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

To all webhosts looking to continue supporting older clients, I suggest that

  1. you confirm the root certificate you want to use is on the system you want to support, example:
    OS X Mavericks: List of available trusted root certificates - Apple Support (IL)

  2. you configure your ACME client to use a different CA server

example: SSL | Buypass Go SSL – Technical information | Buypass CA

when an embedded certificate expires, if the device isn't getting updated, that's that. check the expiration date of the embedded root certificate on the older system you want to support, and the browser is probably deriving it's trusted root from the operating system.
exception: firefox, but firefox accepts expired trusted root certs, unlike chrome, so there's that.

1 Like

we're using HAProxy 2.4.4 and seeing some older macs and ubuntu 15 seeing cert expired messages when they go to docucopies.com is there a config change I can make in haproxy that will fix that?

1 Like

Thank you, I will try to find which subject is substituting R3 certificate. Thank you again.

2 Likes

Hi @deckberg-qd, welcome to the LE community forum :slight_smile:

That site is using the exact same trust path (chain) that this forum is using.
You have only three choices:

  • upgrade the clients to work with this trust path (chain)
    [may not even be possible now, or ever (for some no-longer-supported clients)]
  • modify all the servers to use a different trust path (chain)
    this isn't very likely; as you can't possibly control the very large number of systems on the Internet that are using this same trust path (chain)
  • put all your troubled clients behind a proxy (one that terminates the TLS connections
    that may keep those clients within your trust path (chain) control; as they would only see the proxy

[there may be other ways... I'm running low on :zzz: ]

2 Likes

for your 2nd bullet. am I thinking correct that I can update certbot to 1.12 and put in the correct whatever for --preferred-chain ?

sorry, I'm not trying to make the clients work everywhere on the net, I just want my older customers to be able to get to my website docucopies.com without the expired cert warning

1 Like

For the servers under your control, sure.
"a different trust path" can includes using other FREE, or paid, CAs [all valid choices]

Many ways to slice that pie!

2 Likes

Looks like SSL labs is saying there is and issue with one of the paths. So I need to include the cross signed cert somewhere?

https://www.ssllabs.com/ssltest/analyze.html?d=docucopies.com

1 Like

Your server is already sending the cross-signed cert. It's #3 in the second section in your screenshot. That's part of the "default" chain Let's Encrypt sends to your ACME client.

The --preferred-chain option you alluded to would be the way to get the "alternate" chain that removes that cross-signed cert and also then breaks compatibility with old Android devices. Whether that is an improvement for your overall userbase, only you can determine.

5 Likes

so there's nothing I can do server side to have those older clients be able to connect? it's simply up to the client to update their trust store if they are able?

1 Like

If those older clients do not trust the ISRG Root X1 cert, the only thing you can do server side is change to a different Certificate Authority that they do trust. Personally, I would try switching to the shorter chain first and seeing how those clients respond. But again, that will definitely break old Android devices.

6 Likes

For those looking for a fix with NodeJS 8, i've opened an issue on the github, but probably not going to do anything.

In the post i've writen the fix, but you gonna have to build your own version of Node unless they fix it.

3 Likes

I can Confirm a fix that worked on both a 10.9.5 & 10.11.6 Mac OS users. Simply set the DST Root CA X3 to "Always Trust" on several Mac's I manage in an office and home's this fix work for 4 websites that previously had issues with this CERT ERR.

https://www.nynewspapers.com/

Directions for fix:

  1. Open ~/Applications/Utilities/Keychain Access.app
  2. From View menu select "Show Expired Certificates"
  3. On the Left Sidebar pick System Root
  4. In search bar top-right type DST
  5. Double-click "DST Root CA X3"
  6. In pop-up, turn down "Trust" arrow and set "When using this certificate" to "Always Trust"
  7. Close the pop-up and put in an Administrator user/password info.
  8. Close all open Browsers & Keychain you should be good to go after that.

5 Likes

Hello Everyone!

This expiry of DST Root caused me to really look at and understand my own setup :slight_smile: And thank you all for helping each other here!

I had two issues:

  1. I had to remove the DST Root from my system store on the server because openssl s_client kept failing my tests.
  2. The existing fullchain.pem files still had the DST Root CA X3 certificate in them which caused my webserver to continue to send it, causing failures on some clients. The solution was to force a renewal of the certificate.

I'm not using the apache installer and authenticator, but instead use the webroot athenticator as I found it better when using a mix of services:

# certbot --webroot --dry-run -w /var/www/domains/wiki.tnonline.net/htdocs -d wiki.tnonline.net -v certonly

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Certificate not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/wiki.tnonline.net.conf)

What would you like to do?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Keep the existing certificate for now
2: Renew & replace the certificate (may be subject to CA rate limits)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 

I found that certtool from the GnuTLS package is better to look at the full chain than with openssl:

certtool -i --infile /etc/letsencrypt/live/wiki.tnonline.net/fullchain.pem |less
1 Like

14 posts were merged into an existing topic: Ubuntu Android problem

This is causing lftp to fail.

Certificate: C=US,O=Internet Security Research Group,CN=ISRG Root X1
Issued by: O=Digital Signature Trust Co.,CN=DST Root CA X3
ERROR: Certificate verification: Not trusted

Wayne Sallee
Wayne@WayneSallee.com

1 Like

Thanks! This fixed my problem.
Is this solution permanent? Do you know if it might break in the future?

Can i set auto renew using this approach?

2 Likes

So are you saying that just simply creating a new cert fixed the problem?

Wayne Sallee
Wayne@WayneSallee.com

1 Like

Yes. Because the fullchain.pem had the expired cert in it.

1 Like

Didn't work for me, with lftp.

Wayne Sallee
Wayne@WayneSallee.com

1 Like

That's the approach I tried, but on my Xubuntu NextCloud server system the certificates are held in a core18 snap file. Trying to remove them results in an error as you cannot remove components of a live snap file, the snap file itself must be rebuilt without them. So I tried that using unsquashfs and mksquashfs but then the snap file wasn't recognised.

None of my NextCloud clients can connect; they all get a certificate error.

So I'm still looking for a solution.

1 Like