Upgrading Windows PKI from SHA1 to SHA2 // It’s always my problem

As I’m sure most of us know by now, SHA1 cryptography hashes have been increasingly under attack, and are now regarded as fully broken. In fact, my use of “now” kinda understates the point; you should be urgently looking to upgrade to SHA2 if you have any devices or servers using certificates.

If you’re not aware of these risks then please look around. There are some good introductory articles on the entrust website that talk about this issue, but please note that these articles are from 2014 and somewhat understand the urgency of the issue.

Upgrading your public facing websites and services that use public certificates (e.g. certificates you purchase from a public Certificate Authority, aka “CA”, online) is actually fairly easy; buy a new certificate from a competent supplier, install it, remove old certificate. Job done… (though as ever the devil is in the details).

For those who are running a Windows Certificate Authority (CA) to issue private certificates to servers and devices on your network, there is potentially a different problem: How do you ensure that your private CA is able to issue SHA2 certificates, and if not, how do you upgrade it so that it can?

I’m going to discuss the methods I use, which are designed for a Windows PKI infrastructure with several levels (a root CA and subordinate “issuing” CAs).

In a lot of ways, this really isn’t difficult at all. The steps you need to perform to actually complete the upgrade are extremely simple but the preparation you should carry out beforehand needs to be painstakingly done.

Prerequisites

I'm assuming that you're fairly knowledgeable and comfortable with manipulating certificates, and understand basic processes around managing private Windows CAs on your network. If this doesn't describe you then I strongly advise you to get help, hire a consultant if need be, before proceeding. While I'm actually quite confident that the processes I outline below are robust and that the articles I link to are good, well written articles from knowledgeable people, you will still to be able to understand the concepts we're talking about and be able to adopt instructions to your environment before starting the upgrade process.

First of all, you need to examine your environment. If you’re using Windows XP machines and Windows 2003 servers then you will have problems with SHA2 certificates. There is a hotfix available but if this describes your environment then certificate hashes are probably the least of your security worries. You should also review appliances and applications on your network that use certificates issued by your CAs and ensure that they can handle the update to SHA2. This should apply to most modern systems that are kept reasonably up-to-date, but “most modern systems” isn’t the same as “all”, so make sure you’ve checked this before starting work.

Ideally your Certificate Authorities should be running the newest version of Windows Server possible, and I’d strongly suggest a bare minimum of Windows 2012 to cover all bases. It’s perfectly possible to upgrade a 64-bit version of Windows 2008 server all the way through to Windows 2016 server if you need to. Whether or not you feel that’s a good idea is possibly another question, but you’ve hopefully kept your CAs isolated and free from other roles and that should help make upgrading the CA servers in place more viable.

If you’re using an older 32 bit version of Windows Server then you cannot upgrade directly to Windows 2012 or newer. If this is you, there is an article on migrating your CA to a new server on Technet which you can follow to upgrade to a modern CA.

I’d also suggest that CAs are a good candidate for virtualisation, which will make some of the operations I’m about to discuss easier, and in any case you don’t want your PKI infrastructure to die because of a dodgy hard drive in a server from 2006. My guides below assume you’re working with at least Windows Server 2012 (my examples were tested on Windows Server 2016) and that you’ve ensured that your Cryptographic provider is already upgraded to Microsoft Key Storage Provider.

To ensure that you’re ready to upgrade, go to each CA on your network, open the Certificate Authority Admin GUI, right-click on the CA name and select Properties.

Here we’re interested in two things. The Hash Algorithm is set to SHA-1 which means it needs upgrading, and the Provider is set to “Microsoft Strong Cryptographic Provider” (CSP), which means that you need to upgrade the provider to “Microsoft Key Storage Provider” (KSP).

Think of this as a two-step process if it helps explain the process: before you can upgrade the root certificate you need to upgrade the container that holds it.

