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.

  5. Rick June 2, 2015 Reply

    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.

    • Bruce Morton Author
      Bruce Morton June 8, 2015 Reply

      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.

  6. Greg Gehr June 5, 2015 Reply

    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.

    • Bruce Morton Author
      Bruce Morton June 8, 2015 Reply

      Yes, this is the browser ubiquity issue which I referenced in my previous comment.

  7. Steve Brierley June 11, 2015 Reply


    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?

  8. smarty September 4, 2015 Reply

    Hi Bruce, Many thanks for this article.
    We are running Microsoft based internal CA that has SHA1 root certificates. According to this article there shouldn’t be any problem with this setup in the near future, but do you know if we will be able to create valid SHA2 certificates if we just adjust our certificates creation templates?

    • Bruce Morton Author
      Bruce Morton October 15, 2015 Reply

      Sorry for the late reply. You have me at a disadvantage as I am not an expert with a Microsoft CA, but it does seem reasonable that the certificate creation template should be able to be adjusted to change the hash algorithm from SHA-1 to SHA-2 (e.g., SHA-256).

  9. Tijust December 3, 2015 Reply

    I am using SHA 2 root certificate and signed certificate is SHA1 , After importing into keystore getting an error and all apps stopped working. So my question is, Is signed cert and root cert both should have same hashing mechanis. if root is SHA2 then server cert should also SHA2.


    • Bruce Morton Author
      Bruce Morton December 3, 2015 Reply

      You typically have 3 certificates: 1) the server certificate, 2) the issuing CA certificate, and 3) the root certificate. As stated in this posting, it does not matter if the root is signed with SHA-1 or SHA-2. For browsers which check the hashing algorithm for SHA-1 deprecation, they are looking to see that both the server certificate and the issuing CA certificate are SHA-2.

      For your problem where you get an error and all apps stop working, I assume that the problem does not relate to the hashing algorithm.

  10. Maddi January 19, 2016 Reply

    Hi , is there a problem is using Sub CA which has SHA1 based certificate but it issues certificates with SHA2 algorithm ? Do we need to change the Sub CA certificate algorithm also to SHA 2? Please clarify

    • Bruce Morton Author
      Bruce Morton January 21, 2016 Reply

      When Google Chrome verifies the certificate chain it will check the signing hash used on both the server certificate and the subordinate CA certificate. If either one is SHA-1, then Chrome will provide a warning in the status bar. As we move into 2017, I think you will see this type of issue in other browsers and operating systems. So yes, you need to change your subordinate CA certificate to SHA-2.

  11. navin poojary April 29, 2016 Reply

    hi bruce , do we need to install SHA 2 for linux enterprise version machines

    • Bruce Morton Author
      Bruce Morton April 29, 2016 Reply

      What you really need to know is which clients you are trying to support with your linux machine. If the clients are using Windows or are using browsers such as IE, Edge, Chrome or Firefox, then yes, you need to support SHA-2. The reason is these clients will stop supporting SHA-1 in 2017. Please note that the SHA-2 requirement is for the server certificate and the intermediate certificate. You do not need a SHA-2 root certificate.

  12. Craig Holland September 12, 2016 Reply

    Hi Bruce, Great article and some great conversations over time on this topic. Thank you and the participants. Hopefully this is a easy question. We are a small to midsize organization (public school system) with ADCS. One Certificate Server. In preparation for 2017, SHA-2 signing has been enabled but still have a SHA-1 root. As new certificates are issued to internal web server devices, browsers are alerting a problem in the chain. Certs are issued from the certificate server (root). Is it likely the errors come from the chain being “short” (i.e. the root is also the issuing server? Is it a better practice to make the chain longer and add an intermediate CA?

    • Bruce Morton Author
      Bruce Morton September 15, 2016 Reply

      This is a complicated question to answer without understanding your environment. I think it would be best to discuss with your CA support team. Please note that although there should be no problems with SHA-1 signed roots, there will be a problem if the issuing CA is signed with SHA-1. Both the server and the issuing CA need to be signed with SHA-2.

  13. subbu September 20, 2016 Reply

    What are impact after Jan,2017 for Microsoft Enterprise internal CA issued certificates with SHA1 in Chrome and IE

    • Bruce Morton Author
      Bruce Morton September 21, 2016 Reply

      Microsoft describes their SHA-1 policy here, http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx#Q. They address your question with this FAQ:

      Q – Will the policy impact certificates that chain up to an internal root that is not part of the Microsoft Trusted Root Program?
      A – No. Only certificates that are in the Microsoft Trusted Root Program will be affected by the policies described here.

      As such, there should be no impact on Microsoft products with SHA-1 certificates issued from an internal CA.

      Not so sure about Chrome as Google’s policy for internal CAs is not disclosed. Testing now with a SHA-1 certificate which expires after 2016 should indicate how Chrome will work.

  14. Sugan March 14, 2017 Reply

    My IIS 7 Cert’s CA uses SHA1 Hash algorithm and Intermediate and Client Certs uses SHA2.
    The Java application i use pops-up a security warning with Publisher: UNKNOWN
    Is this because of the SHA1 CA? Is this a security risk?

    • Bruce Morton Author
      Bruce Morton March 20, 2017 Reply

      The warning “Publisher: UNKNOWN” would indicate you are installing signed code where the publisher of the code has not been verified by a certification authority. If you do not know who the publisher is, then this could be a security risk.

      • Sugan March 20, 2017 Reply

        Thanks Bruce. The Cert was issued by a trusted publisher like Entrust, Network Solutions. Previously the Root, Intermediate, Server Cert were all SHA1. After re-issue the Intermediate, Server Cert changed to SHA2 but the Root is still SHA1. Something I missed to mention is that the application servers are F5 load balanced; unsure if that has anything to do with this warning.

Add to the Conversation