Share this:

The certification authorities (CAs) have provided methods to have your certificates issued and signed using a SHA-2 hashing algorithm. As we move ahead, you will see the CAs changing the default signing algorithm from SHA-1 to SHA-2.

It’d be sound strategy to move all of your certificates to SHA-2 and do some testing. Don’t worry about the operating systems and the browsers as they support SHA-2. But make sure your other applications also support SHA-2. These are the applications that your company has coded or have procured from a third party.

You will also see that the issuing CA will be signed using SHA-2, and so will your CRL and OCSP responses. However, in many cases, you will not see the root certificate signed using SHA-2. Why?

In short, the signature on a root certificate is not verified as the software trusts the root certificate public key directly. A root certificate is self-signed and is not signed by another entity that has been given authority. The root certificate gets authority through the root certificate program managed by the operating system or browser developer.

In a root certificate program, the developer determines a certificate policy that provides the rules with which the CA has to comply. The CA states compliance to the policy through the publication of its Certificate Policy or Certification Practice Statement documents. The CA confirms compliance to these rules by providing third-party audits such as those performed by WebTrust. If the CA meets the certificate policy, then the root is trusted and embedded in the software. As such, verification of trust using the signature is not required.

In Microsoft’s responses to their SHA-1 deprecation policy, they state the following: “The SHA1 deprecation policy does not impact SHA1 root certificates, because Windows relies on other means to validate root certificates besides the signature. But all root CAs are expected to switch to use SHA2 to sign any subordinate CA certificates, CRLs, etc.”

So please do not be concerned if the website you are visiting does not use a SHA-2 signed root certificate.

Updated September 11, 2014:Google is also sun-setting SHA-1, but regarding roots state “Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.”

Bruce Morton has worked in the public key infrastructure and digital certificate industry for more than 15 years and has focused on SSL and other publicly trusted certificates since 2005. He has been an active member of the CA/Browser Forum that released guidelines for extended validation (EV) certificates and Baseline Requirements for SSL certificates. Bruce oversees the governance and compliance of Entrust’s publicly trusted PKI.

15 Comments

I am wondering if this is that easily tue in all cases or only for the browser or only for microsoft certificate store. The root certificates has many information in it, an AIA, CDP, the CA path length, the lifetime. If I was able to change the CA path length without compromizing the signature, I might be able to introduce a new issuing CA, which was never planned by the PKI designers.
I also might change the location of the CRL, pointing to an older, but still valid CRL, that does not contain the certificate with the compromized key, yet.
I might simply change the til valid field to yesterday.

This are just ideas, angles of possible attacks that pop into my mind.

Root certificates are interesting as they typically do not have an AIA, CDP or path length. The purpose of the root certificate is to provide a public key to the browser (or operating system). The browser does not need to verify the signature as the public key was provide to the vendor of the browser through a trusted method.

Introducing a new issuing CA would mean that you would need to have the issuing CA cross-signed by the root CA. In that case you would have to compromise the root CA. If you own the root CA, then you wouldn’t need to compromise the signature process.

There is no CRL for a root certificate. The root certificate is considered trusted by the browser, if it is is moved to not trusted, then the browser will have this information.

SHA-1 deprecation is disjoint to encryption and hashing (ciphers) dictated by HTTPS server?

This is purely verification of certificate using SHA-2 vs. using SHA-1. Encryption/Hashing negotiated between client and server is disjoint topic to this? Meaning we can still have RC4-MD5 cipher supported while using certificate signed using SHA-2?

Also can certificates have dual fingerprints one using SHA-1 and one using SHA-2 to support browsers that dont work with SHA-2? Or the only way to support legacy clients is to hope server support dual certificates?

SHA-1 deprecation applies to the use of SHA-1 to hash the certificate at the time of signing the certificate by the CA. SHA-1 deprecation also applies to other signatures such as signing the CRL or the OCSP response. SHA-1 deprecation does not apply to the cipher suites used to negotiate a TLS session between the browser and the server.

For SHA-256 support, some servers may allow that more than one certificate be installed which will allow support of legacy clients. The good news is that all browsers support SHA-2 and Windows supports SHA-2 back to Windows XP SP3.

The certificate fingerprints are not included in the certificate. These are typically done by the browser. When you view a certificate using Internet Explorer, it will display the SHA-1 fingerprint. When you view the certificate using Firefox, it will display both the SHA-1 and the SHA-256 fingerprint.

Is the issue with sha-1 that it is possible to crack the certificates signature and determine the private key? If so, then wouldn’t having a sha-1 signature make the root cert vulnerable to such an attack even if you weren’t relying on the signature for trust?

Following up on the note made by both Microsoft and Google that ” SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.”

Does this mean that for Root CA that are managed internally in the company network this change won’t have any effect since the CA Root certificate is added to each OS certificate repository (be it manually, scripts or group policy) and the only thing that might be done is to add a new intermediate that signs certificates in SHA2.

You should not have a problem with the trust of a SHA-1 signed internal root CA. You will have to consider which clients need to be supported which validate your certificates. I believe that Microsoft will not be pushing their SHA-1 deprecation policy down to internal CAs; however, Chrome of Firefox may. In this case the best solution is issue SHA-2 signed intermediate CA and end user certificates. You also need to consider how you will provide status of your certificates. Since SHA-1 will no longer be supported, the CRL/OCSP responses should be signed using SHA-2.

Thanks for the great information. I did not know SHA-1 was still going to be accepted if it’s the root cert. I suspect however signing everything but the root CA with SHA-2 will cause some confusion. If someone is having cert issues they may immediately point the finger at the SHA-1 root thinking that’s depreciated and it should be SHA-2. Is there any downside to signing the root CA with SHA-2 so everything in the entire chain is signed with SHA-2? This to me would make it a much cleaner certificate environment and remove any question of SHA-1 depreciation when troubleshooting.

The trust of the roots is not determined by validating the signature. The roots are trusted because the CAs have gone through a process and the browsers have accepted and embedded the root certificates in the browser or operating system. The advantage is the older SHA-1 roots have high browser ubiquity and will support SHA-2 certificates as we migrate from SHA-1 to SHA-2. There is no downside to using SHA-2 signed roots; however, in some cases they may be too new and do not have browser ubiquity.

it is over one year since this article was written. Based on what was written here, I purchased a Comodo SHA 2 cert to use with my Cpanel 11.48 email host for use by my Mac Apple Mail Clients and guess what, Comodo and Apple have not yet completed the “accept the new cert” dance, which means Apple Mail cannot send email SSL with this cert without forcing the trust of the cert. Two weeks after starting the process to get the cert to work, I am giving up and am purchasing a SHA 1 cert. I will upgrade it if/when the real world for Apple users actually adopts this new standard.

We issue server to server PKI certificates from our own CA. They are all currently SHA-1 and we are in the process of replacing them with SHA-2 certificates. When january 1, 2017 comes and if we have not replaced our server to sever certificates will Windows stop accepting the SHA-1 certs? If the browser is not invovled in the communication stream will the SHA-1 encrypted communication still work?

IdentityOn Blog

Entrust has been at the forefront of the identity-based security market for nearly two decades. Our identity-based security solutions secure governments, enterprises, and financial institutions in more than 5,000 organizations spanning 85 countries.