Let's Encrypt certificate not accepted

[Jean Soulat]

Hello,

It looks like I have the same problem as reported in #12691 (Trust ISRG Root X1 and ignore "cross-signature" DST Root CA X3 certificates)

I use FileZilla v3.59.0 (Windows 10.0 64b). The About box shows GnuTLS: 3.7.2

I am migrating from a VPS with Plesk to a more up-to-date config (also VPS with Plesk). Both use a Let's Encrypt certificate.

FileZilla connects correctly to the older VPS. It does not accept the certificate for the new VPS because of the expired DST Root CA X3 certificate.

[Tim Kosse]

Make sure that the server is not including the expired root in the list of certificates it sends during the TLS handshake.

Also, the expired certificate might still be in your system's trust store. If so, try removing it from there.

[Jean Soulat]

Dear Mr Kosse,

Thank you for your quick reply but I do not understand.

1) "Make sure that the server is not including the expired root in the list of certificates it sends during the TLS handshake."
I have no expertise in these matters, although I tried to understand as much as possible. My server is Debian with Plesk, provided by OVH. OVH "support" sent me an unofficial link to remove the expired DST Root CA X3 certificate from some place in the server. I did it without fully understanding:

rm /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
vi /etc/ca-certificates.conf
and remove
mozilla/DST_Root_CA_X3.crt
update-ca-certificates

From ​https://www.howtoforge.com/community/threads/lets-encrypt-dst-root-ca-x3-expiration-september-2021.87761/#post-427870

It still did not work afterward although I restarted the server.

2) "Also, the expired certificate might still be in your system's trust store. If so, try removing it from there."

Yes, the DST_Root_CA_X3 certificate, expired on September 30, 2021 was in my Windows list of trusted root certificates. I removed it and the problem seemed to be solved. Unfortunetaly Windows reinstalls it after some time and the problem is here again.

3) My understanding at the moment, is as follows:

• Let's Encrypt seems to have done something unusual by putting their root certificate (ISRG Root X1) as an intermediate certificate.
• This works correctly if the browser or FileZilla (or any client app) recognizes ISRG Root X1 as a trusted certificate although it is in intermediate position.
• Unfortunately, for some Let's Encrypt certificates (not all), FileZilla ignores ISRG Root X1, reaches the expired DST Root CA X3 and decides that the server certificate is not valid.

IMHO, this is a bug in FileZilla (or GnuTLS) and I take the liberty to reopen the ticket. The post above mentioned a nightmare, I can confirm that.

Thank you so much for your efforts with FileZilla. It is a wonderful software.

[Jean Soulat]

Correction: putting a ISRG Root X1 in intermediate position is standard cross-signing, validation should succeed.

[Jean Soulat]

Update May 22, 2022: I checked the server with Qualys. SSL Labs web page.

Certification Paths for all 5 tabs (Mozilla, Apple, Android, Java, Windows) show similar results:

Path # 1: Trusted
1 Sent by server: (Server certificate)
2 Sent by server: R3
3 In trust store: ISRG Root X1 Self-signed

Path # 2: Not trusted
1 Sent by server: (Server certificate)
2 Sent by server: R3
3 Sent by server: ISRG Root X1
4 In trust store: DST Root CA X3 Self-signed EXPIRED

This seems to confirm that there is a valid certification path and FileZilla doesn't find it.

As long as DST Root CA X3 was present in the Windows trust store, the FileZilla trust boxes could not be checked. The first one could be checked after DST Root CA X3 was removed from the Windows trust store.

Warning: DST Root CA X3 is recreated automatically after a few hours.

The FileZilla checkbox Edit > Settings > "Use system trust store to validate TLS certificates" does not seem to change anything.

It is not clear if removing DST Root CA X3 was needed.

My workaround:

(1) Remove DST Root CA X3 from Windows trust store.
(2) Start a connection to the server and check "always trust".
(3) If still not working, remove DST Root CA X3 from the server and redo steps (1) and (2)

And (4) I EXPECT THE PROBLEM TO HAPPEN AGAIN WHEN THE LET'S ENCRYPT CERTIFICATE IS RENEWED since Windows recreates DST Root CA X3.

[Tim Kosse]

I checked the server with Qualys. SSL Labs web page.

That site only checks HTTP servers. How did you check the certificate of the FTP server?

[Jean Soulat]

For FTP, I wrote a small C# program with Visual Studio and the AlexFTPSv2 NuGet package. A RemoteCertificateValidationCallback shows an X509Chain parameter:
(Server certificate) > R3 > ISRG Root X1

However I couldn't be sure if it shows the chain exactly as sent by the server, or already with some interpretation by Windows.

So I used the web server test at www.ssllabs.com/ssltest/ for web servers because at least it shows the interpretation by various clients (Mozilla, Apple, etc.)

[Jean Soulat]

Update May 28, 2022

I am migrating from an old server (TLS 1.3 not accepted) to a new one (TLS 1.3 working). The problem is only with the new one:

• The result above with AlexFTPSv2 is for the new server but AlexFTPSv2 seems limited to TLS 1.2.
• No way to check the certificate chain with FTP and TLS 1.3 except that FileZilla shows DST Root CA X3 as the root certificate as long as it is in the Windows trust store.
• When I delete DST Root CA X3 in the Windows trust store (and as long as Windows has not yet recreated it), FileZilla reports the certificate chain as: (server certificate) > R3 (intermediate) > ISRG Root X1 (intermediate), no root certificate.
• Since I am supposed to have removed DST Root CA X3 from the server, I tend to believe that the problem is with the TLS 1.3 handshake.