Lost access to your Root CA in your 2-Tier PKI? Don’t worry, Use Cross Signing to Recover!
Hello, this is Byron from the Microsoft Directory Services Support team. Today, I’d like to share information about an alternative recovery approach for Public Key Infrastructure (PKI) environments. Consider a scenario where the Root Certification Authority (CA) is permanently lost—for example, due to accidental deletion of the Root CA virtual machine, or the system entering an unrecoverable no-boot state without a valid backup. In some cases, there may be no backup of the Root CA’s private key or database, leaving no traditional path to restoration. In such cases, the supported and recommended recovery method is to rebuild the PKI hierarchy from scratch. However, for extremely rare and critical situations where this is not feasible, there is an alternate recovery method that may allow partial restoration and continuity. This approach is intended only as a last resort, and should only be considered when no supported recovery options remain. While not a replacement for proper backup and disaster recovery practices, this fallback method may help reduce downtime and effort in extreme cases. How If it is a two-tier PKI, and the Intermediate CA Server is the one issuing certificates to the environment, and we still have access to the Intermediate CA Certificate with private key, we can build another Root CA, and “link” the Intermediate CA Server to the new Root CA. The steps are simple, just renew the Intermediate CA server with “Same Key pair” with this new Root CA. A high-level diagram below: In fact, this is like the Concept of “Cross Signing”; the newly issued Intermediate CA Certificate could be considered as a “Cross Certificate” as well. Cross Signing is typically used to make one PKI hierarchy chains up through another hierarchy, even when originally it was not configured that way. This technique is designed for a leaf certificate to build a different certificate verification chain, in case one of the chains fails, allowing certification verification to succeed. Cross signing is also used by public CA companies to start their business which we will discuss more in a later section. Here are detailed steps on how to do this: On the Intermediate CA Server. Open the Certification Authority Management Console. Right click on the CA Name node -> All Tasks -> Renew CA Certificate. Renew Intermediate CA server with “Same Key pair” to create the Certificate renewal request file: Submit the certificate request file (.req) on the newly Deployed Root CA Server, issue it, and go to: Issued Certificates node-> Right click on issued Certificate -> All Taks -> Export Binary Data… -> Save as .cer file. Copy this .cer file to the Intermediate CA. On the Intermediate CA Server. Install the newly issued Intermediate CA certificate issued by the new Root CA. The existing issued Leaf Certificates verification should continue to work and chain up to the new Root CA. We can use command Certutil -urlfetch -verify c:\certificate.cer > certificate.txt to export the certificate verification and chain build information. Previous Chain: Leaf certificate: 5700000006d907d38be599e05a000000000006 Issuer: CN=ContosoRootCA01,DC=contoso,DC=com (Previous corrupted Root CA) Current Chain: Leaf certificate: 5700000006d907d38be599e05a000000000006 Issuer: CN=ContosoRootCA02,DC=contoso,DC=com (New built Root CA) How and Why So exactly what is “Cross Signing”? Let’s see the following story (I found this story online): A long time ago (maybe not that long 😊), there was a Certification Authority company called LetsEncrypt. When they started their business, they generated their own 'ISRG' Root CA Certificate (ISRG Root X1). However, it takes time for the industry to accept new Root Certification Authorities. They could not wait that long to start their business, as this might have taken years. They deployed an Intermediate CAs first (LetsEncrypt X3 and LetsEncrypt X4) and used a popular public Certification Authority (DST Root X3) to sign those Intermediate CA Certificates. This allowed them to start their business immediately and issue Leaf Certificates to customers without waiting for the world to accept their own Root CA. So, the Certificate Chain back then was DST Root X3 --> LetsEncrypt X3 / LetsEncrypt X4 --> Leaf Certificate. After 5 years of hard work, the market accepted their Root CA (DST Root X3) and added it to all kinds of products’ Trusted Root. They signed their Intermediate CA certificates with their own Root CA. Now, another chain is available: ISRG Root X1 --> LetsEncrypt X3 / LetsEncrypt X4 --> Leaf Certificate. How come the same Intermediate CA can be chained up to different Root CAs? The magic trick is the Intermediate CA Certificate kept the “Same Asymmetric Key Pair” when it got signed by both DST Root X3 and ISRG Root X1. As you can see from the above screenshots, the issuer is different, and they are two different intermediate CA certificates, but the trick here is the Same Key Pair, even though they were signed by different Root CA’s, aka “Cross Signing”. Another key point here is not all Certificate Chains rely on the AIA path. Another common Certificate chain build method is Key match using AKI/SKI and PKCS#7 which means the server side sends both Leaf Certificate along with Intermediate CA to the client for verification, Client does not need to build chain to Intermediate using AIA. You can refer to this document for more information about this story: https://scotthelme.co.uk/cross-signing-alternate-trust-paths-how-they-work/ There is another “Cross Sign” method targeting the Root CA Certificate itself. The concept is a little bit different: Using one Root CA Certificate to sign another Root CA Certificate. What is the usage scenario? Why do we need this? Scenario 1 Here is a story: In a large corporation, deploying Root CA certificate to all devices might be challenging. It could be time-consuming and might take a lot of administrative effort. Therefore, during the time periods when large corporations renew their Root CAs, they must find a way for newly issued Certificates under the renewed Root CA start to work as soon as possible. The idea is to sign the new Root CA certificate using the old Root CA Certificate, so the chain could be: leaf Certificate --> Intermediate CA -> New Root CA (Signed by Old Root CA)--> Old Root CA. Because devices should trust Old Root CA already, the new Leaf Certificate works immediately after renewal without waiting for new Root CA Deployed to all devices. Scenario 2 Another scenario is once the New Root CA is deployed to the environment, the company wants to remove the old Root CA certificate from the Devices’ trusted Store for company policy reasons. How can the existing Certificate continue to work if they are not yet expired and issued by old Root CA Certificate? The solution is also Cross Certificate: Create a CA Certificate with old CA key pair but signed by the new Root CA Certificate. The chain build would be below: Existing Issued Leaf Certificate --> Intermediate CA --> Old CA Certificate (cross signed by new Root CA) --> New Root CA. In fact, Active Directory Certificate Service supports this and will generate Cross Certificates by default when renewing a Root CA with a new key. Remember that when we renew the Root CA, there will be two additional CRT files called XXXXX (0-1).crt and XXXXX(1-0).crt. These certificates(.crt) are Cross CA Certificate’s. (0-1) is the New Root CA Certificate signed by Old Root CA Certificate. (1-0) is the old Root CA Certificate signed by new Root CA Certificate. They are used for the above Scenario 1 and Scenario 2 As you can see, the Root CA Certificate has an AKI (Authority Key Identifier), which means it was signed by a CA and an SKI (Subject Key Identifier) that matches it. Of course, in Active Directory, we rarely see the deployment of the Cross Certificate, because for Windows devices, the Active Directory is sufficient to quickly deploy new Root CA Certificate to Windows domain members. Summary The common method to perform PKI disaster recovery when the CA private key and database cannot be restored involves rebuilding the entire PKI Hierarchy PKI from scratch, and replacing every single certificate used by applications and servers. While the common method mentioned above is still valid, the “Cross Signing” method illustrated in this blog offers an alternative quick method to recover our PKI Hierarchy. This could potentially save us from spending a lot of disaster recovery time & administrative effort 😊.
