May 9, 2023
When viewing the TLS Certificate hierarchy for sites secured with a GlobalSign TLS Certificate under our Root R3, some users may observe a 4-level certificate chain back to the SHA-1 GlobalSign Root R1.
This article discusses how this happens, why it’s not a security risk that the TLS Certificate appears to be issued under the SHA-1 GlobalSign Root R1, and how to temporarily resolve the misleading certificate chain displayed by the Microsoft Certificate Viewer.
When a client visits a secure site and initiates the TLS handshake, the site provides a “chain” of Certificates including the website Certificate and any intermediates needed to connect it back to a trusted root. Every client makes use of a root store – a collection of embedded CA Certificates – which protects the client from visiting sites that have TLS Certificates that are forged or issued by untrusted sources.
If all of the necessary subordinate CA Certificates are not provided to the TLS client, then it cannot make a trust determination and it will not connect securely. To help offset this and avoid connection issues, most browsers cache the intermediate CA Certificates they are provided so they can be re-used in future TLS connections.
GlobalSign created a cross-signed Certificate to help chain its R3 root back to the older R1, which enables clients with just R1 in their Root trust store to trust websites using the newer R3 root. That’s because some very old clients may not have R3 as a trusted root, and if web site operators have visitors in that category, then they can configure their web server to provide the Cross Certificate during the TLS handshake. The Cross Certificate is treated like a subordinate CA and is cached for future use.
If you’ve visited a site that provided you the cross-signed Certificate, then the Microsoft Certificate viewer will display a chain like this:
However, if you were to use Firefox, you would see a chain like this (TLS Certificate, SHA256 – G3 Subordinate CA, Root R3):
Why does this happen? Well, for starters, each browser uses its own proprietary logic to create the Certificate Chain.
Some use the shortest chain, some have used the most recently issued Certificates, others have implemented slightly different methods. But when checking the Certificate chain from browser to browser – results will vary.
Short answer, no. While SHA-1 is insecure, the signature on a Root Certificate is irrelevant to the trust of Certificates that chain to it. How, you ask? Well, normally the signature on a Certificate is important because without that you have no idea who owns and controls the keypair. However, when it comes to browsers and operating root stores, the public key and identity are securely stored and there is no reliance on SHA-1 for securing the binding of the key pair to the identity. This permits old Roots to continue to be used because the binding is enforced within the Root store.
So, you have a security expert that requires SHA-256 roots because that is their policy (which is debatable for the reasons listed above) and they mandate that your TLS Certificates be issued under a SHA-256 root.
There are a couple of things you can do:
Good question! One way is to use the Qualys SSL site checker which provides the list of Certificates delivered in the TLS handshake.
Here is a step-by-step process to remove the Cross Certificate, but, once again, please note that it will return when you visit a site that is providing it as part of the TLS handshake.