Do You Need SHA-2 Signed Root Certificates?

Bruce Morton

We have discussed the SHA-1 deprecation policy and why you should move to SHA-2.

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
Bruce Morton
Director, Certificate Technology & Standards

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.


  1. cornelinux August 2, 2014 Reply

    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.

    • Bruce Morton Author
      Bruce Morton August 11, 2014 Reply

      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.

Add to the Conversation