Root Certificate expired for Filezilla but not for Firefox

My domain is: managames.com

The operating system my web server runs on is : Debian 9

I can login to a root shell on my machine : yes

I'm using a control panel to manage my site : Virtualmin

The version of my client is : certbot 0.28.0

I have been using the Let's Encrypt's certificate for my FTP Server (ProFTPD) since beginning of 2020 without any problem using this trick : Simple Guide: Using Lets Encrypt SSL certs with Dovecot - #21 by riser .

Since the Root certificate has expired, FileZilla gives me a warning when I connect to my FTP, showing the old Root certificate and not the new ISRG Root X1. If I check my website certificate with Firefox, I can see the correct IS RG Root X1.

What dark magic is that..?!? :dizzy_face:

My FTP Config contains :

TLSRSACertificateFile /etc/letsencrypt/live/static.managames.com/fullchain.pem
TLSRSACertificateKeyFile /etc/letsencrypt/live/static.managames.com/privkey.pem

Thanks in advance for any help ! :grinning:

Browsers start with the "leaf" you sent them and then make up their own "intermediates". They do this to adapt to poorly configured servers and other reasons. To see the actual chain your server sends use a site like this:
https://decoder.link/sslchecker
It shows you are sending the default long chain.

Let's Encrypt now offers a default (long chain) and alternate (short chain). This website and many others use the default long chain. Here is more info about these choices:

3 Likes

As mentioned: You could try switching to the shorter/alternate chain.
And you could also reissue the cert, but from another (free and ACME friendly) CA.

3 Likes

If I understand the rapport correctly, decoder.link states that my long chain root is X1, like Firefox shows, and thus my certificate is up to date.

So should I conclude that for some reason Filezilla doesn't process that long chain correctly and guess incorrectly the root ? That'd seem odd... :thinking:

I'd rather not switch to the short chain, as the long one seems to be the correct choice for my website.

WHY?

Do you know the difference between them?
Logic would dictate that both are valid [CAs don't produce invalid certs for such public use].

1 Like

It's stated in the big quote of @MikeMcQ :

The long chain (recommended for most websites/services)

I have not used Filezilla for a long time but it is not that odd. Even older versions of openssl do not process the long chain properly. openssl is a commonly used program and often integrated with others. The openssl group announced work-arounds for systems that could not update it easily.

Other than Rudy's options, you could make a copy of .../static.managames.com/fullchain.pem and manually remove the last cert (it is the DST Root CA X1). This is making the "short chain" manually. Then use this copy in your FTP TLSRSACertificateFile setting. You will need to edit and copy this each time you refresh the cert.

The 1.12 and later versions of Certbot can create this "short chain" easily but Debian 9 certbot is not easily updated. See this thread.

You could also check Filezilla for updates or their forum for any clues how to tolerate the "long chain".

2 Likes

I copied fullchain.pem to fullchain_FTP.pem and removed the last "-----BEGIN CERTIFICATE----- / -----END CERTIFICATE-----" (so there are 2 certificate sections left), updated my ProFTP config file to use fullchain_FTP.pem, restarted ProFTP, but I still get the same error when I'm connecting with Filezilla.

I then removed the 2nd certificate, and got still the same error.

Finally, I removed the 1st one (so the file is empty :stuck_out_tongue: ), and couldn't connect (TLS Alert : Handshake failed), so ProFTP is definitively using fullchain_FTP.pem .

I'm still puzzled by what's going on, so if you have any other ideas, I'll take them ! :slight_smile:

Try getting a cert from another (FREE and ACME friendly) CA.

1 Like

Are you sure it was the same error? After removing the DST cert it would not be visible to Filezilla. You may have gotten some error but it should not be the same.

Knowing what the error was may give a clue to the Filezilla problem

This is a tool to see the cert chain your server is sending (dont use a browser - they make up their own chain).
https://decoder.link/sslchecker

1 Like

I just checked again and it's really exactly the same error whether I have 1 or 2 certificates left in my pem file :

(I guess there's no sensitive data on that screenshot, but if there are some, please let me know so I'll delete it)

Note : the "Hostname doesn't match the certificate" isn't problematic, I also tried to connect with the correct host and it didn't change anything.

@rg305 , changing of Certificate Authority is way overkill for a problem that is solved by a click on "Ok" once in a while... :slight_smile:
Plus it's not really the correct solution as I'd like to understand what's going on.

Hmm. Did you restart the server service Filezilla is connecting to after changing its cert? Most servers need a reload/restart to see a change and send the new one.

1 Like

Yes, I did, although I checked if it was needed by deleting the last certificate without applying the config to the FTP server and actually it worked (I guess the pem file is loaded on each client connection)

I am not sure what you mean by that but in general the server sends the cert chain and the client decides how to verify it. Browsers mostly just look at the "leaf" and try to build a trust chain themselves.

Perhaps Filezilla does something similar but built it "wrong" and leading to the DST Root. Note this is what older openssl versions do too as I described earlier. Maybe look at your client machine CA Certificates and see if you can remove DST Root CA X3 from it.

Or, do you mean it is working properly now even without changing the FTP server?

2 Likes

Sorry, I meant the reloading of the pem file worked without restarting the FTP server.

I tried to disable both the intermediate R3 & root X3 certificates with CertMgr in Windows 10 (I didn't delete them, though), but it didn't change anything for FileZilla.

Ok. If this site says you are only sending thru ISRG Root X1 (and not DST Root) then any error from Filezilla relates to how it is building the cert chain.
https://decoder.link/sslchecker

I do not know Filezilla well. You might hunt around here looking for how people update Windows so IIS builds the right chain. Windows systems getting active updates generally need no action. But, others apparently can be updated manually. I do not have any links handy nor do I know that off-hand. Maybe Filezilla will benefit from same updates as IIS? Or, try a Filezilla forum.

2 Likes

@manu2 Another cause of this problem may be your FTP server. That config comes from ProFTPD - is that it?

Anyway, some older based servers only send the "leaf" certificate even when given a chain. Without a suggested chain the client (Filezilla in this case) are left to try to create the chain on their own - and in this case is failing.

Using that ssl checker site with your FTP server domain name and port should tell you what is being sent. You have not shared that info yet so I cannot check it. I usually use something like:

echo | openssl s_client -connect static.managames.com:443 -servername static.managames.com | head

Note the port 443 and then see if the Chain ends with ISRG Root or DST Root (or, is 2 or 3 certs long)

2 Likes

sslchecker shows me 3 certificates in the Chain Information, so I guess my config is ok.

And I guess you're right, it might be an issue with FileZilla, so I'll look on that side.

Thanks for all the help ! :slight_smile:

No, if it is showing 3 certs that is the "long chain" ending in DST Root CA X3 so is not the one you updated to remove that. See the post I made just as you did yours

Update: You want it to send a chain that looks something like the one for this site

valid-isrgrootx1.letsencrypt.org

Of course, the first cert will be yours and not the one w/CN=valid-isrgrootx1...

2 Likes

Oops, sorry, I thought you meant to check the www certificate.

I just checked the FTP certificate (ie: the unmodified Let's Encrypt one, but sent by the FTP server), and actually there are 2 errors :

  • We were unable to verify this certificate
  • The chain doesn't contain any intermediate certificates

And the output shows only 1 certificate is sent, not 3, so I guess the real culprit is ProFTPD or at least its configuration.

I'll search if it's possible to change that ProFTP behavior.

Note : it's the exact same result with only 2 certificates.