PKI chain-up, what is this?

Maintaining the PKI chain-up makes sense when renewing certificate, once again if the private key is not compromised.

Why this reminder?

Some people claim never to have heard of this PKI chain-up mechanism, while they participate in the renewal operation … because managing PKI is a job which requires real skills and experience maybe.

When renewing a root Certificate Authority (CA) with the same key pair, it’s essential to understand the chain of trust and how it impacts the renewal process.

The PKI chain-up of trust ensures that certificates issued by the CA are trusted by relying parties.

If I may, when renewing a Root CA certificate, all of us need to consider how the new root certificate will be trusted and how it will be linked to the previous one.

How to perform RootCA renewal?

Here’s a step-by-step guide viable related to the Root CA certificate renewal operation and what PKI chain-up mechanism is:

1. Backup the existing Root CA key pair and certificate: this is mandatory before you start. Ensure that you have a secure backup of the existing root CA private key and certificate. This precaution is crucial for an eventual roll back operation (we must think about disaster recovery every time from my perspective).

2. Generate your CSR (Certificate Signing Request): create a CSR for the root CA using the existing private key. This CSR will contain the updated information for the root CA certificate, such as a new expiration date.

openssl req -new -key root-ca-private-key.pem -out root-ca-renewal.csr

3. Submit CSR for renewal: submit the CSR to your CA software or service for renewal. Follow the instructions provided by your CA software vendor for this process.

4. Issue and receive the renewed Root CA certificate: once the CSR is processed, you will receive the renewed root CA certificate from your CA software or service. Ensure that you receive it securely.

5. Establish a chain of trust (create the PKI chain-up): to maintain trust continuity, establish a chain of trust between the old and new root CA certificates. This allows certificates issued by the old root CA to remain trusted until they expire while enabling new certificates to be issued under the new root CA.

6. Cross-signing: Sign the new root CA certificate with the old root CA’s private key. This creates a cross-signing relationship between the old and new root CA certificates.

openssl ca -in root-ca-renewal.csr -out root-ca-renewal.crt -extensions v3_ca

This command signs the CSR with the old CA’s private key, creating the renewed certificate. The -extensions v3_ca option is used to indicate that it’s a root CA certificate.

Steps 2 to 6 can be done easily in the Microsoft ADCS environment. These steps are totally transparent. The technical gestures are very simple in this case, but it’s always important to understand the basic mechanism. Go to basics.

7. Update trust anchors: ensure that the new root CA certificate is added to trust stores on systems and devices where it’s used. The trust anchors should include both the old and new root CA certificates. For example, radius appliances in case of implementation of 802.1x protocol and so on.

Without this precision, you run the risk of bringing production to a standstill and beginning a lengthy dichotomous investigation.

Renewing Root CA in a Microsoft environment stills straightforward since automatic update is generally activated. Auto-enrollment protocol is clearly like EST or ACME and whatever, in a few words it means deployment automation protocol.

8. Monitor transition period: During the transition period when both the old and new root CA certificates are in use, please monitor and manage certificate issuance accordingly. Existing certificates issued under the old root CA should be allowed to expire naturally, while new certificates can be issued under the new root CA.

This stage requires a good knowledge of his own architecture to determine which components need renewed authority deployed.

9. Remove expired Root CA: once all certificates issued under the old root CA have expired or been replaced, you can consider removing the old root CA certificate from trust stores.

Synthesis

By following these steps, you can smoothly renew a root CA certificate with the same key pair while maintaining trust continuity. It’s essential to carefully plan and manage the transition to ensure that certificates remain trusted throughout the renewal process.

Usually, renewing the CA certificate with the same key pair doesn’t impact the PKI trust chain-up validation process that your PKI clients use for validating previously issued and newly issued certificates.

All previously issued certificates automatically chain-up to the old CA certificate and all newly issued certificates automatically chain up to the new CA certificate.

This process is possible thanks to the Subject Key Identifier (SKI) in the CA certificate, and the Authority Key Identifier (AKI) and Authority Information Access (AIA) fields in each of the certificates a CA issues.