Update Microsoft certificate authorities to use the SHA-2 hashing algorithm

Summary

Microsoft is announcing a policy change to the Microsoft Root Certificate Program. The new policy will no longer allow root certificate authorities to issue X.509 certificates using the SHA-1 hashing algorithm for the purposes of SSL and code signing after January 1, 2016. Using the SHA-1 hashing algorithm in digital certificates could allow an attacker to spoof content, perform phishing attacks, or perform man-in-the-middle attacks.

Recommendation: Microsoft recommends that certificate authorities no longer sign newly generated certificates using the SHA-1 hashing algorithm and begin migrating to SHA-2. Microsoft also recommends that customers replace their SHA-1 certificates with SHA-2 certificates at the earliest opportunity.

Configure Microsoft certificate authorities SHA-2

Confirm your current configuration

EDIT 04/2015: Your Operating System must support SHA-256.

  1. Start your the Certification Authority Tools
  2. Select your Certificate Authority and open the Properties.
    Capture001
  3. On the General tab, you can see your actual Hash algorithm (in my case SHA-1).
    Capture007
  4. You can look at the your Certificate Authority Certificate properties, using View Certificate, browse to Details. As you can see my current Signature hash algorithm is SHA1 for this certificate.
    Capture003

Move your Certificate Authority to SHA256

EDIT 04/2015: Your CA must be in a running state before execute the folowing commands.

  1. Open a Windows Powershell.
  2. Enter the command:
    certutil -setreg ca\csp\CNGHashAlgorithm SHA256

    Capture004

  3. Restart your Certificate Authority service using the Stop this service and Start this Service button.
    Capture005

Your Certificate Authority is now issuing certificate using SHA256 as Hash Algorithm, but your current certificate is still a SHA-1 hash algorithm.

Renew your Certificate Authority Certificate to use SHA256

  1. Select your Certificate Authority and open the All Tasks line, Then select Renew CA Certificate…
    Capture101
  2. Accept the request to stop the Active Directory Certificate Service
  3. You can choose to generate a new signing key.
    Capture102
  4. Active Directory Certificate Service will restart

Your Certificate Authority is now using the new certificate that you issued with SHA256 as hash algorithm.

Confirm your current configuration

  1. Select your Certificate Authority and open the Properties
    Capture001
  2. On the General tab, you can see your actual Hash algorithm (in my case SHA256).
    Capture007
  3. You can look at the your Certificate Authority Certificate properties, using View Certificate, browse to Details. As you can see my current Signature hash algorithm is SHA256 for this certificate.
    Capture103

39 thoughts on “Update Microsoft certificate authorities to use the SHA-2 hashing algorithm

  1. In this case however, will all pre-existing issued certificates need to be re-issued or will they still work as is? Also, do you delete/remove the old root certificates? And do clients who have the root certificate installed need to install the new one or would they be ok with the old one?

  2. Hi Steve,

    The certificates you issued for remote peers will remain valid as long as the certificate and the previous root certificate are valid.
    In my opinion, It’s better to keep the previous SHA1 root certificate in order to allow migrating slowly to SHA2 all your peers.
    The client that are using a certificate based on the previous SHA1 root certificate are fine, but any client using a certificate based on the new SHA2 root certificate will need the new root certificate.

    Adrien P.

  3. Thank you for your reply Adrien. So I would be safe to do the following:

    certutil -setreg ca\csp\CNGHashAlgorithm SHA256
    net stop certsvc
    net start certsvc

    This would leave my current root certificate intact and I would then have a second one which is used for the SHA256 hash algorithm? I just keep the old one as is and it remains valid for use with the currently issued certificates which I can then later migrate over to the new root certificate over time. Is this correct?

    My biggest concern is that I perform the above and then the current root certificate and all previously issued certificates become invalid which would have a huge impact on our infrastructure.

    If you have any official documentation that you could point me to or other best practice that would be greatly appreciated. Thanks again.

    1. Hi Steve,

      Your new root Certificate will be use to issue all your new certificate, which means, for what I saw, you won’t be able to issue certificate that use SHA1 anymore… until you do the reverse action.

      I didn’t find any doc specific to this migration, but that should be the same behavior that an early renewal of a root certificate.

      Adrien P.

      1. Adrien, thank you very much for your reply. I am fine with no longer being able to issue SHA1 certificates and only SHA256 going forward. The only concern is possible impact to the validity of existing certificates (issued ones and the root certificate itself). If no impact then I would be able to go ahead with it. In your experience (production environment) was this not an issue?

        In another forum (if you look at the posts), it seems the opinion there is different and advising not to do it:

        http://social.technet.microsoft.com/Forums/windowsserver/en-US/dfbf6724-f0da-4151-8059-d76c796f3e34/migrating-internal-standalone-ca-from-sha1-to-sha256?forum=winserversecurity

    2. Steve, how did your change go? I am working on the same now and plan to upgrade my root and intermediate CAs to SHA256 but would need to ensure all of the systems, applications, and websites are ok with their current SHA-1 certs until they get migrated. Any lessons learned from your project you could share?

  4. Adrien,

    I have an offline root and 2 issuing CAs that my Microsoft Certs are generated from. I have 2 questions on this topic.

    1. I am going to guess that the process described above has to be done on the root and then a new cert issued to the 2 issuing servers as well as any other intermediates/issuing servers that I have created (like a proxy for instance) or can this just be completed on the issuing CAs? We just renewed the Root at this time last year and I really don’t want to go through that work all over again if I can avoid it.

    2. With the generation of a new key is that required or just a suggestion, since there is no expectation that my key has been compromised in any way, so issuing a new one would create more work since the environment that is served by the Microsoft CA is fairly large… I would end up pushing a new root and new intermediate/issuing certs to all devices.

    1. Dave,

      I realize your post was from over a year ago but your environment describes mine. I’m thanking that I change the CSP on my offline root to SHA256 and then renewing the two issuing CA signer cert to this offline root with the same key, so as not to create a new CRL. Then, updating the CSP on the issuing CA to SHA256 will product only SHA256 moving forward. The one question I had that I’m not 100% clear on is under this scenario, will the existing issued SHA1 certificates be able to use the new CRL since it would be SHA256 at that point. Internally, AD handles but I have some out there that aren’t AD-aware.

      Appreciate any feedback and experience you care to pass along.

  5. I did exactly as you posted but when I renewed the cert it the new one, Certificate #1 was ALSO SHA-1.

    I don’t understand what went wrong.

  6. Hey Adrien, same thing for me. All new CA certs remain SHA-1 and the commend def shows it was changed to SHA256. The only thing I see different is that my CA cryptographic settings show “Microsoft Strong Cryptographic Provider” while yours does not. Is there an easy way to change that?

      1. Per MSDN, the Microsoft Strong Cryptographic Provider (based on the older CryptoAPI) only implements SHA-1.

        https://msdn.microsoft.com/en-us/library/windows/desktop/bb931357%28v=vs.85%29.aspx

        There’s a good discussion here of the old CryptAPI and new CNG (CryptoAPI Next Generation) providers.

        http://ammarhasayen.com/2015/02/03/cryptographic-providers-sha-1-sha-2-support/

        It sounds like you’ll want to migrate to a new provider before you attempt to change the hashing algorithm. See this write-up for steps.

        http://ammarhasayen.com/2015/02/04/sha-2-support-migrate-your-ca-from-csp-to-ksp/

  7. I have a RootCA and a SubCA – root is offline and SubCA has issue many client certs over the years. I am planning the following:

    1. Root CA to be started on the VM cluster –
    2. Backup cert repository on both root and sub CAs

    certutil -backup \\share\cabackup
    certutil -backup \\share\subcabackup

    3. Change signing to algorithm to SHA2 only on SubCA

    certutil -setreg ca\csp\CNGHashAlgorithm SHA256

    net stop certsvc

    net start certsvc

    4. Try issuing a client certificate from any server or online portal
    5. If the certificate is SHA2, this is considered completed
    6. If not update the issuing cert of the SubCA to SHA2 (just renew with the same key) and test existing certs, issue new certs

    Before I do this, I need assurance of some sort, anyone done this yet? what happens to the old certs with SHA1.

      1. After setting SHA 2 in the SubCA (certificate renewed with the same key) the old certificates with SHA1 coexist?

  8. I was having the same issue. I was getting a message stating the algorithm was changed to SHA-2 but validation would show SHA-1. Turned out I was stopping the CA service first. The command needs to be issued while the CA is running. After the success message, then stop and start the CA. So I issued the command, restart the CA, re-published the CRL, ran validation and it worked.

  9. It’s important to not that the KSP must be supported by the OS, which mean anything above Windows Server 2008, if your CA don’t produce a SHA-2 it means it’s a prior version of Windows. Only a new Windows support KSP

  10. Great info, thanks! What will become of all the SHA1 certs that I have issued out now? Will they continue to work?
    Will this cause downtime on the CA server?
    Thanks

    1. The old certificate will remain active until they expire. The downtime is only for requesting new certificate, so it’s pretty small impact.

  11. I am currently working on a similar project. My Root CA is on SHA1 but with a Key Storage Provider to support SHA 256. My intermediate CA is on SHA256 cryptographic settings. I tried to renew Intermediate CA so that it get a SHA 256 hash algorithm but the renewed cert still has a SHA1 hash. Does anyone have any clues ? Thanks

  12. After setting SHA 2 in the SubCA (certificate renewed with the same key) the old certificates with SHA1 coexist?

  13. I have a windows 2008 R2 server that serves as a domain controller with an Enterprise Root CA. The CA is using CSP and SHA-1.
    We are working to figure out the details of getting to SHA-256. I know I have to upgrade to get to KSP to allow for SHA-2.

    How we can proceed? Is there any risk involved. What about the existing issued Certificates. Can any one help me for migration.

  14. I have an offline Root CA, an offline Intermediate CA and 2 Issuing CA’s all running Windows Server 2008 R2. The CA’s are running KSP and issuing SHA1 certs. The forest and domain functional levels are set to Server 2003.

    I would like to upgrade the Internal PKI setup to issue SHA256 certs. I am planning to update host operating system to Windows Server 2012 R2. I will upgrade Windows Server 2008 R2 to R2 SP1 and then perform an in place upgrade to Windows Server 2012 R2 standard edition. Of course I will backup the PKI infrastructure before upgrade the OS.

    However, I am not a PKI expert and inherited the setup when a colleague retired. I am a little confused as to how I should upgrade. The root CA has a 20-year lifespan, the Intermediate 10 years and Issuing CA’s are set to 5 years. I have to update the CRL’s once per year.

    As the issuing CA’s are setup using KSP do I need to only update them to use SHA256 by running
    certutil -setreg ca\csp\CNGHashAlgorithm SHA256
    Or do I need to update the Root and Intermediate CA’s also?

    If the Issuing CA’s are only updated to SHA256, could there be any potential problems when I perform the yearly CRL update? Or would it be best to update all the CA’s to SHA256? If yes, do I update the root, followed by the intermediate and finally the issuing servers.

    Many thanks for any help you can provide.

  15. After having done this separately does one have to change all the computer/user ETC certificate templates to issue SHA2 certificates and use the different provider or is all of that automatically done?

  16. Hi Adrian,

    I am using your article to migrate the SHA1 to SHA2
    using the above steps.

    Wanted to know but it might sound like a stupid question: What about certificates that were already issues with SHA1.
    Will they automatically renew/update?

  17. Thanks. I had Windows 2008 Server, which was issuing SHA1 Certificates, i need to generate SHA2 certificates.

    Steps, helped me in resolving the issue.

  18. The problem I have, is when I follow the instructions above Windows SBS 2011, It adds a certificat# 2, but it is still a SHA1 Certificate.
    What is going wrong?

    I could download a suggested crt file, but how to import that one?

    Thx in advance, Hans

  19. Hi All,

    How do i apply SHA-2 hashing algorithm for workstation 2008 R2 & 2012 R2, we have 100+ server which is not under Active Directory and we don’t use certificate authority.

    Please advice.

    Thanks,
    Venkat

Leave a Reply

Your email address will not be published. Required fields are marked *