3

I installed a Comodo Certificate on Windows Server 2012 / IIS 8.5. For most clients this certificate works without a hitch, but older Android units running Chrome and also Chrome on MacOS Sierra cannot access the site properly because the site is marked as untrusted.

When running SSL Test from SSL labs i get this result: Status

Basically there are two certification paths where one is requiring extra download.

The only solution provided by the vendor of the certificate is to disable all uses of the "COMODO RSA Certification Authority", however this will only work until the next update of the trusted root certification list and requires a reboot each time.

Should I get a certificate from another vendor (seems easier?) or is it possible to extract parts from the issued certificate and rebuild a proper chain?

Oskar Sjöberg
  • 91
  • 1
  • 7
  • Maybe root cause is that "COMODO RSA Certification Authority" exists two tims with different thumbprints, maybe this is confusing to Windows Server / IIS? – Oskar Sjöberg Oct 11 '16 at 05:57
  • So far the only solution seems to be to disable the COMODO RSA Certification Authority and disable the update of the trusted root certficate list. This however seems like a step backwards. I followed this guide: https://support.microsoft.com/en-us/kb/2831004 . There must be a better way, right? – Oskar Sjöberg Oct 19 '16 at 19:07
  • Is the file format for your cert .pfx? I use to use GNU tools (on a Linux system) to convert formats and build a chain the way I want. See https://bgstack15.wordpress.com/2016/06/30/manipulating-ssl-certificates/ and its source http://stackoverflow.com/questions/18787491/adding-certificate-chain-to-p12pfx-certificate/18830742#18830742 – bgStack15 Oct 25 '16 at 17:43

3 Answers3

2

There is nothing wrong with the certificate, it has multiple chains to support obsolete browsers. (This is common with other CAs too) All you need to do is download the missing intermediate and add it to the certificate store on the server and it will serve it up for these troublesome clients.

https://community.qualys.com/thread/12831

JamesRyan
  • 8,166
  • 2
  • 25
  • 36
  • I downloaded the .PEM file from https://ssl-tools.net/subjects/5e021b686c5cd3be1691995789dfc41472163d03, renamed it to .CRT and imported it to "Intermediate Certificate Authorities\Certificates" in Certmgr.msc rebooted server and the same result. What did I do wrong? – Oskar Sjöberg Oct 10 '16 at 18:11
  • Additionally I tried adding the certificate to: Trusted Root CAs and Third Party Root CA, rebooted but with no luck. – Oskar Sjöberg Oct 10 '16 at 19:00
  • Definately dont put it in intermediate or trusted roots. It needs to be in LOCAL_MACHINE\\Personal with the certificate itself. If it doesn't serve that up you can combine it into the certificate following instructions in the link – JamesRyan Oct 11 '16 at 09:03
  • I will try to put the cert and the missing intermediate certificate under Personal to see if that helps. – Oskar Sjöberg Oct 11 '16 at 10:02
  • Adding the cert and intermediate certficates under Personal did not help. Please note that the certificate that it fails to send already is in the trusted root certificate list provided from Microsoft. I was not able to understand how to combine the certificates and import them into cert. – Oskar Sjöberg Oct 19 '16 at 19:04
0

I noticed there is a SHA1 certificate in the chain. If you test your site with Firefox, you may experience the same issue. It may be seeing the SHA1 as older and not trusted. https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/ also https://support.mozilla.org/en-US/kb/secure-website-certificate may help. SHA1 is being phased out and may be causing your issue.

Tim Haintz
  • 486
  • 1
  • 3
  • 8
0

A similar issue happened to me today on WS2012R2 IIS8.5 on 9 out of 80 Windows VMs that were deployed from scratch using Salt automation. I fixed it by going in to IIS manager, select the web site, top-left corner 'edit bindings...'. Select the certificate, select edit. Make some changes, click ok. Click `edit bindings...' again and undo your changes and click Ok again. That resolved the issue for me. The failures showed up by running 'openssl s_client -connect :443' In the first group of lines of output you either see openssl '20', '21' and '27' errors if the issue exists and otherwise you see the correct cert chain.

Steven
  • 1