Correct ca bundle to use

meisner · October 8, 2021, 10:59pm

I'm sure this is probably answered some where - but I'm having trouble finding it.

What is the correct ca bundle that is suppose to be used with Let's Encrypt certificates?

No doubt this is related to the DST Root CA X3 certificate expiring.

But when I'm talking to my provider I'm getting conflicting information. One is saying the DST Root CA X3 certificate expired on September 29, 2021. Another is saying the DST Root CA X3 is good through September 30, 2024.

The ca bundle that I seem to be getting when I issue a Let's Encrypt certificate shows two certificates. A ISRG Root X1 certificate that expires on September 15, 2025. And a DST Root CA X3 certificate that expires on September 30, 2024.

Another person is saying that the ISRG Root X1 certificate that expires on September 30, 2024 isn't valid. But it's being sent by Let's Encrypt.

I'm not really sure where the ca bundle that I'm getting is coming from. I'm using an acme.sh client to issue certificates and it's returning both the ISRG Root X1 certificate that expires on September 15, 2025 and a DST Root CA X3 certificate that expires on September 30, 2024. Maybe that's coming from something else in the acme.sh client?

I'm just wondering if there is an always up-to-date link from Let's Encrypt that always shows what the correct ca bundle to use for certificates currently being issued.

Nummer378 · October 8, 2021, 11:23pm

I think you're confusing some things here.

