Microsoft Certification Authority conversion from SHA1 to SHA2

It has been discussed for a long time that certificates using the hash algorithm SHA-1 (Secure Hash Algorithm 1) for signing are starting to be considered insecure. Large companies (and web browser manufacturers) have agreed to restrict support for certificates with SHA-1. Simply put, all trusted CAs should issue certificates with SHA-2 from January 1, 2016, and certificates with SHA-1 should not be supported from January 1, 2017. More detailed information from MS Windows Enforcement of Authenticode Code Signing and Timestamping.

Google Chrome checks the certificates, including the certificate chain, the most. If a certificate has an expiration date after 2016 and it, or its authority, uses SHA-1, it is marked as insecure (there is also a warning for expiration in 2016).

We won't discuss whether SHA-1 is really insecure. I think the situation with vulnerable protocols (like SSL 3) and weak ciphers (using e.g., DES, MD5) that browsers should rather block (they do block some) is worse. The question is also the support for SHA-2 in various OSes and applications. Nowadays, however, there should generally be no problem.

If we use the internal certification authority from Microsoft, it's high time we adapt to these changes. Fortunately, the transition can be done quite simply and quickly, using the existing solution and maintaining backward compatibility. We can divide the whole problem into three steps, which can be independent.

• switching the hash algorithm on the authority for issuing certificates
• issuing a new certificate for the certification authority
• distributing the new CA certificate and removing the original one on clients

In this article, we're based on a topology with a two-tier hierarchy CA (Certification Authority). We have a standalone offline Root CA on a separate Windows server. It issued a certificate for the Intermediate CA, which is integrated into Active Directory. And this one issues user and server certificates according to various templates.

Switching the Hash Algorithm for Issuing Certificates to SHA-2

Verifying the Current Algorithm and Provider

If we have an older certification authority, it likely uses the SHA-1 hashing algorithm. We can check which algorithm we're using in the MMC Snap-in Certification Authority, by right-clicking on our authority and choosing Properties. On the General tab, in the Cryptographic settings section, we see the Hash algorithm used. MS CA uses the same algorithm for all certificates (we can't issue some with SHA-1 and others with SHA-2).

At the same time, we can see the Provider item here. It's important that it's Microsoft Software Key Storage Provider (KSP) or Microsoft Smart Card Key Storage Provider. These are Cryptography Next Generation (CNG), which support SHA-2. If it's Microsoft Strong Cryptographic Provider, we need to first migrate the CSP to KSP, as described in MS Migrating a Certification Authority Key from a Cryptographic Service Provider (CSP) to a Key Storage Provider (KSP).

We also see the authority certificate (there can be more than one), which we can display by clicking the View Certificate button and check the hash algorithm used for its signature.

Alternatively, we can use the command-line tool `certutil`, which will output the registry value where the algorithm is set:

C:\>certutil -getreg ca\csp\CNGHashAlgorithm
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Intermediate CA\csp:

  CNGHashAlgorithm REG_SZ = SHA1
CertUtil: -getreg command completed successfully.

Setting the Algorithm to SHA256

Changing the used algorithm is done simply by changing the registry, for which we can again use the `certutil` command-line tool.

C:\>certutil -setreg ca\csp\CNGHashAlgorithm SHA256
SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Intermediate CA\csp:

Old Value:
  CNGHashAlgorithm REG_SZ = SHA1

New Value:
  CNGHashAlgorithm REG_SZ = SHA256
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

Note: SHA-2 is a group of hash functions that include SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256. SHA-256 is often used, which we also use here.

Subsequently, we need to restart the CA (using the GUI or the command below) and we can check that the change has occurred in the CA properties.

C:\>net stop certsvc
The Active Directory Certificate Services service is stopping.
The Active Directory Certificate Services service was stopped successfully.

C:\>net start certsvc
The Active Directory Certificate Services service is starting.
The Active Directory Certificate Services service was started successfully.

All newly issued certificates will now use the SHA256 hash algorithm for signing.

Issuing a New Authority Certificate with SHA-2

By performing the previous step, we are now issuing certificates signed with the SHA-2 hash algorithm. In certain checks (e.g., Google Chrome), not only the algorithm of the certificate is checked, but also the certificate chain to see if it contains a certificate signed with SHA-1.

Note: From experience, it seems that the Intermediate certificates are checked, but the Root CA can use SHA-1.

Searching for the CA Certificate

