CA Renewal with a new key in EJBCA

[Sidxzx]

Hello,

I would like to understand how Certificate Revocation Lists (CRLs) and the certificates of end entities are verified when the keys and certificates of the issuing Certificate Authority (CA) are renewed in EJBCA.

Suppose I have the following setup:

• An Issuing Certificate Authority (CA) that publishes Certificate Revocation Lists (CRLs)
• End entity certificates issued by the Issuing CA
• A validation service to verify the issued end entity certificates by creating a certificate chain and checking the CRLs.

When I renew the CA on EJBCA without re-generating its key, everything continues to operate smoothly and certificates are validated correctly with no problems.

When I re-generate the CA keys, I experience problems when validating certificates issued with the old CA key against newly generated CRLs (signed with the new keys).

How this (rekey of CA) is usually handled in EJBCA ? Can I maintain two separate CRLs, one with the updated keys and one with the original keys ?

Thank you.

[primetomas]

CA renewal with re-key and CRLs is a tricky topic. Because of that the most common practice is to create a new CA instead of re-key an existing CA. That's why public Cas typically have "G2" (generation), "G3", etc. Avoids that complexity.

The default behavior of EJBCA is to only generate CRLs using the current CA signing key. If end entities does not have the new CA key, they can not verify that CRL naturally.
See "Microsoft CA compatibility mode" for information how to create multiple CRLs with current and old keys.
https://doc.primekey.com/ejbca/ejbca-operations/ejbca-ca-concept-guide/certificate-authority-overview/microsoft-compatible-ca-key-updates

[Sidxzx]

Hello @primetomas,

CA renewal with re-key and CRLs is a tricky topic. Because of that the most common practice is to create a new CA instead of re-key an existing CA. That's why public Cas typically have "G2" (generation), "G3", etc. Avoids that complexity.

Thank you for the information. Creating a new CA involves a significant amount of administrative and documentation work, so I am trying to avoid it if possible.

If end entities does not have the new CA key, they can not verify that CRL naturally.

If the end entities have the new certificate of the CA, will they be able to validate the CRL?

I performed some testing using OpenSSL and PDF signing (I used Adobe acrobat reader to verify the CRL), however, I was unable to verify the certificates against the new CRL.

$ openssl verify -crl_check -CRLfile NEWLY_ISSUED_CRL.crl -CAfile NEW_CA.pem -verbose BEFORE_REKEY_EE_CERT.pem
CN = SAMPLE BEFORE REKEY
error 3 at 0 depth lookup: unable to get certificate CRL
error BEFORE_REKEY_EE_CERT.pem: verification failed

Is it possible to rely on OCSP instead of the CRL until the existing Certificate Authority (CA) expires?

Thank you.

[primetomas]

OpenSSL error messages are always hard to understand what it means. Isn't it that the EE cert can't be verified by NEW_CA.pem? You probably need both CA certificates in this use case in order to verify both the CRL and the EE certificate.

OCSP can for sure be used, the client need to use KeyID instead of NameID in OCSP though, or also have the new CA certificate to verify OCSP responses signed by the new CA certificate. Similar on that case, the client need both the old and the new CA certificate.

Imho, the administrative burden for CA rekey is typically larger than creating a new CA, due to the inherent complexities. :-).

[Sidxzx]

OpenSSL error messages are always hard to understand what it means. Isn't it that the EE cert can't be verified by NEW_CA.pem? You probably need both CA certificates in this use case in order to verify both the CRL and the EE certificate.

Yes, I tried with both CAs certificates in the chain.

OCSP can for sure be used, the client need to use KeyID instead of NameID in OCSP though, or also have the new CA certificate to verify OCSP responses signed by the new CA certificate. Similar on that case, the client need both the old and the new CA certificate.

I have tested the EJBCA OCSP responder and received valid responses before and after the CA rekey, using OpenSSL OCSP commands. However, I haven't tried it with other clients, such as Adobe when signing a PDF.

Imho, the administrative burden for CA rekey is typically larger than creating a new CA, due to the inherent complexities.

Yes, I believe creating a new CA will be the best course of action, as it will save me from future headaches.

Thank you @primetomas