We have given a certificate chain: X <-- Y <-- Z (X is an end-entity cert, Z is root CA).

Certificates are extended with CRL distribution points info. Because of the fact Y -> X Y is a CA for X. Therefore, Y can revoke X 's certificate by placing it on Y's CRL.

Z is CA for Y. Z can revoke certificate Y. But, the question is: can Z revoke certificate X?

3 Answers 3


Short answer: NO, Z can't revoke X directly. Exception: YES, if Z's CRLs are, due to prior arrangement between Z & Y, in the CRL Distribution Point list of X's certificate that was issued by Y.

RFC5280 refers to this as "Indirect CRL" - where Z can issue a CRL that includes certificates issued by Y. It only works if the verifier knows where to check. The "CRL Distributions Points extension" of certificates is the place they (ought to) look.

It is well known however, that most certification verification algorithms are not strictly quality checked against the standards - and hence this system is fallible to a non-negligible extent.

  • 2
    Although indirect CRL is possible, not all systems does support this. For example, Microsoft CryptoAPI doesn't support indirect CRLs.
    – Crypt32
    Commented May 30, 2017 at 20:12

[The two existing answers are good, but since they have no upvotes, I'll try to provide a canonical answer]

In general, No. I mean, Z can revoke Y, which automatically revokes X and all other certs issued by Y, but with commonly used PKIs and TLS engines Z has no mechanism to revoke X directly.

Generally speaking, each CA only tracks the certificates that it issues; in a typical PKI Z will not know about X's existence, and most cert verification engines will check for X's serial number on Ys CRL, and Y's serial number on Z's CRL. You could imagine a system where Y reports all the certs it issues to its parent CA so that Z does know about X and could include it on a CRL (though you'd have to worry about serial number collision and have some scheme to ensure that no two CAs in the hierarchy will issue the same serial number). Then you still need to worry about clients actually looking for X's serial number on Z's CRL, which is not a standard behaviour.

As @Sas3 mentions in their answer, RFC5280 does provide a mechanism for doing this, called "indirect CRLs" (though it seems like it's more intended for Y to copy Z'd revocations, or for a CA to delegate CRL management to an offboard "CRL signing server" rather than this scenario of having roots be able to bypass their subordinates). That said:

  1. To claim that this is secure, you'd need confidence that all cert validation engines consuming your certs support indirect CRLs.
  2. I'm a developer on the PKI software that powers the Entrust publcily-trusted CA, as well as many other CAs, and despite our name being on the author list of that RFC, as far as I know, even our software doesn't support indirect CRLs.
  3. RFC 5280 has been updated by RFC 6818, which makes no mention of "indirect CRL", so I would argue that while this mechanism is technically standardized, nobody really cares about it.

Long-story short: in a closed environment where you have full control of all CAs and all cert-consuming clients, you could probably devise a scheme whereby Z can revoke X, but in a public PKI or any environment using off-the-shelf TLS engines, this is certainly not widely supported.

  • Interesting. Although I think RFC 5280 is not "deprecated by" anything yet. It's only "updated by" 6818. (In contrast this RFC here has both lines in the top left corner: tools.ietf.org/html/rfc3280 ) Commented Jul 29, 2017 at 19:59
  • @StackzOfZtuff Ah, I wasn't aware of the distinction, thanks! Commented Jul 29, 2017 at 20:14

If Z is revoked, Y and X is not revoked, but can't be trusted anymore so we can say it is revoked. As Z didn't signed X it can't revoke it directly in its CRL. By the way, nobody will be looking to Z CRL if X is revoked there but to X CRL. WHat you can theoretically do is to merge both X and Z CRLs, but the problem is with signing. Who will sign such CRL? Z or X? Or both? As it is not standard I would say this can't work.

If you take a look to wiki you'll find almost everything about CRLs there.

You must log in to answer this question.

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