KB ID 0001243
It’s time to start planning! Microsoft will stop their browsers displaying the ‘lock’ icon for services that are secured with a certificate that uses SHA1. This is going to happen in February 2017 so now’s the time to start thinking about testing your PKI environment, and making sure all your applications support SHA2.
Note: This includes code that has been signed using SHA1 as well!
Below I’m just using an ‘offline root CA’ server, if you have multi tiered PKI deployments, then start at the root CA, fix that, then reissue your Sub CA certificates to your intermediate servers, fix them, then repeat the process for any issuing CA servers. Obviously if you only have a two tier PKI environment you will only need to do the root and Sub CA servers.
For your SubCA’s see PART TWO of this article.
Upgrade Your Microsoft PKI Environment to SHA2 (SHA256)
What about certificates that have already been issued?
We are NOT going to revoke any CA certificates that have already been issued so existing certificates will remain unaffected.
Here we can see my CA server is using SHA1
Note: If your server says the provider is Microsoft Strong Cryptographic Provider and not Microsoft Software Key Storage Provider then skip down a bit.
You may have multiple Certificates (that is not unusual).
Open a PowerShell Window (run as administrator), issue the following command;
certutil -setreg ca\csp\CNGHashAlgorithm SHA256
Restart Certificate Services.
net stop certsvc net start certsvc
Now you need to generate a new CA certificate.
Now you can see your new cert is using SHA256.
Mine Won’t Change From SHA1?
That’s because your cryptographic provider does not support higher than SHA1, for example ‘The command to change to SHA256 was successful, but the new certificate still says SHA1. If you look the Provider is set to ‘Microsoft Strong Cryptography Provider‘.
As you can see the strongest hash algorithm that supports is SHA1 that’s why it refuses to change.
How Do I Change the CA Cryptographic Provider?
Make a backup of the CA Settings and the CA registry Settings.
Backup-CARoleService –path C:\CA-Backup -Password (Read-Host -Prompt "Enter Password" -AsSecureString) TYPE IN A PASSWORD reg export HKLM\SYSTEM\CurrentControlSet\services\CertSvc c:\Reg-Backup\CAregistry.reg
Note: You might want to create the Reg-Backup folder first and grant some rights to it.
Now we need to delete the certificates this CA uses (don’t panic we’ve backed them up!) But first we need to find the certificate’s hashes to delete. Open an administrative command prompt, stop certificate services, and then issue the following command;
Note: ROOT-CA is the name of YOUR CA.
Stop-service certsvc Certutil –store my ROOT-CA >output.txt
Open output.txt then take a note of the hashes for the certificate(s)
Then Open an Administrative PowerShell window and delete them;
cd cert:\localmachine\my Del –deletekey <Certificate HASH>
Now we need to import the p12 file we backed up earlier, then export that as a PFX file. Change ROOT-CA to the name of YOUR CA and the path to your backup folder and certificate as approriate.
Certutil –csp “Microsoft Software Key Storage Provider” –importpfx C:\CA-Backup\ROOT-CA.p12 Certutil –exportpfx my ROOT-CA C:\CA-Backup\Exported-ROOT-CA.pfx ENTER AND CONFIRM A PASSWORD
Then restore the key from your PFX file.
Certutil –restorekey C:\CA-Backup\Exported-ROOT-CA.pfx
Now you need to import a couple of Registry files, in the examples below replace ROOT-CA with the name of your CA
Save the file as CA-Registry-Merge.reg (set the save as file type to All Files)
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\ROOT-CA\CSP] "ProviderType"=dword:00000000 "Provider"="Microsoft Software Key Storage Provider" "CNGPublicKeyAlgorithm"="RSA" "CNGHashAlgorithm"="SHA1"
Merge the file into the registry.
Repeat the process with the following regisry file save this one as CA-Registry-Merge2.reg
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\ROOT-CA\EncryptionCSP] "ProviderType"=dword:00000000 "Provider"="Microsoft Software Key Storage Provider" "CNGPublicKeyAlgorithm"="RSA" "CNGEncryptionAlgorithm"="3DES" "MachineKeyset"=dword:00000001 "SymmetricKeySize"=dword:000000a8
Now change the hashing algorithm to SHA256, open an administrative command prompt and issue the following two commands;
certutil -setreg ca\csp\CNGHashAlgorithm SHA256 net start certsvc
Renew the CA Cert.
You can now see the new cert is using SHA256.
Related Articles, References, Credits, or External Links
Great article! Especially the part where your CA does not change SHA1, if you allow me, I will post it on my blog in Spanish referring to your article
As far as I know this only works on Server 2012 (changing the cryptographic provider). Any workaroud for Server 2008 R2.
I’ve not tried with 2008/2008R2 but that’s getting a bit long in the teeth now, mainstream support for this stopped in 2015, why should Microsoft even bother trying to make this work?
Great Article. I’m about to go through this process on my environments. Any recommendation on testing this on a possible offline or dev environment? How would I go about re-creating my existing MS CA into a “dev” stack environment where I can test this?
Another idea i had was to run 2 local 2 tier CA’s in paralell (my existing prod CA) and my new CA. Does that work? I could not find any readings on google…(doesn’t seem like people have done that)? I’m simply trying to make this upgrade process less risky…
I just span up a test model in VMware before I did is ‘Live’. If you CA’s are physical P2V them int a sandbox environment and perform the upgrade on the replicas to test. If they are already virtual, either clone them or get a free trial of Veeam and use that to replicate the environment.
Hello Pete, great work. I never upgrade SHA1 to SHA2 256. i have a question i have a root CA only,and i have a auto enrollment configure on domain and CA, if i upgrade my Certificate SHA 256 will it impact on my users? or will it be no impact on domain and workstation it will pull the new certificate automatically?
No it wont impact, CA will just have both root certificates for a while 🙂
what will happen to existing certificates issued by the server after the upgrade to SHA1 to SHA2?
They work till they expire 🙂 unless something that uses them drops support for SHA1 of course!
Read two other articles and still had issues, multiple checkpoint removals later I found your article and I am up and running on SHA2 certs.
Good new glad you are fixed 🙂
Do we need to renew the Root CA is it mandatory? will it cause any issues with the existing certs?
I would say yes, you previous Root CA cert still stands, so certificates already issued will not be affected.
A really well done Step-by-Step article!
I had no issued while following the whole explanation including the “change cryptography provider” part.
Keep up your good work!
Thanks for the feedback!
Hello and thank you for this article. I tried without success to apply this to my sbs 2011 stardard server.
Do you think that it’s possible to change the “Microsoft Strong Cryptography Provider” to an anather provider SHA-2 compatible ?
To be honest it’s not something I’ve done, but I’ll publish the question in case someone wants to answer.
Great stuff! Just ran this on my CA when we moved our servers from 2008 R2 to 2016 CU8. Worked perfectly, well written.
Thanks for the feedback!
Very nice! Thank you.
Good article, Why are you using the same key pair?
Hi, you dont HAVE TO, but if you have granted a SubCA cert to something and forgotten about it (like VMware vCenter, or MCAfee HTTPS Proxy, or SourceFire, or a UTM, etc) then you wont get any dramas, a good engineer always expect something to go wrong 🙂
Congratulations on the article, very well detailed.
My question is do I have a PKI structure with Caroot on Sha1 and a subordinate on Sha2.
I need to migrate to Caroot for Sha2.
Certificates already issued and CA Subordinated will not be affected right? A new certificate will be generated when migrating to Sha2. But is the old one in Sha1 still valid? And the last question, after the migration from Caroot to Sha2 will be possible to issue certificates only in SHA2 or it will give the possibility of issuing in both sha1 and sha2.
I thank you for your attention.
Correct Certificates already issues will still be trusted 🙂
Thanks for the article. I’m in the planning stage for migrating the “Microsoft Strong Cryptography Provider” and after interrogating the CA using certutil I’ve noted that the “Private key is NOT exportable” on the CA certificate.
Are there additional considerations or steps I will need to follow?
Full disclosure: I didn’t stop the certsvc before I ran certutil. Will having the service running lock the key?
Why would you want to be able to export a private key with a CA Certificate?
I don’t want to export the private key. It’s more paranoia that when I attempt to run “certutil -exportpfx”, the “un-exportable” key will interfere with that process.
Hi, the CA cert HAS TO behave this way, some firms buy specialist devices to hold their CA’s private key, if that private key was ever compromised the entire PKI chain would be compromised, it’s the ‘thing’ that makes this whole system secure, that’s why it cant be exported, theres absolutely nothing to be ‘paranoid’ about. If you could export the CA’s private key then you should be extremely paranoid, because then you’d have the CA’s public and private keys on a machine that isn’t the CA. I can export my CA cert to pax, I just did it from the Certs MMC, Ive not tired using certutil, but I don’t see how that will behave any differently?
Thanks for the responses. Over the weekend, we attempted to do the conversion to KSP but we failed on the fist step:
Backup-CARoleService –path C:\CA-Backup -Password (Read-Host -Prompt “Enter Password” -AsSecureString).
The powershell error message indicated “Key not valid for use in specific state”.
We are currently investigating our options.
Hi. This article is very good. Thanks. I’m not very conversant with PKI. I understand that this thread is about migrating SHA1 to SHA2 but I have some applications in my environment that do not support SHA2. Can we issue SHA1 certificates after if we have migrated to SHA2
No! you should think about updating the applications! Most browsers now wont connect to SHA1 certs.
Active Directory Certificate Services did not start: Could not load or verify the current CA certificate. R & A CPAs Keyset does not exist 0x80090016 (-2146893802 NTE_BAD_KEYSET).
i went back through everything completed successfully i did have some troubles with the finding the correct store when exporting to output.txt. the import of pfx said it was successful.
Saved me a whole lot of stress.
Well written and easy to follow.
Thanks a lot!!!
For me it didn’t work.
I get an error at the end trying to start the CA services:
Ketset does not exist 0x80090016 (NTE_BAD_KEYSET)
hi daniele,did you manage to solve your problem?
Thanks – went through without any problems 🙂
Excelent Post, great support.
Ran this on 2012R2 box – Worked perfect! Big Thanks.
Notes: Should add new cert GPO after creation.
If still on a 2008 server (why) read, but you better of to backup and restore to a new role on 201x server
@PeteLong – I think it might be worth adding a note around where you re-issue the root CA certificate. Renewing the root certificate can cause all sorts of interesting issues in enterprise environments, for example where the existing root certificate is used to validate client certificates, after re-issue all new client certificates will be signed by a different root certificate that the system may not be aware of. I don’t think there’s any advantage to re-issuing the root CA cetificate, as root CA certs are not affected by the SHA1 vulnerabilities and SHA1 root certs will not cause errors in browsers, all it does is introduce risk. It would be much more important in my view to re-issue other certificates in your environment (intermediate certs and leaf certs) which you suggest not doing later in the article, as these are the certs actually impacted by the SHA1 issues. Article is nice and to the point though, like it!
We simply add an ‘additional’ CA certificate, the original remains where it is (well until it expires).
Well written, thank you. Note: we performed these CA adjustment steps on a Win2012R2. This server was in-place upgraded from Win2008R2 with the CA (SHA1 / MS Strong Crypto) on it several years ago. Those of you still with Win2008R2 – this does work. As other posts mention better the solution is to migrate this role to a newer OS when possible. Several years later now we have changed the provider and improved to SHA256 by following these steps. Again, thank you.
Thanks for the feedback!
Congrats dude! Just perfect explanation! No problems at all.
Big hug from Barcelona (Spain)
Thanks of the feedback!
Great! Thanks for sharing the steps.
Could you please help with next after upgrade to SHA256, I mean what to do with SHA1 Certificate which are still showing in Certmgr and unused certificate, shall we delete those or keep remain there?
No leave them there, until either they expire, or you know for a fact that all certs stamped with the old CA cert are removed/expired.
Really great! Thank you!
Thank you very much. Great article with detailed info. It shouldn’t be this hard, but with your help was manageable.
Thanks for the help updating the Microsoft Windows 2012 R2 CA. KSP + SHA256 = success.
But now I’m seeing “Invalid” when completing new certs on my Exchange 2013 CU23 server. Exchange creates the request as before, we copy to the CertSrv webpage, and are given a .CER file. It loads into Exchange, but shows “Invalid!”
How to complete the task of making Exchange 2013 comply with the SHA2 requirements now in IOS and modern browsers?Robert
This sounds like the Exchang server does not trust your CA?
Really Great Article.
This has helped us migrate our Root CA to SHA2
Thank you Pete.
You’re most welcome – thank you.
So I too had issue with not being able to export the private key and NTE bad key state and so on. What saved me is that I already had an older p12 backup of the current certificate with the private key.
I did everything (well not everything. If you do a backup from the CA MMC, it’ll let you but tell you some keys couldn’t export [this is actually a problem] and finish) I kept going with all the steps but noticed in personal for local computer context, the Root-CA cert was still there. IMPORTANT NOTE: I had a previous export of this current cert and Private key from a recent migration already! I removed this via the MMC. Then I could import it just fine, restored the private key just fine, did the rest of the steps and it worked!
Now to breath and do this in production. I know that best practice is not to have a DC do this roll but that’s what I’ve inherited and have to work with.
I had a question about some of our templates that are published – with clients auto-enrolling for them. Some of them are still set to SHA1. Should I go through and update any that I can change from SHA1 and SHA256 or duplicate any template that are using Legacy Cryptographic Service Provider, and mark them to use Key Storage Provider, RSA, key size, and then SHA256?
Your site has been a wonderful resource in my 2008R2 to 2019 migration. Thanks!
I typically like to clone the templates anyway, so yes that seems like a sensible approach. Thanks for the feedback!
What’s interesting is that those existing templates that were originally set as SHA1 and that clients are auto-enrolling against are getting signed as SHA256 now. I may just leave things alone. *shrugs shoulders*
Great Job!! :), I did the step by step and it working.