Help thread for DST Root CA X3 expiration (September 2021)

rg305 · September 29, 2021, 9:58pm

HI @Narrowstrife, welcome to the LE community forum
[sorry it wasn't under better circumstances]

There are NO intermediate being served:

---
Certificate chain
 0 s:/CN=artdealers.org
   i:/C=US/O=Let's Encrypt/CN=R3
---

---
Certificate chain
 0 s:/CN=artdealers.org
   i:/C=US/O=Let's Encrypt/CN=R3
---

They should look like this:

---
Certificate chain
 0 s:/CN=community.letsencrypt.org
   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 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---

Narrowstrife · September 29, 2021, 10:16pm

Ah! I entered the certificate details into Plesk wrong, which is why the intermediate certificate was missing. Everything seems to be working now. Thank you for the sanity check!

socialattache · September 29, 2021, 10:16pm

We use Let's Encrypt certificates and I noticed a short while ago that our sites are down on many devices. My main site is https://socialattache.com and I get a certificate error now on iPhone XS software 14.8 Safari as well as on OSX 10.15.7 using Chrome or Safari.

The certificate for this domain doesn't expire until November so it appears it's not a certificate expiry issue but likely the root certificate expiry I'm reading about. We create our SSL certificates using the Acme PHP library that we call periodically to create/update our certificates.

These don't seem to be "old" devices so I expect there's something that needs to be done on our end to get them working again?

rg305 · September 29, 2021, 10:19pm

The Devil is in the details...
This is what your site is serving:

---
Certificate chain
 0 s:/CN=socialattache.com
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---

This is an example of what it should be serving (now):

---
Certificate chain
 0 s:/CN=community.letsencrypt.org
   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 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---

Cryptoman · September 29, 2021, 10:26pm

One question I have not yet been able to understand is how modern devices will be able to use the default string if the ISRG Root X1 certificate depends on the DST Root CA X3 certificate that will expire on September 30. It's okay that Android doesn't consider the expiration date (notAfter field) to create a chain of trust, but what about the other systems that consider that field?

socialattache · September 29, 2021, 10:28pm

What controls this result... is this in the certificate we received from Let's Encrypt or elsewhere?

rg305 · September 29, 2021, 10:30pm

Several files are provided when a cert is obtained.
The "fullchain" file should contain the end-leaf cert and the correct intermediate(s).

rg305 · September 29, 2021, 10:33pm

The newer/smarter systems that would consider that field should never get to see it.
Because they would have stopped looking for a trusted path the moment they encountered X1 [which is in their trusted store].

socialattache · September 29, 2021, 10:38pm

I apologize for not being very knowledgeable here as my IT guy is in a time zone where he's sleeping.

I suspect that our file lets-encrypt-r3-cross-signed.pem is out of date (it expired in March 2021) so if this would solve my problem where would I obtain a more recent version?

rg305 · September 29, 2021, 10:43pm

You have an IT guy that gets to sleep ?!?!?! - LOL
[I'm in the wrong time-zone]

Just by the name of it, I would have to say YES.
[who made that file? and why?]

What ACME client are you using?

Cryptoman · September 29, 2021, 10:43pm

So because ISRG Root X1 is already present in the updated systems, does it not need the self-signed root certificate (DST Root CA X3)?

rg305 · September 29, 2021, 10:45pm

@Cryptoman exactly.
Trust is verified leaf to root and verification stops when either:

a trusted cert is found (root store)
an untrusted cert is found (expired/revoked/self-signed)

PaulWiggy · September 29, 2021, 10:57pm

Hi - I'm having a nightmare and I'm not sure why. It is because of the root certificat expiry. I'm using Windows IIS, looking on there my cert chain is (my cert) -> (R3 ISRG Root X1 expiry 2025) -> (ISRG Root X1 expiry 2035) but many of my users are now experiening SSL failures - I think on IPhones - When I go to https://www.ssllabs.com/ and use their SSL checker tool I see (My cert) -> (DST Root CA X3 expires tomorrow) -> (R3 DST Root CA X3 expird 3 hours ago).

Can anyone help me with this and eplain in as much idiot proof details as possible as to what I need to do.

socialattache · September 29, 2021, 11:00pm

We are using the PHP Acme Library and I don't see any version number in the readme.md nor in a few PHP files I checked. I suspect the library simply communicates with the Let's Encrypt servers to do it's thing.

I suspect my last IT guy downloaded the file for me but that was over a year ago I think.

I expect I'll need to replace the file with something from here but I don't know which one:

This file is pointed to by our virtual hosts file:

<VirtualHost *:443>
ServerName socialattache.com

SSLEngine on
SSLCertificateFile /var/www/netbizboom/Data/Certificates/socialattache.com/certificate.pub.pem
SSLCertificateKeyFile /var/www/netbizboom/Data/Certificates/socialattache.com/private-key.pem
SSLCertificateChainFile /var/www/netbizboom/Data/Certificates/intermediate.ca-bundle

DocumentRoot /var/www/netbizboom

<Directory /var/www/netbizboom>
Require all granted

Allow local .htaccess to override Apache configuration settings

AllowOverride all

mts · September 29, 2021, 11:00pm

Hey guys,

since the old root is expired I have many shutdowns (expired messages):
a) iphones cannot connect to our exchange anymore
b) our cloud-devices are no longer able to connect to the backend (openssl 1.1.x)

this is the address: https://nucloud.nucleus-server.com
Based on this checked (https://chainchecker.certifytheweb.com/) everything looks ok.

We are using opnsene with the internal ACME-plugin (3.1)

rg305 · September 29, 2021, 11:05pm

Please attach that file.

rg305 · September 29, 2021, 11:07pm

The Devil is in the details...

This is what is being served:

---
Certificate chain
 0 s:/CN=nucloud.nucleus-server.com
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---

This is the EXAMPLE to follow:

Certificate chain
 0 s:/CN=community.letsencrypt.org
   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 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---

socialattache · September 29, 2021, 11:13pm

The original intermediate.ca-bundle:

rg305 · September 29, 2021, 11:21pm

OMG!

That's been expired for months.

Change that file to:

mts · September 29, 2021, 11:23pm

hm, ok. Actually I have no idea how to influence the certificate chain.

I'm using haproxy (inside opnsense) as load-balancer and haproxy is also taking care of ssl.
So probably I need some adjustments there.