What you talk about - the certificates provided by acme.sh - are CA certificates returned by the ACME server (Let's Encrypt) and are so-called intermediates. They're part of what we call the certificate chain. This chain should be served by the server to the clients in every TLS handshake. They're not intended for much else.

A 'ca bundle' can mean many things, but it commonly refers to a trust store. A trust store is shipped with (TLS) clients and contains certificates (or public keys) that anchor trust - trust anchors. Those are often so-called 'root certificates'. These trust stores are usually managed by some root program, such as Mozilla's CA Certificate Program.

Any modern trust store should include ISRG Root X1, which is a root certificate valid until 2035. All current Let's Encrypt certificates chain up to this root. There exists also a cross-sign certificate of ISRG Root X1, which is part of the current default chain. This is likely the cause for your confusion, because these certificates share the same key and subject.

About DST Root CA X3, that indeed expired on Sep 30 14:01:15 2021 GMT. It is no longer considered valid by many devices. Let's Encrypts current chain still contains a cross-sign up to this expired root, because that helps with Android compatibility. This should not matter for most devices, as ISRG Root X1 is still valid and should also be in trust stores.

What exactly are you trying to do? Are you configuring a server or a client?

SagePtr · October 8, 2021, 11:36pm

There are two ISRG Root X1 certificates.
One is included to trusted roots and valid to 2035. This one is included in ca bundles. (https://crt.sh/?id=9314791)
The other one is signed by DST Root CA X3 and it is valid until 30 Sep 2024. It exists solely to maintain the compatibility with old Android devices. This one is provided by default Letsencrypt chain, should not be added to any bundle because technically it's intermediate. (https://crt.sh/?id=3958242236)
And DST Root CA X3 already expired 30 Sep 2021, for some old OpenSSL clients it should be explicitly excluded from ca bundle if it's still there. (https://crt.sh/?id=8395)

griffin · October 8, 2021, 11:49pm

Read here:

griffin · October 8, 2021, 11:53pm

It depends upon what one means by a "CA bundle". For example, if you're a cPanel user, you can absolutely include both the R3 (signed by ISRG Root X1) and cross-signed ISRG Root X1 (signed by DST Root CA X3) intermediate certificates in the CA bundle box when installing a certificate via the cPanel SSL interface.

meisner · October 9, 2021, 12:12am

Actually I can't install it in cPanel if I include the DST Root CA X3 intermediate certificate.

I can if I exclude the DST Root CA X3 intermediate certificate.

When I inquired about this with my provider, they told me the DST Root CA X3 certificate is invalid. But when I check it, it shows as being valid until September 30, 2024.

Everything works without the DST Root CA X3 certificate for me, so I assume I'm up to date and using the ISRG Root X1 root certificate.

I guess ultimately the argument I'm having with my provider is that the DST Root CA X3 certificate (which I gather is an intermediate certificate) is included in the ca.cer file when my acme.sh client issues a certificate. I just assumed that that certificate should be included in the ca bundle when installing the certificate, even though it's probably not being used.

But I don't understand why it's invalid. I mean, cPanel's not installing it, so maybe it is invalid. But I don't really understand why it's invalid. And if it is invalid, why is it being included in the ca.cer file when issuing a certificate through acme.sh?

I'm sure I'm confusing something. I just don't really know what.

griffin · October 9, 2021, 12:15am

You should never include the self-signed DST Root CA X3 root certificate in your cPanel CA bundle because it's a root certificate. You should only include the two intermediate certificates that I mentioned (R3 signed by ISRG Root X1 and ISRG Root X1 signed by DST Root CA X3) if you want to use the long/default chain. You should only include the R3 signed by ISRG Root X1 intermediate certificate if you want to use the short/alternate chain.

meisner · October 9, 2021, 12:20am

Yea - the ISRG Root X1 signed by DST Root CA X3 - is the one I'm referring to. If I include that in the ca bundle field when installing a certificate, the certificate does not install.

griffin · October 9, 2021, 12:23am

You must include both intermediates in the field, like this:

griffin · October 9, 2021, 12:25am

For reference, CertSage (the ACME client that I authored), includes detailed cPanel certificate installation instructions that includes ~~both intermediate certificates~~ only the first intermediate.

meisner · October 9, 2021, 12:27am

Yea, that's what I try to install.

When I install that ca bundle, my imap and smtp connections are no longer secure.

If I install just:

imap and smtp work.

But both certificate - like you posted - are included in the ca.cer that I get when a certificate is issued.

griffin · October 9, 2021, 12:28am

Interesting...

Let me check something...

rg305 · October 9, 2021, 12:52am

"DST Root CA X3" is not, and I don't think has ever been used as, an intermediate certificate.
It is a ROOT certificate.
Thus, as such, should never be included in any bundle.

There are currently only two valid bundles (by bundle here I'm referring to the cert + chain).
Short path:
[leaf signed by R3], [R3 signed by "ISRG Root X1"]
Long path (default):
[leaf signed by R3], [R3 signed by "ISRG Root X1"], ["ISRG Root X1" signed by "DST Root CA X3"]

griffin · October 9, 2021, 1:08am

I just tested my GoDaddy cPanel shared hosting instance (mail.griffin.software) several ways and got some odd results.

By including both intermediate certificates in the CA bundle...

TLS/SSL: Serves both intermediate certificates if I click to "update" the certificate, but serves only the R3 intermediate certificate if I install the certificate anew.
https://decoder.link/sslchecker/mail.griffin.software/443

SMTP: Serves only the R3 intermediate certificate.
https://decoder.link/sslchecker/mail.griffin.software/465

IMAP: Serves the default GoDaddy intermediate certificates.
https://decoder.link/sslchecker/mail.griffin.software/993

POP3: Serves the default GoDaddy intermediate certificates.
https://decoder.link/sslchecker/mail.griffin.software/995

I can definitively say that I recommend not using the long/default chain with GoDaddy cPanel shared hosting.

@meisner

Your approach is probably the best here. Thanks for bringing my awareness to this absurdity. I will be ~~cracking some skulls~~ following up on this in the near future

rg305 · October 9, 2021, 1:26am

You missed one port (also shows the short chain):

openssl s_client -connect mail.griffin.software:587 -servername mail.griffin.software -starttls smtp | head
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = griffin.software
verify return:1
250 HELP
CONNECTED(00000005)
---
Certificate chain
 0 s:CN = griffin.software
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
---

griffin · October 9, 2021, 1:27am

I thought SMTP was 465.

rg305 · October 9, 2021, 1:27am

I have no idea why people use 465.
The TLS required port is 587.

griffin · October 9, 2021, 1:28am

With GoDaddy, secure SMTP won't work on 587.

rg305 · October 9, 2021, 1:29am

I rest my case.

griffin · October 9, 2021, 1:30am

GoDaddy has it backwards...

Topic		Replies	Views
Expiration or revokation of DST Root CA X3 Help	4	4036	January 1, 2018
CA bundle expiration Issuance Tech	8	839	January 14, 2024
DST Root CA X3 Expiration Help	16	2726	December 12, 2021
IdenTrust DST Root CA X3 expiry Help	18	5239	November 6, 2021
Renew DST Root CA X3 on IIS? Help	8	1892	December 25, 2021

Correct ca bundle to use

Related topics