SHA-1 is broken, and there is bold moves from Microsoft to move away from SHA-1 after announcing their deprecation plan for SHA-1 on November 2013. If you want to know the whole story about SHA-1 and why it is being phased out by everyone, then read this blog post [PKI Certificate Services SHA-1 Deprecation]
I spent sometime reading and understanding the answer of the following questions:
- SHA-1 is broken, So what shall I do? [Continue reading]
- What makes a CA capable of issuing certificates that uses SHA-2? [Read my previous blog post]
- What is the deadline for SHA-1 support and what about comparability issues? [Read my previous blog post]
Healthy Enterprise PKI infrastructure
Before jumping into how to migrate to a SHA-2 ready PKI infrastructure, I want to help you picture a healthy PKI infrastructure that will not be affected by the deprecation plans of SHA-1.
Microsoft’s SHA-1 deprecation plan affects the following for Enterprise PKI deployments:
- SSL and Code Signing – end-entity certificates >> these should be SHA-2 and code signing certificates should be time-stamped.
- Intermediate CA certificates >> the certificate for the CA server acting as intermediate CA server.
Saying that, the below are not affected by Microsoft’s SHA-1 deprecation plan, and can keep using SHA-1:
- The Self-Signed Certificate of the Root CA server: So only the self signed root CA server can keep using SHA-1. Microsoft said “The SHA1 deprecation policy does not impact SHA1 privately deployed root certificates, because Windows relies on other means to validate root certificates besides the signature” . Google Chrome will not issue warning also for privately deployed root CA certificates.
- Al self signed certificates : for the same reason self signed root CA certificate is excluded from the deprecation policy.
Let me give you an example. If you have an Offline Root CA server and an online Issuer CA server (Intermediate) that produces end-entity certificates, then this two-tiered private PKI deployment should look like this to comply with SHA-2 and avoid any interruption caused by Microsoft’s SHA-1 deprecation plans:
- For the Privately deployed Root CA server:
- The Root CA Certificate that is self-signed can be either use SHA-1 or SHA-2 as it is not affected by SHA-1 deprecation plan.
- When the Root CA server signs a CRL, or signs a certificate request, this signing operation should be performed by SHA-2
- According to the previous point, the Root CA server should be able of performing SHA-2 operations even if its self-signed certificate is using SHA-1
- In order to do signing operations using SHA-2, the Root CA should be using cryptographic provider that supports SHA-2 (i.e Microsoft Key Storage Provider)
- For the Intermediate Issuing CA server:
- The CA certificate itself should be using SHA-2.
- Any signing operation done by the server should be done with SHA-2.
- In order to do signing operations using SHA-2, the issuing CA should be using cryptographic provider that supports SHA-2 (i.e Microsoft Key Storage Provider)
- For end-entity SSL and Code Signing Certificates
- Should be using SHA-2 and the certificate chain should be using SHA-2 except for the root CA certificate, as the root CA certificate can use SHA-1 or SHA-2
- For code signing certificates, a time-stamp should be included to validate the signature.
I guess it is wise to start from now, and to prepare your self so that you will not be affected by Microsoft deprecation plan for SHA-1. I also get to know that many big companies are requiring SHA-2 certificates for their systems from now. VMware is one of them for sure.
The time you spent in designing and planning the migration now, will pay off for many years. I read once that PKI is a 90% designing science, and 10% doing and implementing. So let us start by describing our migration plan. I will do my migration plan on two tiered PKI infrastructure (Offline root CA and one intermediate issuer CA). The same applies if you have more tiers.
Approach 1 : “Side by Side , different Root CA”
Keep your current PKI infrastructure as is, and deploy a parallel PKI infrastructure (on Windows 2012 R2 perhaps) that uses only SHA-2 for issued certificates and for CA certificates. Start issuing new certificates from the new hierarchy and re-issue SSL certificates from the new hierarchy.
You will have here two Root CA servers. Enterprise subscribers and relying parties will need to trust both roots during the migration. The benefits of this approach is that you can carefully and slowly migrate applications to a new SHA-2 based PKI in a controller manner. Finally, when all subscribers, relying parties and applications have migrated, the old SHA-1 based PKI can be decommissioned.
In this way, you could keep your old PKI hierarchy to support legacy applications and devices that is not SHA-2 ready, while supporting SHA-2 completely in the new hierarchy.
It is worth mentioning that you have to create a separate enterprise Certificate Policy (CP) for the adoption of SHA-2 and the discontinuation of SHA-1 hashing algorithm.
Approach 2 : “Side by Side , Same Root CA”
In this approach, you will do side by side for intermediate CA servers, but you will keep the same Root CA.
Idea is simple. Root CA self signed certificate is not included in Microsoft’s deprecation plan for SHA-1, and Google Chrome will not give warning for that. Just keep the self signed root CA certificate without any modification.
In Parallel, create a new Intermediate Issuer CA (recommendation is to install the CA on Windows 2012 R2) that is capable of issuing SHA-2 certificates and that uses SHA-2 for its CA certificate itself.
Certificates issued from the new Intermediate Issuer CA, will use SHA-2, and will chain up to SHA-2 intermediate. It does not matter if it chained up to SHA-1 root CA.
First, you should upgrade the O.S version of your Root CA to Windows 2012 R2. This is highly recommended to enable the CA to perform CRL signing later using SHA-2 and to migrate to a storage provider that supports SHA-2. You can find the details of how to upgrade your Root CA server to Windows 2012 R2 in this blog post.
You are still safe if your Root CA is running Windows 2008 R2. Next you have to check the Cryptographic Provider for your Root CA, and make sure it is supporting SHA-2. Although the root CA certificate itself can be signed with SHA-1, the Root CA still needs to sign the CRL and the new Intermediate CA with SHA-2. You can know more about how to check the CA cryptographic provider SHA-2 support and how to upgrade to a provider that supports SHA-2 in this blog post. Now you have your Root CA supporting SHA-2.
Second, install a new Intermediate Issuer CA (Windows 2012 R2 is recommended), with SHA-2 CA certificate, and make sure the CA uses SHA-2 for issuing end-entity certificates.
Note: if your CA is using cyrptographic provider that supports SHA-2, you can configure your CA to issue SHA-2 certificates by running:
certutil -setreg ca\csp\CNGHashAlgorithm SHA256
If you use the Side by Side Same Root CA approach, and you configure the root CA to use SHA-2 as part of the plan, note that the CA also signs CRLs using the new algorithm. So in case your CA had issued certificates that are validated by applications that don’t understand SHA-2 and in case those apps check CRLs, then those applications would fail.
My recommendation is to use the side by side migration with different Root CA, so you will build a completely separated PKI infrastructure and gradually phase out the old PKI infrastructure.
- PKI Certificate Services SHA-1 Deprecation
- Upgrade your Root CA to Windows 2012 R2 – PKI
- SHA-2 Support – Migrate your CA from CSP to KSP
- What makes a CA capable of issuing certificates that uses SHA-2?