I’m not covering how to upgrade from a CSP to a KSP in this article because there are plenty of wonderfully written articles out there which cover how to do both the CSP -> KSP and SHA1 -> SHA2 upgrades together and I wanted to offer something that had clear steps for people who were already at the KSP stage. I suggest following this Technet article on migrating from a CSP to a KSP if you need to update your cryptographic provider.

A typical installation

A typical Windows server based PKI setup should contain at least two CAs; a root CA which should ideally be offline (e.g. not a domain member and not part of the general network) and certainly should be as isolated and secure as possible) which is used to validate the other CAs on your network, and one (or more) issuing CAs which handle the task of receiving certificate requests and issuing certificates to users and workstations on your network.

To upgrade this kind of setup is a 6 stage process:

Upgrade the root CA cryptographic algorithm to SHA-2.
Use the upgraded root CA to issue a SHA-2 root certificate, and verify this certificate is correct.
Import the new SHA-2 root certificate into AD, ensure the subordinate CAs update their certificate stores, and can see the updated root certificate.
Upgrade the subordinate CA cryptographic algorithm to SHA-2.
Request new certificates for each subordinate CA from the root CA, and verify this certificate is correct.
Verify that new certificates issued by the subordinate CAs are fully trusted SHA-2 certificates.

The upgrade process itself.

Remember, we're only handling the SHA1 to SHA2 conversion here. If you also need to migrate your CA from a CSP to a KSP then please use this technet article.

Ensure that you have good backups of all your CAs taken using your backup software of choice. Do a test restore and make sure you’re happy with the quality of these backups (You can always use a test restore to an isolated VM to practice the CA upgrade process).

Note that following this process will leave you with SHA1 CA certificates sitting alongside your new SHA2 CA certificates on your CAs. This is fine, both certificates will be valid for the natural lifetime of the SHA1 CA certificate, at which point the SHA2 certificate will be the only valid one and can be renewed as normal in your own timeframes.

On the Root CA:

Ensure you can 'roll back' by backing up the CA.

To back up the CA database and root certificate itself, open an admin powershell prompt and run the following commands.

mkdir c:\CAUpgradebackup
$filepath = "c:\CAUpgradebackup\Backups"
$password = "MyPassword"

This creates the environment you will need to back up your CA configuration in a folder on your c drive named "CAUpgradebackup". You can (and probably should) customise both this file path and the password for your needs rather than just going with my defaults.

You are now ready to backup certificate database and certificates. All the commands here are carried out at your powershell prompt you created above.

certutil -p $password -backup $filepath

Then export your current CA service config from registry:

Reg export hklm\system\currentcontrolset\services\certsvc\configuration $FilePath\CAConfiguration.reg /y

And back up your CRLs (I’m assuming they’re published to the default file path here):

Copy-Item -Path "C:\Windows\System32\certsrv\certenroll\*.crl" -Destination $FilePath

You’ve now backed up your root CA. You can now navigate to the folder specified in $filepath above and verify that you have good data.

Upgrading the Cryptographic Algorithm

When you are sure that your backup was successful and you can recover data, you are ready to upgrade your cryptographic algorithm to SHA-2. If you are using virtual servers for your CAs, now would be a good time to take a snapshot, just in case.

Ensure the Certificate Server service is running
Carry out the upgrade by typing the command below into your powershell prompt:
```
certutil -setreg ca\csp\CNGHashAlgorithm SHA256
```
Stop, and then restart the Certificate Server service.

You can now verify the upgrade worked by opening the Certificate Authority Admin GUI, right-clicking on the CA name, and select Properties. CA KSP

You should see something similar to my example here, the provider should still read “Microsoft Software Key Storage Provider”, but the Hash Algorithm should now read SHA256.

With that done, you have just two things left to do on the root CA, update the root CA’s own CA certificate, and publish the certificate to AD.

