1

Server: Windows 2012 R2 / IIS 8.5 using SNI (Azure Virtual Machine)

I have an SSL certificate that has been installed and is working in all browsers except Firefox and iOS Safari. The chain in Chrome and IE appears as follows:

Baltimore CyberTrust Root
---->XX Public Root Certification Authority
-------->XX Certification Authority
----------->xxx.domain.com

In Firefox and Safari on iOS, you get a message that says the site is untrusted and if you view the certificate via Add Exception the chain appears as follows:

XX Certification Authority
----->xxx.domain.com

XX Certification Authority has signed the xx.domain.com certificate. Public Root Certification Authority has signed the XX Certification Authority and CyberTrust has signed Public Root Certification.

The intermediate certificates are in the Intermediate Certification Authorities store on the server. For some reason, Firefox will not download the complete certificate chain (or the server is not sending it). I have tried to delete cert8.db in the Firefox profile and I've had it happen on clean machines consistently.

I have tested my domain at sslshopper.com and ssllabs.com. They do not report any errors and report that all intermediate certificates are installed correctly.

Jonathan
  • 111
  • 3

2 Answers2

2

They do not report any errors and report that all intermediate certificates are installed correctly.

The symptoms you describe look very much contrary to this claim. Chrome (and IE?) download missing intermediate certificates by themselves while Firefox and most mobile applications do not. SSLLabs will not mark these intermediate certificates as missing but they are marked as "Extra Download".

If this is really not the case check if your server has IPv4 and IPv6 enabled and if the setup for IPv6 is different. SSLLabs does not check the IPv6 setup. If IPv6 gets used depends on the OS, connectivity and preferences of the browser so this might explain such differences too. Other differences in this area are different IP address of the server depending on the location or different tests, i.e. sometimes www.example.com and sometimes only example.com.

Steffen Ullrich
  • 13,227
  • 27
  • 39
  • SSL Labs has recently begun testing IPv6 versions of sites separately. It's been done very nicely, IMO. – womble Sep 27 '15 at 07:10
  • I agree that the symptoms don't seem to match the tests but this is definitely the case. I checked it again with the dev ssllabs which supports ipv6 though we don't have an ipv6 entry in the DNS for this domain. This SSL cert has a couple of SANd and it's bound to multiple sites on this server and they all exhibit the same issue. On ssllabs, the cert paths say "sent by server" for the first 3 and "in trust store" for CyberTrust. – Jonathan Sep 27 '15 at 12:28
  • @Jonathan: did you try Chrome, Firefox and IE all on the same system so that they get the same IP address and are affected by the same middleboxes (firewalls etc). And did you make sure that they have the same settings regarding proxies? Also note that Chrome and IE use the same certificate store on Windows while Firefox has its own. – Steffen Ullrich Sep 27 '15 at 13:51
  • @Steffen: Thank you for continuing to look at this. I did try it all on the same system. There are no proxies. I've also had reports of the same situation happening on other systems. – Jonathan Sep 27 '15 at 14:15
  • @Jonathan: hard to tell what's going on without further details. Can you share the affected URL? – Steffen Ullrich Sep 27 '15 at 15:03
0

After much trial and error, I was finally able to fix it. I do not know exactly what fixed it but I continued to load several intermediate certificates from my certification authority. Although I had loaded intermediate certificates that matched the certificate chain by name, it did not seem to match on serial number. I finally found a combination that Firefox and iOS Safari liked. Still, the SSL Labs never showed extra download.

Jonathan
  • 111
  • 3
  • serial number is not involved in the process. But there are sometimes certificates with the same name but different public key (e.g. 1024 bit vs. 2048) and if you've added the wrong intermediate certificate it cannot be used to verify the signature. – Steffen Ullrich Sep 29 '15 at 14:07
  • I wondered the same thing about the serial number. I did not realize the different public key portion though. I was getting out of my depth and glad to get it resolved. – Jonathan Sep 29 '15 at 14:11