DST Root CA X3 expiry countdown

Here we go.

7 Likes

We just watched the countdown as a family lol.

6 Likes

Batten down the hatches!

3 Likes

I have an Android 6 device which doesn't have Root X1 installed. And I just connected to my IIS 7.5 Server without any problems. IIS serves only R3 and Root X1 as additional certificates in the chain. And as this last one is still cross signed by DST Root CA X3 -- which is trusted by older Androids -- the system itself seems to be able to verify the whole chain.

I furthermore noted on my (windows) desktop that just before the expiry of CA X3 the browser (resp the windows certifiate viewer) showed the certificate chain inclusive CA X3, but once it expired, CA X3 vanished.

Probably it'd only work as long as the device still has in its cache the ISRG-Root-X1-signed-by-DST-Root-CA-X3 certificate. So if it's visited a server that sent that in its chain recently enough, then it may work. But I have a hunch that, say, a factory-reset device wouldn't.

1 Like

Hello,

After the expiration of the root certificate all of our debian 9 servers show connections to sites with LE certs as invalid due to a expired certificate.
We tried completely removing a cert and requesting a new one but this does not fix it.
Debian 10 does work.

We confirmed the ISRG Root X1 is in the ca-certificates trust store on debian 9 and 10.
We run openssl 1.1.0l on debian 9 and 1.1.1d on debian 10.

Does anyone know what could cause this and how to fix it?

Thanks!

EDIT: Looks like a workaround for now is changing /etc/ca-certificates.conf:
mozilla/DST_Root_CA_X3.crt -> to !mozilla/DST_Root_CA_X3.crt
And then run update-ca-certificates command

On debian 9, you can try removing DST Root CA X3 from the set of trusted roots, to cause OpenSSL to build the chain to ISRG Root X1 instead.

1 Like

Should that even be necessary for OpenSSL 1.1.x? :thinking:

2 Likes

This did resolve a large amount of the issues for us. We're currently still struggling with Ruby/Python being unable validate SSL certificates, but that also affects Debian 10. We're not sure yet what causes it, still debugging...

I.e. Ansible towards Debian 10 servers that download an url via https all fail, even though curl on the server works.

IIRC debain uses GNUTLS for their wget so .... I think gnutls only patched to do short-circuiting after addtrust expireation?

2 Likes

I didn't experience any issues after the DST Root CA X3 certificate expired on my Windows Server 2019 (IIS 10). As with the expiration of the R3 intermediate certificate yesterday, SSL Labs continues to result in the use of the standard long chain. However, on all sites that use Let's Encrypt certificate, my local Windows 10 client is using the short chain (with self-signed ISRG Root X1 certificate). The same behavior is perceived in my client with Android 8.1.
So far I have not been able to obtain any evidence that any device is using the long chain, despite the results of SSL Labs.
Anyway, everything seems functional and there was no need to reboot Windows Server or IIS after the expiration of both certificates.


2 Likes

You are serving the short chain, the client is resolving the other chain combinations chain itself, so compatibility will vary by client.

3 Likes

is doesn't look it he sent shor chain , chain 2s isrg signed by dst cert has Sent by server tag

1 Like

The long (cross-signed X1) chain is shown to be served by the SSL Labs pics.

@Cryptoman, you would have to use an much older Android system to see the full chain; as most systems will short-circuit the validation as soon as any trusted cert is reached.
OR
use OpenSSL to see for yourself what is being served:
openssl s_client -connect EXAMPLE.COM:443 -servername EXAMPLE.COM

2 Likes

OpenSSL shows the longest chain :wink:

image

2 Likes

Cool, thanks. Looks like I have more homework to do, every day's a school day!

And I also need to figure out how to not reply to everyone.

2 Likes

Don't click the lower reply button.


OR
Also include the @username in the reply [just in case you do]

2 Likes

Hello,
We are using windows 2019 server and IIS 10. We use "win acme" latest version for certification.
I am deleting(as in picture) "DST root CA X3" from trusted certificates,but after 15 minutes it is coming back. rebooted the server, but it is still there. I think becouse of this in some chrome browser our web sites' certificate still showing "DST ca X3". I am not sure win acme uses a service to add the certificate again.

Has anyone any idea?

After deleting it - unbind and rebind any sites/certs that use it in IIS.
[you don't have to click OK between unbind (or simple choosing another cert) and then reselect the right cert and then click OK (only once per site/cert)]

If that continues to fail, can you reboot the server?
[in windows, some thing only happen at boot up]

1 Like

http://apps.identrust.com/roots/dstrootcax3.p7c as the issuer for ISRG Root X1 is still the expired DST Root CA X3 certificate