Correct ca bundle to use

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.

1 Like

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?

3 Likes

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)

4 Likes

Read here:

2 Likes

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.

4 Likes

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.

1 Like

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.

3 Likes

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.

1 Like

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

-----BEGIN CERTIFICATE-----
MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw
WhcNMjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCUjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC7AhUozPaglNMPEuyNVZLD+ILxmaZ6QoinXSaqtSu5xUyxr45r+XXIo9cP
R5QUVTVXjJ6oojkZ9YI8QqlObvU7wy7bjcCwXPNZOOftz2nwWgsbvsCUJCWH+jdx
sxPnHKzhm+/b5DtFUkWWqcFTzjTIUu61ru2P3mBw4qVUq7ZtDpelQDRrK9O8Zutm
NHz6a4uPVymZ+DAXXbpyb/uBxa3Shlg9F8fnCbvxK/eG3MHacV3URuPMrSXBiLxg
Z3Vms/EY96Jc5lP/Ooi2R6X/ExjqmAl3P51T+c8B5fWmcBcUr2Ok/5mzk53cU6cG
/kiFHaFpriV1uxPMUgP17VGhi9sVAgMBAAGjggEIMIIBBDAOBgNVHQ8BAf8EBAMC
AYYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMBIGA1UdEwEB/wQIMAYB
Af8CAQAwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYfr52LFMLGMB8GA1UdIwQYMBaA
FHm0WeZ7tuXkAXOACIjIGlj26ZtuMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AoYWaHR0cDovL3gxLmkubGVuY3Iub3JnLzAnBgNVHR8EIDAeMBygGqAYhhZodHRw
Oi8veDEuYy5sZW5jci5vcmcvMCIGA1UdIAQbMBkwCAYGZ4EMAQIBMA0GCysGAQQB
gt8TAQEBMA0GCSqGSIb3DQEBCwUAA4ICAQCFyk5HPqP3hUSFvNVneLKYY611TR6W
PTNlclQtgaDqw+34IL9fzLdwALduO/ZelN7kIJ+m74uyA+eitRY8kc607TkC53wl
ikfmZW4/RvTZ8M6UK+5UzhK8jCdLuMGYL6KvzXGRSgi3yLgjewQtCPkIVz6D2QQz
CkcheAmCJ8MqyJu5zlzyZMjAvnnAT45tRAxekrsu94sQ4egdRCnbWSDtY7kh+BIm
lJNXoB1lBMEKIq4QDUOXoRgffuDghje1WrG9ML+Hbisq/yFOGwXD9RiX8F6sw6W4
avAuvDszue5L3sz85K+EC4Y/wFVDNvZo4TYXao6Z0f+lQKc0t8DQYzk1OXVu8rp2
yJMC6alLbBfODALZvYH7n7do1AZls4I9d1P4jnkDrQoxB3UqQ9hVl3LEKQ73xF1O
yK5GhDDX8oVfGKF5u+decIsH4YaTw7mP3GFxJSqv3+0lUFJoi5Lc5da149p90Ids
hCExroL1+7mryIkXPeFM5TgO9r0rvZaBFOvV2z0gp35Z0+L4WPlbuEjN/lxPFin+
HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv
MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX
nLRbwHOoq7hHwg==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE----- 
MIIFYDCCBEigAwIBAgIQQAF3ITfU6UK47naqPGQKtzANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTIxMDEyMDE5MTQwM1oXDTI0MDkzMDE4MTQwM1ow
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQCt6CRz9BQ385ueK1coHIe+3LffOJCMbjzmV6B493XC
ov71am72AE8o295ohmxEk7axY/0UEmu/H9LqMZshftEzPLpI9d1537O4/xLxIZpL
wYqGcWlKZmZsj348cL+tKSIG8+TA5oCu4kuPt5l+lAOf00eXfJlII1PoOK5PCm+D
LtFJV4yAdLbaL9A4jXsDcCEbdfIwPPqPrt3aY6vrFk/CjhFLfs8L6P+1dy70sntK
4EwSJQxwjQMpoOFTJOwT2e4ZvxCzSow/iaNhUd6shweU9GNx7C7ib1uYgeGJXDR5
bHbvO5BieebbpJovJsXQEOEO3tkQjhb7t/eo98flAgeYjzYIlefiN5YNNnWe+w5y
sR2bvAP5SQXYgd0FtCrWQemsAXaVCg/Y39W9Eh81LygXbNKYwagJZHduRze6zqxZ
Xmidf3LWicUGQSk+WT7dJvUkyRGnWqNMQB9GoZm1pzpRboY7nn1ypxIFeFntPlF4
FQsDj43QLwWyPntKHEtzBRL8xurgUBN8Q5N0s8p0544fAQjQMNRbcTa0B7rBMDBc
SLeCO5imfWCKoqMpgsy6vYMEG6KDA0Gh1gXxG8K28Kh8hjtGqEgqiNx2mna/H2ql
PRmP6zjzZN7IKw0KKP/32+IVQtQi0Cdd4Xn+GOdwiK1O5tmLOsbdJ1Fu/7xk9TND
TwIDAQABo4IBRjCCAUIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYw
SwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8vYXBwcy5pZGVudHJ1
c3QuY29tL3Jvb3RzL2RzdHJvb3RjYXgzLnA3YzAfBgNVHSMEGDAWgBTEp7Gkeyxx
+tvhS5B1/8QVYIWJEDBUBgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEEAYLfEwEB
ATAwMC4GCCsGAQUFBwIBFiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2VuY3J5cHQu
b3JnMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaWRlbnRydXN0LmNvbS9E
U1RST09UQ0FYM0NSTC5jcmwwHQYDVR0OBBYEFHm0WeZ7tuXkAXOACIjIGlj26Ztu
MA0GCSqGSIb3DQEBCwUAA4IBAQAKcwBslm7/DlLQrt2M51oGrS+o44+/yQoDFVDC
5WxCu2+b9LRPwkSICHXM6webFGJueN7sJ7o5XPWioW5WlHAQU7G75K/QosMrAdSW
9MUgNTP52GE24HGNtLi1qoJFlcDyqSMo59ahy2cI2qBDLKobkx/J3vWraV0T9VuG
WCLKTVXkcGdtwlfFRjlBz4pYg1htmf5X6DYO8A4jqv2Il9DjXA6USbW1FzXSLr9O
he8Y4IWS6wY7bCkjCWDcRQJMEhg76fsO3txE+FiYruq9RUWhiF1myv4Q6W+CyBFC
Dfvp7OOGAN6dEOM4+qR9sdjoSYKEBpsr6GtPAQw4dy753ec5
-----END CERTIFICATE-----
2 Likes

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

