IIS sends incorrect intermediate SSL certificate

Question

I just installed a new SSL certificate (from StartCom) to one of our servers and noticed that in Chrome there is the crossed padlock icon displayed for the site so I started investigating why is that so. It turned out it is because the intermediate cert sent to the browser uses the old SHA-1 signature algorithm.

Just to be sure, I grabbed our cert (as originally issed by the CA), ran it again through OpenSSL to merge it with the SHA-2 intermediate cert (I downloaded it from the CA's site) and updated it again on IIS. It still did not help.

I ran a test at SSL Labs and this is what it shows:

What I do not know is where does the intermediate cert shown here (the one with fingerprint "a1ac...") come from.

1. It is not installed on the server - I checked that by trying to find it in the server's "Certificates" snap-in console:

2. It is not part of the certificate I assigned to the site - this is the output of certutil -dump cert.pfx:

   ================ Certificate 0 ================
   ================ Begin Nesting Level 1 ================
   Serial Number: 1cab36472d9c51
   Issuer: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
    NotBefore: 10/14/2007 10:57 PM
    NotAfter: 10/14/2022 10:57 PM
   Subject: CN=StartCom Class 2 Primary Intermediate Server CA, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
   Non-root Certificate
   Template: 
   Cert Hash(sha1): 06 49 69 b7 f4 d6 a7 4f d0 98 be 59 d3 79 fa e4 29 a9 06 fb
   ----------------  End Nesting Level 1  ----------------
   No key provider information
   Cannot find the certificate and private key for decryption.
   
   ================ Certificate 1 ================
   ================ Begin Nesting Level 1 ================
   Serial Number: 07aa747ba37df3
   Issuer: CN=StartCom Class 2 Primary Intermediate Server CA, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
    NotBefore: 7/15/2015 3:41 AM
    NotAfter: 7/15/2017 3:23 AM
   Subject: E=jan.valenta@idioma.com, CN=*.idioma.com, O=IDIOMA, s.r.o., L=Praha, S=Praha, C=CZ
   Non-root Certificate
   Template: 
   Cert Hash(sha1): 02 90 be 6e 6e b8 a5 7a ff aa a2 ac 95 b8 61 2a 3d c7 80 f6
   ----------------  End Nesting Level 1  ----------------
     Key Container = <hidden>
     Unique container name: <hidden>
     Provider = Microsoft Enhanced Cryptographic Provider v1.0
   Encryption test passed
   CertUtil: -dump command completed successfully.
   

Note that the intermediate cert signature does not match the SSL Labs output. It however matches what I see when I open the site's cert on IIS, go to its certification path, open the intermediate cert and see its signature.

What makes IIS send this particular intermediate certificate?

UPDATE:

The public part of my certificate (the very CRT file I got from the CA) is here.

Output of certutil -verifystore CA "StartCom Class 2 Primary Intermediate Server CA":

CA "Intermediate Certification Authorities"
================ Certificate 3 ================
Serial Number: 1cab36472d9c51
Issuer: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
 NotBefore: 10/14/2007 10:57 PM
 NotAfter: 10/14/2022 10:57 PM
Subject: CN=StartCom Class 2 Primary Intermediate Server CA, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
Non-root Certificate
Cert Hash(sha1): 06 49 69 b7 f4 d6 a7 4f d0 98 be 59 d3 79 fa e4 29 a9 06 fb
No key provider information
Cannot find the certificate and private key for decryption.
Encryption test passed
Verified Issuance Policies:
    1.3.6.1.4.1.23223.1.1.1
Verified Application Policies:
    1.3.6.1.5.5.7.3.1 Server Authentication
    1.3.6.1.5.5.7.3.2 Client Authentication
    1.3.6.1.5.5.7.3.4 Secure Email
    1.3.6.1.5.5.7.3.3 Code Signing
    1.3.6.1.5.5.7.3.8 Time Stamping
    1.3.6.1.4.1.311.10.3.4 Encrypting File System
    1.3.6.1.5.5.7.3.6 IP security tunnel termination
    1.3.6.1.5.5.7.3.7 IP security user
Certificate is valid
CertUtil: -verifystore command completed successfully.

Output of certutil -GroupPolicy -verifystore CA "StartCom Class 2 Primary Intermediate Server CA":

CA "Intermediate Certification Authorities"
CertUtil: -verifystore command FAILED: 0x80090011 (-2146893807 NTE_NOT_FOUND)
CertUtil: Object was not found.

Answer 1

It is not IIS fault. Looks like you downloaded wrong intermediate CA certificate or incorrectly merged certificates with OpenSSL.

IIS internally builds certificate chain and uses these certificates (except root certificate, which is not transmitted during SSL handshake) to send to client. Even if the certificate is not presented in the store, IIS can use Authority Information Access certificate extension to retrieve missing issuer certificate.

Based on your output, intermediate CA certificate (in the PFX bundle) is not the right issuer of your certificate. If you could send us (or post here) public part of your certificate, I would provide more information on what is happening. But most likely, the problem is on StartCom side.

Edit 17.07.2015

I examined your output and found that StartSSL made a bad decision when they renewed their intermediate CA certificate. They reused the key pair and as the result, multiple identical chains can be generated for your certificate through different intermediate CA certificates and a single root. Depending on a number of factors, either chain can be selected by chaining engine.

A good practice is to renew CA certificate with a new key pair when any significant information is chnged in the CA cert.

What you shall to do (if possible):

1. remove bindings in IIS.
2. export SSL certificate to PFX. In the export wizard, uncheck the option that includes all certificates in the chain and mark to delete the private key if export is successful.
3. delete the certificate from store and clear CryptoAPI cache: certutil -urlcache * delete.
4. install proper StartSSL CA certificate in the Local Machine\Intermediate CAs: (https://www.startssl.com/certs/class2/sha2/der/sub.class2.server.sha2.ca.crt)
5. install exported PFX to machine store (Personal container). You may select to mark private key as exportable during import operation.
6. Double-click the certificate, switch to Certification Path tab, select intermediate CA certificate -> View Certificate and check whether it is a proper SHA256 cert.
7. configure SSL bindings in IIS.

Answer 2

While I can't comment specifically on StartCom I have had similar issues in the past from vendors changing from SHA 1 to SHA 2, usually issues with cross signing certificates.

What I've found to be the best route to go is find all the intermediate and root certificates returned by your server at the current time and delete the intermediate and root entries.

In your case this would be the 'StartCom Class 2 Primary Intermediate Server CA' and 'StartCom Certification Authority'. You'd probably want to export these first to be on the safe side.

At this point you should be able to import the new certificates from the CA bundle from the vendor.