Share via


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

clip_image001

ONLINE SUBORDINATE ISSUING CA
CANAME – ContosoSUB-CA

clip_image003

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.

clip_image005

Here is sample output of the command - Certutil –store my <Your CA common name>

As you can see, the provider is a CSP.

clip_image006

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 –

clip_image008

clip_image010

Provide a password for the private key file.

clip_image012

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

clip_image014

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>

clip_image016

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.

clip_image018

***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 –

clip_image020

Step 8c

clip_image022

Step 8d– Run CSP.reg

Step 9

Your EncryptionCSP.reg file must contain the information highlighted at the top –

clip_image024

Step 9c– verification - certutil -v -getreg ca\encryptioncsp\EncryptionAlgorithm

Step 9d– Run EncryptionCsp.reg

Step 10

Change the CA hash algorithm to SHA256

clip_image026

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:

clip_image028

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:

clip_image030

Your OFFLINE ROOT CA is now completely configured for SHA256.

Running CERTUTIL –CRL will generate a new CRL file also signed using SHA256

clip_image032

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”

image

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.

clip_image035

*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

clip_image037

Now in the screenshot below you can see the Hash Algorithm is SHA256.

clip_image039

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 –

clip_image041

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.

clip_image043

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.

clip_image045

The Subordinate CA’s .CRL files are also now signed with SHA256 –

clip_image047

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.