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.
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.