Score:0

Server

DST Root CA X3 (Self-signed) - has expired in certificate chain used by Let's Encrypt (Apache/Windows)

MeSo2

8/11/24, 2:45 PM

Is it safe to remove a self-signed root certificate from the chain; and what, if any, are the consequences of doing that?

And how would I go about doing this on a Windows setup? The instructions under "Manually updating the local certificates" which suggest to remove the DST Root CA X3 certificate from the chain is for non-Windows setups.

This is how I found about about my problem: I ran a SSL test on my domain https://www.filmfix.com using https://www.ssllabs.com:

I use https://github.com/do-know/Crypt-LE to obtain my wildcard Let's Encrypt certificate and run Apache to handle all :443 calls.

Doing some digging I found a way to remove that certificate, but the chain is somehow still listed.

Removing DST Root CA X3 from Windows

I went ahead and did certmgr.msc to check on it

The URL support.microsoft.com/?id=293781 is not working; but I found this related page https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/trusted-root-certificates-are-required and could not find the mentioning of DST Root CA X3 in it, so I deleted the certificate and rebooted Windows.

I regenerated the Let's Encrypt wildcard certificate and restarted Apache. Now testing at https://www.ssllabs.com it looks like I the SSL DST Root CA X3 issue is no longer.

I tested on https://www.immuniweb.com and got an A+! And found this helpful tip:

The server is not configured to support OCSP stapling for its RSA certificate that allows better verification of the certificate validation status. Reconfigure or upgrade your web server to enable OCSP stapling.

But I still see CN = DST Root CA X3 in the chain when running.

C:\64bit\Apache24\bin>openssl s_client -connect www.filmfix.com:443 -status -servername www.filmfix.com

CONNECTED(000001B0)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = *.filmfix.com
verify return:1
OCSP response: no response sent
---
Certificate chain
 0 s:CN = *.filmfix.com
   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
---

Do I need to remove any of the ssl.pem or ssl.csr file for openssl to regenerate the files to update the chain?

1 + 4

windows

ssl

keychain

self-signed-certificate

lets-encrypt

dave_thompson_085

8/12/24, 3:21 AM

(1) Apache does not use the Windows certstore AT ALL; deleting DSTX3 from Windows has no effect on what your Apache serves (2) getting a renewed cert from LE _might_ change the chain used depending on how you did it which you didn't say, but [LE still _defaults_ to the cross-DSTX3 chain until next year](https://letsencrypt.org/2023/07/10/cross-sign-expiration.html) BTW when I try ssllabs on your site it can't connect at all -- I think it might have a timeout, and at least for me your server is pretty slow (as you already noted).

MeSo2

8/12/24, 3:27 AM

@dave_thompson_085 Let me stop all the running processes so you have better access to it. I will run them some other time. I also rebooted Apache. And now a full reboot. It was still slow...

MeSo2

8/12/24, 3:54 AM

@dave_thompson_085 I am using a perl script that runs le64.exe [Crypt-LE 0.39.0.0](https://metacpan.org/dist/Crypt-LE) to obtain a dns-01 TXT challenge from Let's Encrypt; the challenge (data) gets sent to Simple DNS Plus via a GET request that updates the _acme-challenge TXT record; le64.exe update cert obtained by Let's Encrypt

dave_thompson_085

8/14/24, 2:15 AM

I'm not going to read through that code, but I don't see anything obvious about using a nonstandard chain, and in fact your server (still) does use the cross-signed chain. ssllabs now gets through, and it shows _two_ different certs, one for www.filmfix.com and if SNI is not used a different but almost contemporaneous one for www.filmfix.net, both from LE and both using the cross-signed chain, which ssllabs shows with its two trust paths: one truncated at ISRG X1 and trusted nearly everywhere now, one continuing to DST X3 which is invalid and untrusted -- exactly as you posted 'before'.

Score:0

Server

Ginnungagap

8/11/24, 5:10 PM

DO NOT mess with your system managed trust store if you have this kind of question.

The ssllabs warning comes from Qualys' tool's own trust store so you can remove alter and break your local trust store all you want, it isn't going to change anything.

The reason you're seeing this is most likely because the server is sending the cross-signed X1 Root designed for compatibility when Let's Encrypt transitioned to the new X1 root which might not have been deployed everywhere yet. Kind of how they were cross-signed by IdenTrust when they started operating in 2015.

There is no reason today to continue presenting the cross-signed X1 root in your server chain since it will pose more problems than it will fix.

+ 5

MeSo2

8/11/24, 7:34 PM

I need to add that I've been having this issue https://serverfault.com/questions/1141176/apache-2-4-on-windows-slow-to-respond-to-initial-first-request, and after removing DST Root CA X3 it looks like the connection issue could have possibly resolved itself. I don't know if an expired root certificate can cause a connection problem. I also just renewed my certificate (that could have fixed it?) Would updating Apache from 2.4.39 to a newer version update these root certificates? I'm on Windows 10 Pro. I do still have a copy of the X3 certificate, and could drop it back into place. Recommended?

Ginnungagap

8/11/24, 8:11 PM

Windows 10 is not a suitable server OS so this question would fall out of scope for SE

MeSo2

8/12/24, 3:30 AM

I am not using IIS for certificates, but Apache. I would think Widows would have nothing to do with it -- or am I wrong?

dave_thompson_085

8/12/24, 3:31 AM

@MeSo2: Apache version is irrelevant for incoming connnections; all versions use the files you configure, or a tool like certbot configures for you, which should/will contain exactly the certs supplied by the CA (such as LE) plus your key (which you, or certbot etc, generated). (_Very_ old Apache versions, like before 2010, didn't support SNI and thus didn't support 'named' VirtualHost's on one address&port with different certs.) For outgoing proxies you also need to configure any trustedcerts; _here_ you _might_ use an OS-supplied file on Unix, but not Windows (without a lot of work).

MeSo2

8/12/24, 4:07 AM

@dave_thompson_085 The certificate I have is a wildcard certificate for *.filmfix.com. I am using that same certificate for all my VirtualHost's setups: some are hosted straight via Apache, and others are proxied from Apache to IIS. Apache is handling all calls and all the certificate load.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: DST Root CA X3 (Self-signed) - has expired in certificate chain used by Let's Encrypt (Apache/Windows)

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.