What makes a root certificate a root certificate?

Help
1

So, recently the root certificate "DST Root CA X3" expired. On this Let's Encrypt page Production Chain Changes it is explained that currently the default certificate chain that is issued is "End-entity certificate ← R3 ← ISRG Root X1 ← DST Root CA X3" and that it will stay that way.

I looked at such a chain, and indeed the last certificate had these properties:

Subject: C=US, O=Internet Security Research Group, CN=ISRG Root X1
Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
Not After : Sep 30 18:14:03 2024 GMT
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE

So how is this certificate useful to include? DST Root CA X3 has expired, so one would think a certificate signed by it is now useless, even though this particular certificate has a stated validity of several more years.

Then I noticed the "CA:TRUE" part. Does this by itself make this a root certificate?

I tried to find the answer to this by googling, but everything I found was sloppy in its descriptions and I didn't find anything that looked authoritative. Most sources however insist that a root certificate must be self-signed.

2

@oseibert check the CA/Browser Forum's Baseline Requirements and look at sections:

7.1.2.1 Root CA Certificate
7.1.2.2 Subordinate CA Certificate
7.1.2.3 Subscriber Certificate

for the difference required on those main 3 certificate types.

1 Like
3

That document looks very authoritative :slight_smile: So if I understand it in some quick reading, the given certificate is not a root certificate. But not because it's not self-signed (that requirement isn't listed there) but because it fails

c. certificatePolicies
This extension SHOULD NOT be present.

since it has

        X509v3 Certificate Policies:
           Policy: 2.23.140.1.2.1
          Policy: 1.3.6.1.4.1.44947.1.1.1
           CPS: http://cps.root-x1.letsencrypt.org

(I hope I match the names up right, since they are spelled a bit differently between the document and the output from openssl)

So that answers one question.

Then the one that remains is: why is it useful to include this certificate, since it is not a root, and the root that signed it has expired?

4

Root certificates are indeed self-signed. They are included with the clients trust store and not send over the wire, so you won't see any root as part of your certificate chain. Sending roots would be useless, since the client already knows them.

The certificate you're showing above is a cross-sign of ISRG Root X1, which is also a root certificate.

It's confusing when you think in "certificates". Think less in certificates, think keypairs!

DST Root CA X3 and ISRG Root X1 are both keypairs. There exist multiple certificates representing these keypairs.

Let's Encrypt current default chain is specifically designed to support older Android. The problem with older Android is, that they do not have ISRG Root X1 in their trust store - they won't trust anything signed by that. But they do trust DST Root CA X3 and they do not care that it is now expired.

So Let's Encrypt got a cross-sign chaining up to DST Root CA X3 Android can use for verification. Other clients (that do care about the expiry of DST Root CA X3) can use ISRG Root X1 for verification, because that's

a) also a root
b) is part of the verification chain - R3 is issued by ISRG Root X1!

So conclusively, the certificate "ISRG Root X1 signed by DST Root CA X3" is what we call a cross-sign. It acts as a helper certificate, to show Androids a path to DST Root CA X3, without having to trust ISRG Root X1. Other clients should ignore this certificate, as they already know that ISRG Root X1 is a self-signed root certificate they have in their trust store.

4 Likes
5

Please see https://letsencrypt.org/2020/12/21/extending-android-compatibility.html

3 Likes
6

That's like saying:
It's confusing when you think of "square roots" think of it more like "quantum physics" to a 3rd grader.
[You can't explain things by using more complicated things to explain them with - not that anyone here is smarter than a 5th grader]

The post is technically correct but will probably never be read fully; because anyone (like me) willing to read through it all would likely already be familiar with all that was said - very small target audience.

Sorry to be so crabby... must be low on sugar!

2 Likes
7

Ahh! "This solution works because Android intentionally does not enforce the expiration dates of certificates used as trust anchors." That makes all the difference, and was the thing I was definitely not expecting!

Thanks!

1 Like
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.