Do You Need SHA-2 Signed Root Certificates?

Bruce Morton
Part 1 of 9 in the Series — SHA-2 Migration

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.

  2. Mark September 19, 2014 Reply

    Can you please educate.

    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?

    • Bruce Morton Author
      Bruce Morton September 22, 2014 Reply

      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.

  3. Todd December 1, 2014 Reply

    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?

    • Bruce Morton Author
      Bruce Morton December 1, 2014 Reply

      No, the issue is creating another certificate which would have the same SHA-1 signature. Since we don’t rely on the signature to verify the root, attacking the SHA-1 signature is not an issue.

  4. Oren January 4, 2015 Reply

    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.

    • Bruce Morton Author
      Bruce Morton January 5, 2015 Reply

      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.

Add to the Conversation