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.
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
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:
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
RSA 2048 bits (e 65537) / SHA256withRSA
2 Sent by server Entrust Certification Authority – L1C
RSA 2048 bits (e 65537) / SHA256withRSA
3 In trust store Entrust.net Certification Authority (2048) Self-signed
RSA 2048 bits (e 65537) / SHA1withRSA
Weak or insecure signature, but no impact on root certificate
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
SSLLabs SSL Server Test: https://www.ssllabs.com/ssltest/
Latest posts by Pier Carlo Chiodi (see all)
- Route server feature-rich and automatic configuration - 13 February 2017
- Large BGP Communities playground - 15 September 2016
- RFC7050 (DNS64 prefix via ipv4only.arpa) on RIPE Atlas probes - 9 March 2016