Upgrade CA SHA1 to SHA2 (256) in Windows Server 2012 r2

Question

_{Thursday, April 5, 2018 5:56 AM}

HI

We have an internal CA hierarchy, which consists of a Windows 2012r2 server (Root CA) configured. Our current hasing algorithm is still SHA1 with Microsoft Strong Cryptographic Provider, which I need to upgrade to  (SHA256) if possible. We have been using the internal certificates for Windows Client and Mail access (mail.abc.com).

Also Clarify me, what happens to the already issued client certificate after the CA certificate is upgraded
 to SHA256?  I have read some article in this blog/forums said that the impact will not be there if you are not upgrade the Root certificate to SHA256. Will it possible If I want to renew the existing root certificates with the same SHA1 algorithm in future? or renew the root certificate with the same or new key to SHA256, it won't give any issue for my infrastructure.

Can anyone clarify what my options are to upgrade our CA infrastructure to support SHA256, and switch (if necessary) to a better provider?

Thanks 

All replies (3)

_{Thursday, April 5, 2018 3:58 PM}

Your primary step for SHA2 is to move private key from legacy CSP to CNG key storage provider: /en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn771627(v=ws.11)

Next steps are:

-- if it is root CA, then it is enough to enable sha2:

Certutil –setreg ca\csp\HashAlgorithm sha256

and restart CA service.

-- if it is subordinate CA, you will have to renew CA certificate with new key pair and submit request to parent CA that supports sha2 signing.

Vadims Podāns, aka PowerShell CryptoGuy
My weblog: www.sysadmins.lv
PowerShell PKI Module: PSPKI
Check out new: SSL Certificate Verifier
Check out new: PowerShell File Checksum Integrity Verifier tool.

_{Friday, April 6, 2018 12:03 PM}

Hi Ahmed,

"what happens to the already issued client certificate after the CA certificate is upgraded  to SHA256?"

Validation of the client certificate to the ca in a nutshell consists of decrypting the signature with the CA public key to retrieve the hash the CA made, reproducing the hash on the client certificate, and comparing the two hashes. If you have a pre-existing client certificate, of necessity the signature was made based on a SHA1 hash.

What happens after that depends on the way you perform the upgrade. If you reissue the CA certificate with the same keypair, the client will 'read' from the new CA certificate that it needs to reconstruct the hash with SHA256. Hashes will not match and verification will fail. If you reissue the CA certificate with a new keypair, you now have one certificate with the right public key and the right hash algorithm as attribute, and one with the wrong public key and the wrong hash algorithm. As long as you keep the two in your AIA and/or trust lists, you should be fine. It's known though that there are a few quirks. Nothing that can't be solved by reissuing the client certificate with the new CA certificate though.

_{Monday, April 9, 2018 9:18 AM}

Hi,

Just checking in to see if the information provided was helpful. And if the replies as above are helpful, we would appreciate you to mark them as answers, please let us know if you would like further assistance.

Best Regards,

Wendy

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].