Cannot pin ISRG Root X1 certificate

Help
#1

Based on the Letsencrypt chain of trust here: https://letsencrypt.org/certificates/

I downloaded and pinned the ISRG Root X1 certificate in my client application in order to only initiate a TLS connection to my server if the server has a valid certificate from LetsEncrypt, rejecting any other CAs. However the certificate returned by the server doesn't seem to be signed with this root. The chain is:

My domain -> R3 -> IdenTrust DST Root CA X3

Switching out my pinned certificate for the IdenTrust one results in a succesful TLS connection. But from the image at https://letsencrypt.org/certificates/ it looks like the ISRG Root X1 should be signing the R3 certificate as well. I'm not sure if I'm missing something.

1 Like
#2

There are two R3 certificates.

One signed by "DST Root CA X3" and one signed by "ISRG Root X1".

For your "ISRG Root X1" pinning to work, your certificate chain should use the latter R3 certificate. By default (until January 11), you will have received the former R3 certificate from Let's Encrypt.

2 Likes
#3

Your client should be able to build a chain to ISRG Root X1 too, indeed, but it would need knowledge of the intermediate certificate signed by that root.

Currently, servers usually send only the intermediate R3 signed by IdenTrusts root DST Root CA X3, so probably your client hasn't cached the R3 signed by ISRG Root X1 or doesn't build a chain to it due to other reasons.

2 Likes
#4

I see. I could pin them both until then I guess. Is there a way to be issued the X1 variant instead?

2 Likes
#5

image
If you cut out all the unrelated, you can see that there are two independent roots.
And you may need to include both in your pinning.

1 Like
#6

The two intermediates discussed here (R3 signed by ISRG Root X1 and R3 signed by DST Root CA X3) contain the same public key and thus the end leaf certificates are signed by the same private key. You can think of the CommonName R3 from the intermediates as the public/private keypair.

As the end leaf certificates are signed by only a single private key (R3), end leaf certificates can chain to both roots, depending on the intermediate used. Therefore, your end leaf certificates are the same, no matter what chain is being build.

3 Likes
#7

Meaning yes, you can just replace the R3 certificate in your chain with the "ISRG Root X1"-signed one.

You can download it from https://letsencrypt.org/certs/lets-encrypt-r3.pem.

If your next renewal is after January 11, you won't need to make that substitution again.

2 Likes
#8

Well, actually meaning "no", as Let's Encrypt doesn't need to issue a specific end leaf certificate when it comes to which root the chain is being build. I don't consider choosing the intermediate as being "issued a X1 variant" to be honest.

Perhaps a little bit "too correct", but when it comes to understanding PKI, root, intermediates, cross-signing, I like to be overly correct just to be sure everything is understood correctly.

2 Likes
#9

Makes sense. I would have to fork the library that I'm using for certificate issuance in order to substitute the intermediary, or replace the intermediary manually in the certificate file on disk, so I will just pin both until January 11th as that's simpler.

Thanks for your help everyone.

2 Likes
#10

Note that you shouldn't hardcode the intermediate. The intermediate might change without any notice, for example, when an incident forces Let's Encrypt to start using the backup intermediate R4 in stead of R3. When you're being issued a certificate from the ACME server, the server sends HTTP Link headers with the "alternate" relation type containing alternate intermediate certificates which could be used too.

You could analyze the intermediates send to you by the ACME server and choose the one you require. For example, you could check the Issuer of the intermediate to identify the signing root certificate and choose by that criterium.

3 Likes
#11

OR
If you can use more than one, use R3 and R4 (and E1 and E2, and X3 and X4)
:wink:

1 Like
#12

Gotta pin em' all!!!

3 Likes
#13

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