Chrome displays SSL error due to use of .local top level domain

Question

I just replaced the SSL cert on a few of our servers (all hosted on IIS7). At the suggestion of our IT manager, we're using a Subject Alternative Name certificate instead of individual certs for each server. We bought this cert from Digicert (it's not self-signed.) I have installed the certificate on our servers and the sites load without warning and show good locks in Firefox and Internet Explorer. However, Chrome displays a red "x" through the lock icon and strikethrough font for the "https" portion of the URL. The Connection tab displays the following error:

"The identity of this website has not been verified. The identity of the server you are connected to cannot be fully validated. You are connected to a server using a name only valid within your network, which an external certificate authority has no way to validate ownership of. As some certificate authorities will issue certificates for these names regardless, there is no way to ensure you are connected to the intended website and not an attacker."

Clicking on "Certificate Information" shows me the full chain of certs (our cert, Digicert's intermediate cert and Digicert's CA cert) and the certificate status for all three shows as "This certificate is OK.". I have quadruple checked that the hostname I am using in the URL is an exact match for either the common name or one of the subject alternative names in the cert. The previous cert we had on these sites was a wildcard cert for *.mycompany.local, while the new common name and SAN names are for specific hosts within the mycompany.local domain (i.e. eng-wiki.mycompany.local).

The explanation from Chrome almost sounds as though it has detected that an internal DNS server was used to resolve the IP of the server, but that was the case with the old wildcard cert as well, and if that were a valid reason to claim that the identity couldn't be verified, it should have failed the same way with the old wildcard cert (but it did not.) Moreover, that explanation would imply that no company internal servers can have their identity verified, which does a lot more harm to security than good, since we'll all have to teach our users to ignore the security warnings in Chrome despite having dropped hundreds of dollars on a legit cert specifically to avoid that.

I'd be grateful for any help.

Thanks!

--edit--

Digging further today, I searched the Chromium source for the text of the error message and found that the issue is caused by Chrome concluding that the hostname is not unique. There are other posts reporting this issue like this one with SAN certificates when using a shortname for their URL. But I'm using a fully qualified server name, for example wiki.mycompany.local

The code that determines my hostname as non-unique is here, and I see some comments discussing gTLDs which I suspect is the root cause. I don't know much about global top level domains, but my company uses the .local pseudo-TLD. Wikipedia seems to say that this is no longer a good idea (I can't make 3 links b/c my reputation is too low on server fault, please feel free to edit this and make it a link en.wikipedia.org/wiki/.local), though it was a recommended practice many years ago when our IT team set up our network. Not an easy thing to ask them to change now

I'm tempted to edit my question to remove the SAN element from the equation, except that I did not have this issue when using a wildcard cert for mycompany.local. So I still suspect the use of a SAN cert is part of the issue. Still grateful for any help.

Answer 1

Moreover, that explanation would imply that no company internal servers can have their identity verified, which does a lot more harm to security than good, since we'll all have to teach our users to ignore the security warnings in Chrome despite having dropped hundreds of dollars on a legit cert specifically to avoid that.

But they can't have their identity verified by a third party, no matter how expensive the certificate was.

Only one company can "own" contoso.com on the public internet, and that company can specify what server1.contoso.com is, and nobody else can.

DigiCert (or whoever) can verify that the certificate request for server1.contoso.com is coming from the same company that owns contoso.com and is therefore (probably) not a fraudulent request. They can also issue one certificate for server1.contoso.com and then no more.

Anyone can have contoso.local. Lots of people all at once. Digicert can't do anything to verify that you do or don't have servers by that name. And they can issue certificates to that name over and over again each to different people.

So the security warning is a genuine warning - Chrome cannot verify that this is the intended server1.contoso.local because the exact same certificate could be installed on a thousand computers called "server1.contoso.local" around the world.

If you're considering putting your credit card details into a site, a .local certificate should not reassure you much at all.

Apparently IE and FireFox have differing views on this, choosing to pretend that it is fine, when it actually isn't.

Make your server accessible by a real FQDN and buy a certificate for that instead.

Answer 2

DigiCert doesn't list Chrome as a supported browser on their site. As discussed elsewhere, the interpretation of a SAN depends on the SSL implementation, and I suspect Chrome may do Something Weird(tm) compared to Firefox or Internet Explorer.

By chance are you using an IP address in the SubjectAltName? Looking at one of the Chrome App code samples online seems to indicate they expect a hostname in there (and not an IP).

Answer 3

This is fairly simple and it boils down to Authentication. As TessellatingHeckler stated, the security warning is genuine and there is a workaround for this. This is not a defect in Chrome but rather a proactive approach to best security practices that IE or FF might need to catch up on. Ever wonder why some CAs are still selling 5 year certs while others are only selling 3 year? There is a change in cert validity period coming soon as well.

When an Organizational Validated (OV) certificate is issued, the CA must authenticate that the domain is fully registered at a domain registrar and that the business has the right to use the domain. It does so by looking at WHOIS and D&B to verify this information. Anything that is .com/.net/.edu for example. One the other hand a .local can be owned by anyone and can not be authenticated by any CA. Not sure how Authentication was done at Digicert but it shouldn't have. When you buy a SSL cert, you pay more for Authentication than anything else.

Here is a link from the CA Browser forum stating that by OCT 2016, the use of all internal names will be eliminated for best security practices. Hopefully it will shed some light to your IT management team and for them to start taking a proactive approach instead of waiting until the last minute.

https://www.cabforum.org/Guidance-Deprecated-Internal-Names.pdf

May I ask you for how many years is this certificate valid for? The reason I ask is that there is a work around for the time being so you can sort out the server configurations regarding internal name. When you generate the CSR, put the common name as www.yourcompany.com and in the SAN field, put in "yourcompany.local" This way, when the CA is in the process of authentication, it can verify that you have the rights to www.yourcompany.com, and within the SAN field, the IP address for yourcompany.local will also be secured. This workaround is time sensitive since no CA will issue a 3 year cert under such conditions if its validity period is passed the mandated change.

I hope the information is somewhat helpful.