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.
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:
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:
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.
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".
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 ), 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 !
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).
(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...
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.
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?
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.
@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)
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...
), and couldn't connect (TLS Alert : Handshake failed), so ProFTP is definitively using fullchain_FTP.pem .
