Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|improve this question
up vote 1 down vote accepted

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" on the public internet, and that company can specify what is, and nobody else can.

DigiCert (or whoever) can verify that the certificate request for is coming from the same company that owns and is therefore (probably) not a fraudulent request. They can also issue one certificate for 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.

share|improve this answer
I think I buy this answer, but I have a couple of more questions: 1) What exactly is meant by "Make your server accessible by a real FQDN"? The IP address for the server is either going to be in the 10.x.x.x/96 range, so won't be resolveable by external DNS. Assuming that's okay, are you really just saying that we should name all our servers The company has been run on a .local TLD for 8 years. Is there some site I can point them to to help persuade them that .local is bad enough to incur the cost of doing significant server migration? Or is there some simpler way to manage? – jptsetme Oct 15 '13 at 19:59
and 2) I assume it's a Chrome defect that I did not receive these errors in the past when I was using a wildcard cert (*.mycompany.local issued by GlobalSign)? – jptsetme Oct 15 '13 at 20:00
I do wonder why the wildcard cert worked; using one again would be the smallest change to go back to a 'working' system. .local isn't terrible, but DigiCert saying you own contoso.local adds no credibility so what are you paying them for? You're paying to suppress browser warnings, rather than for more security or useful verification. If you have a domain for your company, e.g., then in your internal DNS add and make resolve to 10.x.x.x (within your network). Then buy a cert for, browsers should stop complaining. – TessellatingHeckler Oct 16 '13 at 1:09
@jptsetme: For the (very delayed) record, internal IPs are resolveable by external DNS just fine. DNS does not care about what data you put in it. (Some resolvers like dnsmasq may break that, but they'd have already broken .local anyway). So the only question is whether you're okay with making it resolveable globally, or just internally. – grawity Aug 30 '15 at 8:39

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

share|improve this answer
I noticed the absence of Chrome in Digicert's list of supported browsers when I started digging into this issue, but I wasn't sure how to interpret it. (i.e. it's not listed among the esoteric browsers that don't support SAN either.) I spent some time on google and figured if Chrome didn't support subject alternative name ssl certificates, it would be easy to find details on that, but I haven't found that to be the case. I'm not using any IP addresses in my subject alternative names. Just fully qualified hostnames. – jptsetme Oct 14 '13 at 20:38

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.

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

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.