25

If you revoke a certificate authority's certificate, do all of the certificates it issued become invalid as well? What about for certificates issued by an authority beneath it?

For example, if root CA A issues intermediate CA B, which issues certificate C, and:

  • CA A revokes CA B, does certificate C become invalid?
  • CA A gets revoked (somehow), does its revocation cascade all the way down the chain such that certificate C is now invalid as well?
Improve this question
3
  • 11
    Incidentally: This is (one) reason that often a CA will not sign the certificates it issues with their root certificate - instead they will create an intermediate certificate, and use that to sign. In cas of problems that allows them to revoke the intermediate certificate (which they can re-issue), instead of having to revoke/distrust their root cert.
    – sleske
    Oct 10, 2019 at 7:32
  • 2
    Good comment on why 1-tier CAs are not good.
    – Crypt32
    Oct 10, 2019 at 7:44
  • 1
    In theory, B (and thereby C) could be kept alive by signing it with a trusted A'
    – Hagen von Eitzen
    Oct 10, 2019 at 20:28

2 Answers 2

Reset to default
35

CA A revokes CA B, does certificate C become invalid?

Yes, revocation cascades down to the tree. If CA certificate is revoked, all certificates below (regardless of how many levels are below CA) are implicitly considered untrusted. Keep in mind that they become *untrusted*, not revoked.

CA A gets revoked (somehow), does its revocation cascade all the way down the chain such that certificate C is now invalid as well?

Root CA revocation is an undefined operation within RFC5280. In this case, the CA puts its certificate (serial number) in its own CRL and signs with its own key. And now we have a chicken-egg problem:

The CA cert is revoked (listed in CRL), but the CRL is signed with a revoked key, so we can't trust this CRL and get a definitive answer about whether the root certificate is revoked. This problem is often solved by not checking root CA revocation using RFC5280 techniques. For example, in Microsoft's certificate chaining engine default configuration, root CA certificates are not checked for revocation at all.

Such cases (root CA revocation) are handled differently, using OOB processes, by maintaining a list of explicitly trusted anchors (root certificates) and removing a bad CA cert from the list.

Improve this answer
10
  • 3
    +1, I would add that the reason Root CAs have undefined revocation is that in most PKI specs (for example, RFC5280), a Root CA is, by definition, a public key whose hash matches the authorityKeyIdentifier in the certificates that it issues. Often, clients that are trying to save memory will have only the root's public key, and not the entire certificate. You can revoke a certificate, but as mentioned, revoking a public key is ... undefined.
    – Mike Ounsworth
    Oct 9, 2019 at 21:02
  • It should be noted that in practice if there is some reason to no longer trust a root certificate, it will simply be removed from the list of trusted root certificates that is used by software. These lists are maintained by browsers (e.g. Firefox has such a list) or by operating systems (e.g. MS Windows has one, visible in the Microsoft Management Console / MMC). So a root certificate is not "revoked", it is simply "removed" or "disabled". This has happened, e.g. with DigiNotar certs (article on Mozilla blog).
    – sleske
    Oct 10, 2019 at 7:29
  • I added some clarifications in my response.
    – Crypt32
    Oct 10, 2019 at 7:43
  • 7
    The logic in your "chicken-egg problem" seems kind of weak: if a CRL contains the root certificate it is signed with, then either a) the legitimate holder of the certificate put it on the list and signed it, in which case they clearly want it revoked, or b) the certificate has been compromised and needs to be revoked anyway. So there's no reason not to accept the revocation in either case. (That said, I'm not trying to dispute your claim that some/many/most/all implementations don't apply CRLs to root certificates — I'm merely pointing out that, AFAICT, it would be perfectly OK if they did.)
    – Ilmari Karonen
    Oct 10, 2019 at 21:29
  • 1
    @JanHudec I mean, interpretation of root CA certificate presence in its own CRL may vary from implementation to implementation. I didn't say it is bad choice. RFC doesn't say anything on this, so whatever is implemented may be considered as valid implementation. But this is not something everyone can rely on.
    – Crypt32
    Oct 12, 2019 at 8:54
9

"It depends".

The most secure answer is "yes, it revokes the subtree", because once the "B" certificate has been revoked there's no reason to trust any certificate it claims to have issued (or any CRL it has signed, et cetera).

But it really depends on what inputs are given to the chain builder (which means it won't be consistent from application to application).

  • If a chain trust is built without checking revocation, it'll say everything is fine.
  • If a chain trust is built only checking the End-Entity revocation, then
    • If the CA published a final CRL revoking everything then it'll say revoked.
    • Otherwise it'll say everything is fine.
  • If the chain trust is built to check revocation everywhere except the root, it'll say revoked.
  • If the chain trust is built to check revocation for the whole chain (which is sort of redundant, since the easiest way to "revoke" the root is to take it out of the trust list), it'll say revoked.

.NET's X509Chain class defaults to checking revocation for everything except the root. Win32 CertGetCertificateChain defaults to no revocation (the revocation type has to be specified via the dwFlags parameter). Other libraries may have different defaults, and applications can configure them in a variety of ways.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .