What happens when an Intermediate CA is revoked?

Question

Currently I’m working on a certificate manager that allows our product to securely connect to remote web services (over TLS/SSL). For security, we use Certificate Revocation List checking (or CRL-checking) to find out whether a certain certificate has been revoked. Still, some issues are unclear to me:

• Must/should I fetch all CRLs of the complete chain to check the certificate’s validity?
• What should I do when an Intermediate CA is revoked? Will all its certificates be added to the CRL as well? Can the certificate be replaced by a new (uncompromised) version?

Answer 1

Must/should I fetch all CRLs of the complete chain to check the certificates validity?

Absolutely. A CA builds a CRL only for the certificates it issues. Status of the CA itself must be checked via the CRL of the issuing CA. Note: This is a recursive search. When writing code, or testing systems, remember that there can be more than one "generation" of issuing CAs and check all certificates except the self signed root. A root CA will not have an associated CRL - if the root is compromised, that root must be manually removed from any trust stores.

What should I do when an Intermediate CA is revoked?

Do not trust anything signed by the CA. A certificate is only as good as the CA that issued it. If the CA is becomes untrustworthy, the certificates issued by that CA are no longer trustworthy.

Do not expect to get a CRL from the revoked CA saying that all certificates issued by the CA are not valid. If the CA is active, this will create a prohibitively large CRL that will be extremely painful to transport, parse, and generally do anything with. Also - if the CA's key has been lost - it may not be possible to create this CRL.

In practice, the smart thing would be to remove the CA from any trust stores. Removing the CA from trust stores will cause any application that builds it's CA chain from trust stores to fail the certificate verification quickly. Building the certificate chain is usually done prior to any OCSP/CRL checking, so you save your application from extra steps and potentially bandwidth by trimming the revoked CA from your stores.

An intermediate CA being revoked is also a fairly major event - honestly, I've never experienced it in the real world. If I was working on a highly secure system, I'd also publish as far and wide as I could that the CA was revoked. Particularly any systems that may be working off CRLs that are cached for a long time.

And if I held certificates signed by this CA, I'd start formulating my re-certification strategy ASAP.

Will all it's certificates be added to the CRL as well?

No. Note, there are two different CRLs in play: - the issuing CA's CA (either a root CA or another CA in the chain) - issues a CRL which verifies the status of the issuing CA's cert - the issuing CA - issues a CRL which verifies the status of the certs this CA has issued.

If you have a CA chain that is n certificates from root to end entity, you will have n-1 CRLs involved.

Can the certificate be replaced by a new (uncompromised) version?

Yes... sort of. The compromise reflects the untrustworthiness of the private key of the CA. The CA will need a new private key, which essentially makes it a new CA.

It is, technically, possible to rename the CA with the same Distinguished Name - if there is an operational value to that. But in practice, my temptation would be to standup a new CA, with a new DN, just so that all humans were clear on the difference.

This will be a major pain in the rear end. The users of the new CA will need to: - remove the compromised cert, and replace it with the new CA cert - recertify all End Entity certificates with certificates that are signed by the new CA.

Note that it's a matter of security policy as whether you recertify or rekey your end entities. If the compromised system did not have access to the private keys of any end-entities, you can re-sign the same private key with a new CA key. If you kept a store of certificate requests on file, you could resubmit them to the new CA and save yourself a whole bunch of key generation.

However, in some cases, the CA system may put some private keys in escrow - this means that in some central location (usually near the CA system), the private keys are stored securely in case the users loose their keys and need an update. This is particularly prevalent in the case of encryption certificates, since you may need to retrieve encrypted data even after an encryption key has been revoked.

In these cases, if the CA is compromised, there's a decent chance the key escrow has been compromised. That means that all users of keys in the escrows should generate new key pairs and request a new certificate.

Past that - its a matter of policy as to whether re-certification is allowed. Since a new certificate will have a new validity period, it may be that the security powers that be say "no renew/recertification" because they can't limit the validity period sufficiently.

Answer 2

Yes, you should fetch all CRLs for all certificates in the chain. A certificate can be deemed usable for any purpose, including verifying other certificates, only if it can be plugged at the end of a valid certificate chain and its revocation status has been ascertained. Of course, a CRL must not be trusted unless its signature can be verified with regards to an authorized public key, which may imply some extra certificate chains as well.

A certificate being revoked means that its contents are not to be considered usable. Revocation can be seen as a "cancel order" on the cryptographic signature which has been added to the certificate by the issuing CA: "this signature must not be considered as valid, even though mathematically it looks good". You could also consider the revocation as a supersede on the certificate end-of-validity date.

If an intermediate CA certificate is revoked then it becomes unusable. You cannot use it as part of a chain. So, if you want to validate one of the certificates which that CA has issued, then you will need to find another intermediate CA certificate, with the same CA name and key, and which is not revoked.

A certificate may be revoked for arbitrary reasons: ultimately, a certificate is revoked because whoever is in charge of asserting the revocation status, by issuing CRLs, says so. One possible reason for a certificate to be revoked is that the corresponding private key was compromised (stolen). At that point, nothing signed with that key is to be trusted anymore since it could have been signed by the key thief. In that case (key compromise), not only will the intermediate CA certificate be revoked, but the intermediate CA will generate a new key, so any other certificate for that intermediate CA will use the new key. The net effect is that certificates previously issued by that intermediate CA will never again appear as part of valid chains again. Revoking them would be pointless.

Answer 3

• Yes, a certificate is only valid if the full chain of certificates up to the root are valid and not revoked, so you should check them all.
• If an intermediate CA is revoked, then child certs will need to be re-issued by a valid CA, there's no way to "swap in" a valid intermediate. To clarify: "re-issued" means "an entirely new cert created referencing the same name"
• I don't believe that child certs get put on a CRL when a parent cert is revoked. It's certainly possible to do, but logistically it would be painful, and I'm not aware of anyone that does it. This is just my best guess, though, I could easily be wrong on this point.