5

I understand that each certificate can have a CRL distribution point (extension 2.5.29.31) – or even multiple ones, but let's not consider that for the moment. Let's assume we have a root CA > intermediate CAs > and leaf certificates.

My understanding is that the root CA issues (signs) any intermediate CAs. It also maintains a list of revoked certificates (a CRL), and that this list holds only certificates which it had originally signed (or: is the issuer of).

Furthermore, the root CA's CRL is published at an URI that is included as a CRL distribution point in the certificates this root CA has signed, which are the intermediate CA certificates in our example.

Consequently, the leaf certificates will have the CRL URI of their issuer intermediate CAs in their CRL distribution point.

Since the root CA certificate is self-signed, I am unsure if a CRL distribution point in the root certificate makes sense or not. Searching through the system trust store of my computer, I notice that some root CA certificate have CRL distribution points and some don't. Why is that?


Obviously, most if not all clients accept root certificates without a CRL distribution point. However, when I run a revocation check using openssl, I get an error for the root certificate:

$ openssl verify -show_chain -crl_check_all -crl_download -CAfile root_G3.crt -untrusted ica-test_G2.crt [email protected] error 3 at 2 depth lookup: unable to get certificate CRL 

It complains about chain depth 2, which is the root certificate. It's only one in the chain without a CRL DP.

2 Answers 2

5

Why is that?

Can't tell for sure, but I guess CDP was included for root certificate revocation by a CA owner. However this unlikely ever worked in practice. RFC 3280 (most root certs with CDP were created when this RFC was effective) and 5280 do not define a root certificate revocation process. Here are some quotes from RFC 5280:

§6.1 When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path

§6.1.1 The trust anchor information is trusted because it was delivered to the path processing procedure by some trustworthy out-of-band procedure.

Which suggests that self-signed certificate is not part of certification path and constraint checking, which implies revocation checking as well, because only prospective certification path is checked for revocation.

It could be a human mistake or bug. For example, the most popular CA software in Microsoft ecosystem, Microsoft Certificate Services (now known as Active Directory Certificate Services) mistakenly included CDP extension in root CA certificate by default from Windows NT4 until it was fixed in Windows Server 2008.

And to your original question

When to use a CRL distribution point in a root certificate?

a short answer: never. The sole purpose of self-signed certificate is to provide a trust anchor, nothing else. It should not define any policies or constraints. They are set at Policy CA level.

1
  • Makes sense. However, testing with openssl, it seems to have a different opinion, or I might be doing or expecting wrongly. See my question edit. Commented Feb 3 at 12:16
2

There is absolutely no point in having a CRL Distribution Point in a Root CA. I hadn't noticed any before you mentioned it, but had a quick glance in my Windows 11 device and found AAA Certificate Services by Comodo does indeed contain a CDP. I gave up at 'C'.

It doesn't help anyone by having it there, as if you decide not to trust the CA, then by definition you cannot trust it to revoke. In other words, if it was compromised, would the compromiser have a guilty conscious and revoke it? I doubt very much!

The only way to revoke a Root CA is for it to be removed from the trust-anchor store. Either by the OS/browser vendor, or by yourself.

4
  • 2
    The owner may want to revoke it for other reasons without any compromising, like replacing it by a new root certificate? Commented Jan 27 at 19:51
  • 1
    Then the owner would replace it in the trust-anchor store, not leave it there and revoke it. Commented Jan 27 at 22:31
  • The owner usually doesn't have control over all clients' trust anchor stores, and how would it be revoked without a CRL distribution point in the certificate? Commented Jan 29 at 8:26
  • Root CA certs aren't checked for revocation (read the RFC linked in Crypt32's answer). This is why you should be very careful about what you add to your trust-anchor store. OS and browser vendors generally do this on your behalf with their Root Certificate Programs, but for local CAs you're on your own. If you're running Windows, Group Policy can help you manage them. MDM can help for mobile devices. There is also a protocol for managing them (Trust Anchor Management Protocol) but AFAIK it isn't implemented that often. Revocation can't/won't, hence no point embedding a CDP URL. Commented Jan 29 at 12:19

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.