Subdomain in google started to fail with "Your connection is not private" error after we migrated Apex and WWW to netlify

We are seeing SSL issues across all subdomain setup outside of netlify after moving Apex and www to netlify.

Netlify site name https://atoms-k2.netlify.app
Custom domain : atoms.com

Going to www.atoms.com and atoms.com work as expected. However, all of our links we had created for services like Mandrill, sendgrid etc started to fail with the following message

Attackers might be trying to steal your information from trk.atoms.com (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID```


We even generated a wildcard certificate with letsencrypt and updated it in Netlify since netlify by defaualt only created certificates for domains mapped to the site. Is the issue here that we need a different ssl certificate than the one provided by lets-encrypt ?

Previously, the apex was pointed to cloudflare and everything worked fine.

Hi, @atoms. That subdomain (trk.atoms.com ) isn’t served by Netlify.

We cannot provision SSL certificate for systems we don’t control. You will need to contact the support team for that hosting about the SSL certificates there.

To summarize, because that subdomain isn’t a Netlify site, we are unable to assist with troubleshooting the SSL certificates.

If there are other questions about this, please let us know.

This started happening only after we pointed the APEX and WWW subdomain to netlify.

So, part of me thinks that this is related to Netlify. In the above example trk.atoms.com

It is a klaviyo link. In klaviyo, we set trk.atoms.com, and they ask us to have trk.atoms.com point to atoms.klaviyo.com

This worked before moving the Netlify. Now if you are saying this is not Netlify’s issue, I don’t know where to go looking.

This is also not specific to klaviyo. All other subdomains are broken. Could cached data somewhere outside of netlify and google domain cause this ?

Hi, @atoms. Regarding cached data, caching of DNS records due to time to live (TTL) values in the DNS records themselves is the most common cause of delays to DNS record changes:

Our support team can troubleshoot services at Netlify only. I’m not able to troubleshoot the issues with sites at klaviyo.com but I can troubleshoot any issues with our service at Netlify.

This is what I do know.

First, I see a Netlify DNS zone for this domain here:

https://app.netlify.com/teams/wearatoms-admin/dns/atoms.com

However, that DNS zone isn’t being used. Note, if it isn’t being used it must be deleted. Keeping an inactive DNS zone in Netlify for a custom domain will prevent us from renewing the SSL certificates for sites using that custom domain or its subdomains.

Second, the DNS zone isn’t active (and therefore should be made active or deleted):

$ whois atoms.com | grep -i "name server"
   Name Server: NS-CLOUD-C1.GOOGLEDOMAINS.COM
   Name Server: NS-CLOUD-C2.GOOGLEDOMAINS.COM
   Name Server: NS-CLOUD-C3.GOOGLEDOMAINS.COM
   Name Server: NS-CLOUD-C4.GOOGLEDOMAINS.COM
Name Server: NS-CLOUD-C1.GOOGLEDOMAINS.COM
Name Server: NS-CLOUD-C2.GOOGLEDOMAINS.COM
Name Server: NS-CLOUD-C3.GOOGLEDOMAINS.COM
Name Server: NS-CLOUD-C4.GOOGLEDOMAINS.COM

It seems the issue occurred when you activated Netlify DNS for this site. If so, please take a look at this support guide:

That support guide covers the case where service stop working because the DNS records need are not copied to Netlify DNS before activating it.

To summarize, at this time Netlify DNS isn’t being used. It if was being used our support team is here to troubleshoot the DNS service at Netlify. The site also isn’t hosted at Netlify. If it was hosted at Netlify we can troubleshoot it. However, we cannot troubleshoot SSL issues with a third-party service and trk.atoms.com isn’t using Netlify (for either HTTP or DNS) at this time.

If there are SSL issues for any sites hosted at Netlify, please let us know and we’ll be happy to troubleshoot. Likewise, if there are questions about this reply, just let us know and we’ll do our best to answer.