To do the first part, simply cancel out of the properties dialogue we were looking at above, right-click the CA name again, and select “Renew CA certificate”. Follow this process, allowing the CA to stop, issue itself a new CA certificate, and restart.

You should now see a new certificate listed in the CA Certificates list. Select it and choose “View Certificate”. You should be able to see the new certificate issued as a SHA-2/SHA256 certificate, as per the example below. rootCA

Lastly, at least as far as the root CA goes, you need to upload this certificate to Active Directory in order for the subordinate CAs (and downstream clients for that matter) to be able to find this certificate in the chain when validating newly issued SHA2 certificates. If your root is ‘online’, e.g. connected to AD, this will happen automatically. If your root CA is offline then you will need to publish the root certificate to AD yourself. Rather than make this article longer than needed, I will simply point you at this serverfault article if you don’t already know how to do that.

On each Subordinate/Issuing CA in turn

Ensure that the new SHA2 certificate from your root CA is visible in the Local Computer's "Trusted Root Certification Authorities" store. You can use the Certificates MMC snap-in for this. If it is not visible, ensure you've published the root certificate correctly and from a command line use gpupdate /force to update the available certificates. Do not proceed until you have the updated root certificate available and you've verified that it shows as OK.

Ensure you can 'roll back' by backing up the CA.

To back up the CA database certificate, open an admin powershell prompt and run the backup commands we used earlier (see earlier instructions for detailed explanations for each step).

mkdir c:\CAUpgradebackup
$filepath = "c:\CAUpgradebackup\Backups"
$password = "MyPassword"

This creates the environment you will need to back up your CA configuration in a folder on your c drive. You are now ready to backup certificate database and certificates.

# backup the CA database and cert
certutil -p $password -backup $filepath
# export the CA registry configuration
Reg export hklm\system\currentcontrolset\services\certsvc\configuration $FilePath\CAConfiguration.reg /y
# backup CRLs
Copy-Item -Path "C:\Windows\System32\certsrv\certenroll\*.crl" -Destination $FilePath

Backup CA Templates (This is a new step for subordinate/issuing CAs)

certutil -catemplates | Out-File -FilePath "$FilePath\Templates.txt"

You’ve now backed up your subordinate CA. Verify that you have good data in the backup folder before proceeding.

Upgrading the Cryptographic Algorithm

Ensure the Certificate Server service is running
Carry out the upgrade by typing the command below into your powershell prompt:
```
certutil -setreg ca\csp\CNGHashAlgorithm SHA256
```
Stop, and then restart the Certificate Server service.

You can now verify the upgrade worked by opening the Certificate Authority Admin GUI, right-clicking on the CA name, and select Properties. CA KSP

You should see something similar to my example here, the provider should still read “Microsoft Software Key Storage Provider”, but the Hash Algorithm should now read SHA256.

With that done, you have just one thing left to do on the subordinate CA, update the CA certificate, and publish the certificate to AD.

To do this, simply cancel out of the properties dialogue we were looking at above, right-click the CA name again, and select “Renew CA certificate”. Follow this process, allowing the CA to stop, issue a certificate request which you can then fulfill on the root CA and then install the newly issued certificate on your subordinate CA.

Repeat this process for all subordinate/issuing CAs

Test your new certificate servers

You can now test your new SHA 2 pki infrastructure by logging on to a test workstation, opening the certificates MMC, ensuring the root and subordinate CA certificates appear in the Trusted Root Certification Authorities and Intermediate Certification Authorities sections for the local computer, and then going to personal certificates and renewing one of the certificates you see there. It should renew without errors, obviously, and show both signature algorithm and signature hash algorithm as SHA256.

I know this is along and drawn-out process, but it’s like a lot of things, the precautions usually aren’t needed but lets face it, if you ring up Microsoft and say “I just hosed all my CAs following a process that’s only semi-official at best, and don’t have a backup” they’re going to record the call, dub it over comedy “ommpah-ooompah” trombone noises and play it at the support Christmas party forever.