Therefore, we need a new certificate for our certification authority. When a client checks a certificate to see if it is trusted for us, in most cases, the authority certificate is searched for using only its name (only with special settings is the ID searched for). So, when we issue a new authority certificate (with the same name), we can use it to verify previously issued certificates as well. We only need to replace it on the clients (or on the application servers when they send the certificate chain along with their own server certificate). If the client has both versions of the certificate, it depends on which one is found first. The issued certificate is always valid, but it may report an error that there is an SHA-1 certificate in the path.

Issuing a New Subordinate CA Certificate

In the case of a two-tier CA hierarchy, the first step is to turn on our offline Root CA. And change the hash algorithm to SHA-2, as described in the previous section.

Next, we issue a new certificate for the Intermediate CA. Official description Renew a subordinate certification authority. Using the MMC Snap-in Certification Authority, we right-click on our authority and choose All Tasks - Renew CA Certificate.

We get a prompt asking if we want to generate a new private key, which is usually not necessary.

In the next step, the request is created in a file at the root of the C drive, and in the case of an online authority, we can immediately send it. We take the request and use it on the Root CA. Using the MMC Snap-in Certification Authority, we right-click on our authority and choose All Tasks - Submit new request. If we have approval set up, on the Pending Requests, we choose Issue. We save the issued certificate to a file and transfer it to the Intermediate CA. Here we right-click on our authority and choose All Tasks - Install CA Certificate. When we look at the authority properties, we'll see one more certificate (and in its details, it's signed with SHA256).

The final question is whether to issue a new certificate for the Root CA as well, or if it's not necessary.

Distributing the New CA Certificate to Clients and Removing the Original

Distributing the Certificate Using Group Policy

Distributing the certificate of the certification authority to the Trusted Root Certification Authorities certificate store on clients is done simply using a GPO (Group Policy Object). The Enterprise CA automatically inserts its certificate into the Default Domain Policy. If necessary, we can manually enter it into any GPO in the path Computer/Policies/Windows Settings/Security Settings/Public Key Policies, either Trusted Root Certification Authorities or Intermediate Certification Authority Certificates.

Deleting the Certificate Using a Startup Script

As we mentioned, if the client has two certificates for the same CA, the system may sometimes use the old one. Therefore, the old certificate needs to be removed from the clients. However, this cannot be done standardly using GPO. There is an MS article How to remove a trusted Certificate Authority from computers in the domain, which seems unnecessarily complicated to me. Here we'll show the use of the `certutil` command-line tool, described in Certutil. To delete a certificate, the format is used (if it deletes the specified certificate, it displays information about it):

certutil -delstore CertificateStoreName CertID

There is just a slightly more confusing situation regarding certificate stores (Certificate Store). When we use the MMC Snap-In Certificates, we choose certificates for users, computers, or services. In the given location, we already see Personal, Trusted Root Certification Authorities, Intermediate Certification Authority Certificates, and others. When we add a trusted CA certificate, it's not even clear whether it's for a user or a computer.

But when we use the `certutil` command, we have to specify the correct store. The safest thing is to do the deletion in all stores. The stores are user, enterprise, grouppolicy, service, and computer (which is the default without a keyword). We also need to specify the location Root for Trusted Root Certification Authorities, CA for Intermediate Certification Authority Certificates, and My for Personal.

The second thing is the `CertID`, which the documentation states can be a variety of certificate (or CRL) attributes. I had success using the Thumbprint, whether with spaces (then used in quotes) or without. Deleting an Intermediate certificate (in all stores) can then look like this:

certutil -delstore CA "a0 03 a5 d4 fc 2e 5d 73 42 c3 f6 e2 fa b4 36 69 b1 7e c2 f5"
certutil -delstore -enterprise CA "a0 03 a5 d4 fc 2e 5d 73 42 c3 f6 e2 fa b4 36 69 b1 7e c2 f5"
certutil -delstore -user CA "a0 03 a5 d4 fc 2e 5d 73 42 c3 f6 e2 fa b4 36 69 b1 7e c2 f5"
certutil -delstore -grouppolicy CA "a0 03 a5 d4 fc 2e 5d 73 42 c3 f6 e2 fa b4 36 69 b1 7e c2 f5"

Such a simple script can be saved into a cmd file and a GPO with a Startup script created (Computer Configuration - Policies - Windows Settings - Scripts - Startup), which is applied to the container with the client computers.

Finally, some information: when we search (check) where our certificate is located, we can use the view of the content of a specific store, for example:

certutil -enterprise -viewstore CA

Or directly try to display information about a specific certificate (by Thumbprint) in a specific store. If it's found, it will display its details.

certutil -store -user CA "a0 03 a5 d4 fc 2e 5d 73 42 c3 f6 e2 fa b4 36 69 b1 7e c2 f5"