SHA1 Key Migration to SHA256 for a two tier PKI hierarchy
Hello. Jim here again to take you through the migration steps for moving your two tier PKI hierarchy from SHA1 to SHA256. I will not be explaining the differences between the two or the supportability / security implementations of either. That information is readily available, easily discoverable and is referenced in the links provided below. Please note the following:
Server Authentication certificates: CAs must begin issuing new certificates using only the SHA-2 algorithm after January 1, 2016. Windows will no longer trust certificates signed with SHA-1 after January 1, 2017.
If your organization uses its own PKI hierarchy (you do not purchase certificates from a third-party), you will not be affected by the SHA1 deprecation. Microsoft's SHA1 deprecation plan ONLY APPLIES to certificates issued by members of the Microsoft Trusted Root Certificate program. Your internal PKI hierarchy may continue to use SHA1; however, it is a security risk and diligence should be taken to move to SHA256 as soon as possible.
In this post, I will be following the steps documented here with some modifications: Migrating a Certification Authority Key from a Cryptographic Service Provider (CSP) to a Key Storage Provider (KSP) -https://technet.microsoft.com/en-us/library/dn771627.aspx
The steps that follow in this blog will match the steps in the TechNet article above with the addition of screenshots and additional information that the TechNet article lacks.
Additional recommended reading:
The following blog written by Robert Greene will also be referenced and should be reviewed - https://blogs.technet.com/b/askds/archive/2015/04/01/migrating-your-certification-authority-hashing-algorithm-from-sha1-to-sha2.aspx
This Wiki article written by Roger Grimes should also be reviewed as well - https://social.technet.microsoft.com/wiki/contents/articles/31296.implementing-sha-2-in-active-directory-certificate-services.aspx
Microsoft Trusted Root Certificate: Program Requirements - https://technet.microsoft.com/en-us/library/cc751157.aspx
The scenario for this exercise is as follows:
A two tier PKI hierarchy consisting of an Offline ROOT and an Online subordinate enterprise issuing CA.
Operating Systems:
Offline ROOT and Online subordinate are both Windows 2008 R2 SP1
OFFLINE ROOT
CANAME - CONTOSOROOT-CA
ONLINE SUBORDINATE ISSUING CA
CANAME – ContosoSUB-CA
First, you should verify whether your CA is using a Cryptographic Service Provider (CSP) or Key Storage Provider (KSP). This will determine whether you have to go through all the steps or just skip to changing the CA hash algorithm to SHA2. The command for this is in step 3. The line to take note of in the output of this command is “Provider =”. If the Provider = line is any of the top five service providers highlighted below, the CA is using a CSP and you must do the conversion steps. The RSA#Microsoft Software Key Storage Provider and everything below it are KSP’s.
Here is sample output of the command - Certutil –store my <Your CA common name>
As you can see, the provider is a CSP.
If you are using a Hardware Storage Module (HSM) you should contact your HSM vendor for special guidance on migrating from a CSP to a KSP. The steps for changing the Hashing algorithm to a SHA2 algorithm would still be the same for HSM based CA’s.
There are some customers that use their HSM for the CA private / public key, but use Microsoft CSP’s for the Encryption CSP (used for the CA Exchange certificate).
We will begin at the OFFLINE ROOT.
BACKUP! BACKUP! BACKUP the CA and Private KEY of both the OFFLINE ROOT and Online issuing CA. If you have more than one CA Certificate (you have renewed multiple times), all of them will need to be backed up.
Use the MMC to backup the private key or use the CERTSRV.msc and right click the CA name to backup as follows on both the online subordinate issuing and the OFFLINE ROOT CA’s –
Provide a password for the private key file.
You may also backup the registry location as indicated in step 1C.
Step 2– Stop the CA Service
Step 3- This command was discussed earlier to determine the provider.
- Certutil –store my <Your CA common name>
Step 4 and Step 6 from the above referenced TechNet articleshould be done via the UI.
a. Open the MMC - load the Certificates snapin for the LOCAL COMPUTER
b. Right click each CA certificate (If you have more than 1) - export
c. Yes, export the private key
d. Check - Include all certificates in the certification path if possible
e. Check - Delete the private key if the export is successful
f. Click next and continue with the export.
Step 5
Copy the resultant .pfx file to a Windows 8 or Windows Server 2012 computer
Conversion requires a Windows Server 2012 certutil.exe, as Windows Server 2008 (and prior) do not support the necessary KSP conversion commands. If you want to convert a CA certificate on an ADCS version prior to Windows Server 2012, you must export the CA certificate off of the CA, import onto Windows Server 2012 or later using certutil.exe with the -KSP option, then export the newly signed certificate as a PFX file, and re-import on the original server.
Run the command in Step 5 on the Windows 8 or Windows Server 2012 computer.
- Certutil –csp <KSP name> -importpfx <Your CA cert/key PFX file>
Step 6
a. To be done on the Windows 8 or Windows Server 2012 computer as previously indicated using the MMC.
b. Open the MMC - load the Certificates snapin for the LOCAL COMPUTER
c. Right click the CA certificate you just imported – All Tasks – export
*I have seen an issue where the “Yes, export the private key” is dimmed after running the conversion command and trying to export via the MMC. If you encounter this behavior, simply reimport the .PFX file manually and check the box Mark this key as exportable during the import . This will not affect the previous conversion.
d. Yes, export the private key.
e. Check - Include all certificates in the certification path if possible
f. Check - Delete the private key if the export is successful
g. Click next and continue with the export.
h. Copy the resultant .pfx file back to the destination 2008 R2 ROOTCA
Step 7
You can again use the UI (MMC) to import the .pfx back to the computer store on the ROOTCA
*Don’t forget during the import to Mark this key as exportable.
***IMPORTANT***
If you have renewed you CA multiple times with the same key, after exporting the first CA certificate as indicated above in step 4 and step 6, you are breaking the private key association with the previously renewed CA certificates. This is because you are deleting the private key upon successful export. After doing the conversion and importing the resultant .pfx file on the CA (remembering to mark the private key as exportable), you must run the following command from an elevated command prompt for each of the additional CA certificates that were renewed previously:
certutil –repairstore MY serialnumber
The Serial number is found on the details tab of the CA certificate. This will repair the association of the public certificate to the private key.
Step 8–
Your CSP.reg file must contain the information highlighted at the top –
Step 8c
Step 8d– Run CSP.reg
Step 9
Your EncryptionCSP.reg file must contain the information highlighted at the top –
Step 9c– verification - certutil -v -getreg ca\encryptioncsp\EncryptionAlgorithm
Step 9d– Run EncryptionCsp.reg
Step 10
Change the CA hash algorithm to SHA256
Start the CA Service
Step 11
For a root CA: You will not see the migration take effect for the CA certificate itself until you complete the migration of the root CA, and then renew the certificate for the root CA.
Before we renew the OFFLINE ROOT certificate this is how it looks:
Renewing the CA’s own certificate with a new or existing (same) key would depend on the remaining validity of the certificate. If the certificate is at or nearing 50% of its lifetime, it would be a good idea to renew with a new key. See the following for additional information on CA certificate renewal –
https://technet.microsoft.com/en-us/library/cc730605.aspx
After we renew the OFFLINE ROOT certificate with a new key or the same key, its own Certificate will be signed with the SHA256 signature as indicated in the screenshot below:
Your OFFLINE ROOT CA is now completely configured for SHA256.
Running CERTUTIL –CRL will generate a new CRL file also signed using SHA256
By default, CRT, CRL and delta CRL files are published on the CA in the following location - %SystemRoot%\System32\CertSrv\CertEnroll. The format of the CRL file name is the "sanitized name" of the CA plus, in parentheses, the "key id" of the CA (if the CA certificate has been renewed with a new key) and a .CRL extension. See the following for more information on CRL distribution points and the CRL file name - https://technet.microsoft.com/en-us/library/cc782162%28v=ws.10%29.aspx
Copy this new .CRL file to a domain joined computer and publish it to Active Directory while logged on as an Enterprise Administrator from an elevated command prompt.
Do the same for the new SHA256 ROOT CA certificate.
- certutil -f -dspublish <.CRT file> RootCA
- certutil –f -dspublish <.CRL file>
Now continue with the migration of the Online Issuing Subordinate CA.
Step 1– Backup the CA database and Private Key.
Backup the CA registry settings
Step 2– Stop the CA Service.
Step 3- Get the details of your CA certificates
Certutil –store my “Your SubCA name”
I have never renewed the Subordinate CA certificate so there is only one.
Step 4 – 6
As you know from what was previously accomplished with the OFFLINE ROOT, steps 4-6 are done via the MMC and we must do the conversion on a Windows 8 or Windows 2012 or later computer for reasons explained earlier.
*When you import the converted SUBCA .pfx file via the MMC, you must remember to again Mark this key as exportable.
Step 8 – Step 9
Creating and importing the registry files for CSP and CSP Encryption (see above)
Step 10- Change the CA hash algorithm to SHA-2
Now in the screenshot below you can see the Hash Algorithm is SHA256.
The Subordinate CA’s own certificate is still SHA1. In order to change this to SHA256 you must renew the Subordinate CA’s certificate. When you renew the Subordinate CA’s certificate it will be signed with SHA256. This is because we previously changed the hash algorithm on the OFFLINE ROOT to SHA256.
Renew the Subordinate CA’s certificate following the proper steps for creating the request and submitting it to the OFFLINE ROOT. Information on whether to renew with a new key or the same key was provided earlier. Then you will copy the resultant .CER file back to the Subordinate CA and install it via the Certification Authority management interface.
If you receive the following error when installing the new CA certificate –
Check the newly procured Subordinate CA certificate via the MMC. On the certification path tab, it will indicate under certificate status that – “The signature of the certificate cannot be verified”
This error could have several causes. You did not –dspublish the new OFFLINE ROOT .CRT file and .CRL file to Active Directory as previously instructed.
Or you did publish the Root CA certificate but the Subordinate CA has not done Autoenrollment (AE) yet and therefore has not downloaded the “NEW” Root CA certificate via AE methods, or AE may be disabled on the CA all together.
After the files are published to AD and after verification of AE and group policy updates on the Subordinate CA, the install and subsequent starting of Certificate Services will succeed.
Now in addition to the Hash Algorithm being SHA256 on the Subordinate CA, the Signature on its own certificate will also be SHA256.
The Subordinate CA’s .CRL files are also now signed with SHA256 –
Your migration to SHA256 on the Subordinate CA is now completed.
I hope you found this information helpful and informative. I hope it will make your SHA256 migration project planning and implementation less daunting.
Jim Tierney
Comments
- Anonymous
October 27, 2015
Thanks for the article!
Just a quick mention, just before Step 2 you reference back to Step 1C - I don't see anything labeled Step 1C (or even Step 1).
Now, a question...
I'm running a three-tier PKI - Root (Offline), INT (Offline), CA (Online, issuer). I took a look at my Root and INT and the output of Certutil -store my "CANAME" for "Provider =" is already "Microsoft Software Key Storage Provider".
Can I just skip to Step 10 and do the SHA1 to SHA256 algorithm change and proceed from there?
Any info would be great! Thanks again. - Anonymous
October 27, 2015
Hi CompNerd84.
Thanks for the question.
Step 1C is in the actual TechNet article that I am referencing. It is the backing up the Registry key step. HKLMSYSTEMCurrentControlSetServiceCertSvcConfiguration
Right click - export.
If you are already using a KSP, (based on what you are indicating, you are) you can skip the conversion step and proceed to step 10. - Anonymous
October 28, 2015
Thanks for the clarification on Step 1C
And great news I can skip the conversion step! Makes my life just that much easier now!
Thanks again. - Anonymous
November 04, 2015
The comment has been removed - Anonymous
November 09, 2015
Hello bklyngy ,
Thanks for the question.
Migrating to SHA256 does not invalidate any existing certificates or crl's. Whenever the existing certificates get renewed in whatever way they are renewed (manual, AE), the new certificate procured will be SHA256 signed.
There is nothing to update on the certificate templates. - Anonymous
November 24, 2015
The comment has been removed - Anonymous
December 11, 2015
Hello Bala Ramchandar
Thank you for the kind words.
I am not understanding your first question. If you are asking will Microsoft stop customers internal CA's from issuing SHA1 certificates with an update of some kind, the answer is no. We are indicating that it would be best to stop doing that on your own.
For question number two, the answer is no. A CA can only do one or the other not both. If you need to support some applications that currently do not support SHA2 algorithms, I would suggest that you look into bringing up a new SHA256 PKI hierarchy alongside your current SHA1 PKI hierarchy. Slowly begin migrating SHA2 supported applications and operating systems over to the new hierarchy and only allow applications and operating systems that support SHA1 on the existing PKI hierarchy. - Anonymous
December 29, 2015
Thanks for the great article. Three questions that would help me greatly!
1. The step where you perform this command, Certutil –store my . Does it require you to shut down the CA and does it actually change anything or just export the configuration? I'm trying to do research to figure out how much effort the migration will be.
2. we currently have a single tier Root CA (AD integrated). the Root CA uses SHA-1. Is it possible to setup a subordinate underneath the Root CA that would issue SHA-256 certificates? The idea would be to allow both types of certs to be used temporarily. I'm assuming this is not supported as the Subordinate CA would have a SHA-1 cert and couldn't sign new SHA-2 certs. (figured I'd ask anyways.)
3. We are not currently auto-enrolling certificates at this time. I tried to go through others comments but just unclear, if I have existing SHA-1 certificates that are being used. I'm assuming they will work as expected after going through all these steps. We can then work to migrate them at will. we would just need to meet the the 1/1/2017 deadline or the obvious certificate expiration value right?
Thanks in advance! - Anonymous
January 16, 2016
Great post! What happens though now that you have 2 enterprise CAs registered in AD for the same forest/domain? How does auto-enrollment decide which onto use? - Anonymous
January 19, 2016
The comment has been removed - Anonymous
January 19, 2016
Hi shocko,
Thanks for the kind words. If you are migrating an existing PKI hierarchy you will not have multiple ROOT CA's and enrollment services objects in Active Directory. You will have the same objects as before, you are simply publishing new .CRL files and .CRT files for newly issued SHA256 signed certificates to chain to and validate. Existing SHA1 certificates will continue to work and be validated. When these SHA1 certificates are renewed via whatever method you use, the new certificate they receive will be SHA256 signed.
If you stand up a NEW PKI hierarchy side by side with the existing one, you will then have multiple enrollment services objects in AD. This setup is described in great detail here -http://blogs.technet.com/b/askds/archive/2010/08/23/moving-your-organization-from-a-single-microsoft-ca-to-a-microsoft-recommended-pki.aspx - Anonymous
February 18, 2016
I checked both my Root and Intermediate CA are KSP but the provider is SafeNet Key Storage Provider.What to do now.Please reply. - Anonymous
March 22, 2016
In a two tier PKI hierarchy, Can we only migrate Issuing CA from SHA1 to SHA256, leaving the offline Root CA as SHA1 and upgrading it a later time.