2 Likes

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:

-----BEGIN CERTIFICATE-----
MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw
WhcNMjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCUjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC7AhUozPaglNMPEuyNVZLD+ILxmaZ6QoinXSaqtSu5xUyxr45r+XXIo9cP
R5QUVTVXjJ6oojkZ9YI8QqlObvU7wy7bjcCwXPNZOOftz2nwWgsbvsCUJCWH+jdx
sxPnHKzhm+/b5DtFUkWWqcFTzjTIUu61ru2P3mBw4qVUq7ZtDpelQDRrK9O8Zutm
NHz6a4uPVymZ+DAXXbpyb/uBxa3Shlg9F8fnCbvxK/eG3MHacV3URuPMrSXBiLxg
Z3Vms/EY96Jc5lP/Ooi2R6X/ExjqmAl3P51T+c8B5fWmcBcUr2Ok/5mzk53cU6cG
/kiFHaFpriV1uxPMUgP17VGhi9sVAgMBAAGjggEIMIIBBDAOBgNVHQ8BAf8EBAMC
AYYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMBIGA1UdEwEB/wQIMAYB
Af8CAQAwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYfr52LFMLGMB8GA1UdIwQYMBaA
FHm0WeZ7tuXkAXOACIjIGlj26ZtuMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AoYWaHR0cDovL3gxLmkubGVuY3Iub3JnLzAnBgNVHR8EIDAeMBygGqAYhhZodHRw
Oi8veDEuYy5sZW5jci5vcmcvMCIGA1UdIAQbMBkwCAYGZ4EMAQIBMA0GCysGAQQB
gt8TAQEBMA0GCSqGSIb3DQEBCwUAA4ICAQCFyk5HPqP3hUSFvNVneLKYY611TR6W
PTNlclQtgaDqw+34IL9fzLdwALduO/ZelN7kIJ+m74uyA+eitRY8kc607TkC53wl
ikfmZW4/RvTZ8M6UK+5UzhK8jCdLuMGYL6KvzXGRSgi3yLgjewQtCPkIVz6D2QQz
CkcheAmCJ8MqyJu5zlzyZMjAvnnAT45tRAxekrsu94sQ4egdRCnbWSDtY7kh+BIm
lJNXoB1lBMEKIq4QDUOXoRgffuDghje1WrG9ML+Hbisq/yFOGwXD9RiX8F6sw6W4
avAuvDszue5L3sz85K+EC4Y/wFVDNvZo4TYXao6Z0f+lQKc0t8DQYzk1OXVu8rp2
yJMC6alLbBfODALZvYH7n7do1AZls4I9d1P4jnkDrQoxB3UqQ9hVl3LEKQ73xF1O
yK5GhDDX8oVfGKF5u+decIsH4YaTw7mP3GFxJSqv3+0lUFJoi5Lc5da149p90Ids
hCExroL1+7mryIkXPeFM5TgO9r0rvZaBFOvV2z0gp35Z0+L4WPlbuEjN/lxPFin+
HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv
MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX
nLRbwHOoq7hHwg==
-----END CERTIFICATE-----

imap and smtp work.

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

1 Like

Interesting... :thinking:

Let me check something...

1 Like

"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"]

4 Likes

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

:confused:

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

4 Likes

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
---
2 Likes

I thought SMTP was 465.

1 Like

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

4 Likes

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

3 Likes

I rest my case.

4 Likes

GoDaddy has it backwards... :rofl:

4 Likes