Pierky's Blog

While dealing with the SHA-1 sunsetting process I encountered a problem with some certificates from StartSSL/StartCom that may lead Chrome to raise warnings or even errors on websites with updated SHA-2-only chains (at least on Microsoft Windows clients).

Chrome’s SHA-1 deprecation process provides that SHA-1 signed certificates and certificates which include a SHA-1-based signature as part of the certificate chain (root excluded) will be treated as “secure, but with minor errors” or even “affirmatively insecure” (for certificates that expire on or after 1 January 2017). To avoid issues, end-entity certificates must be updated and their chains enforced to use SHA-2-only certificates. Here the problem lies.

Issue

UPDATE: it seems that the specific StartSSL issue can be solved/mitigated using “unofficial” Intermediate CA certificates: more details on Chromium Issue 473105 comment #33

UPDATE-2: finally StartCom created brand new SHA2-only Intermediate CAs, with different names and a starting validity of 2015-12-16, which should fix the wrong caching behaviour. Here an example.

StartSSL SHA-2 end-entity certificates chain up to both SHA-1 and SHA-2 Intermediate CAs (here I used Class 1 certificates, issued by StartCom Class 1 Primary Intermediate Server CA);

$ curl -O https://www.startssl.com/certs/class1/sha1/pem/sub.class1.server.sha1.ca.pem
$ echo "" | \
  openssl s_client -connect testssl.pierky.com:443 2>/dev/null | \
  sed -n -e '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/p' | \
  openssl verify -CAfile sub.class1.server.sha1.ca.pem
stdin: OK

$ curl -O https://www.startssl.com/certs/class1/sha2/pem/sub.class1.server.sha2.ca.pem
$ echo "" | \
  openssl s_client -connect testssl.pierky.com:443 2>/dev/null | \
  sed -n -e '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/p' | \
  openssl verify -CAfile sub.class1.server.sha2.ca.pem
stdin: OK

It seems that if a Windows client has a previously saved SHA-1 Intermediate in its local trust-store (“Intermediate Certification Authorities” tab) then the browser uses exactly that one to build the path, even if the server correctly sends the SHA-2-only chain during the connection setup (tests made on Win7 Pro SP1 with Chrome 41.0.2272.118).

Here the SSLLabs results showing the correct SHA-2 chain sent by the server:

Solutions

To prevent this behaviour the CA/B Forum, in Ballot 118, stated that

SHA-2 Subscriber certificates SHOULD NOT chain up to a SHA-1 Subordinate CA Certificate.

Chrome staff is aware of this problem (Issue 473105), an OS-level issue that all consumers of Microsoft’s APIs are restricted to, but they will handle it with a low priority scheduling, since – they say – it’s a problem that can entirely be solved by CAs.

As far as I can see in the aforementioned Chromium issue, it seems that Entrust suffered of a similar problem too, by issuing SHA-2 leaf certificates from mixed intermediate CA.
In the SSLLabs output pasted in the issue’s body the cio.gov leaf certificate seems to have been issued by the SHA-2 signed version of Entrust Certification Authority – L1C (Fingerprint: 7a11f46fb38f42e577279d39c6f2864bbeafaa75), while the user already had the SHA-1 version in his/her local trust-store (Serial Number: 0x4c0e8c39 – 1276021817):

1 Sent by server cio.gov
Fingerprint: 40c7407c209b9c7d7b1dc30e7302398522ff17c2
RSA 2048 bits (e 65537) / SHA256withRSA

2 Sent by server Entrust Certification Authority – L1C
Fingerprint: 7a11f46fb38f42e577279d39c6f2864bbeafaa75
RSA 2048 bits (e 65537) / SHA256withRSA

3 In trust store Entrust.net Certification Authority (2048) Self-signed
Fingerprint: 503006091d97d4f5ae39f7cbe7927d7d652d3431
RSA 2048 bits (e 65537) / SHA1withRSA
Weak or insecure signature, but no impact on root certificate

As Ryan Sleevi noted in the post, it seems that Entrust then reissued L1C-chained SHA-2 leaf certificates from the proper SHA-2-only intermediate (Entrust Certification Authority – L1K).

Since the SHA-1 deprecation process led to highlight this problem I hope that everything will be tried by every involved party (Chrome, CA, Microsoft also?) to solve this issue, before that these (valid) certificates would be marked as “affirmatively insecure” and would bring major problems (undermining users trust in PKI and lowering SSL warnings effectiveness included).

Tools and resources

Check your site for weak SHA-1 certificates: https://shaaaaaaaaaaaaa.com

SSL-Tools: https://ssl-tools.net/

SSLLabs SSL Server Test: https://www.ssllabs.com/ssltest/