Thanks for your answer. I have checked that Comodo's root CA
certificate is present in the certificate bundle file, however
Comodo's intermediate CA certificate (that signed the server's
certificate) isn't, as is normal if I understand correctly.

The certificate hierarchy is as follow (as shown by Firefox > Page
Info when connecting to

COMODO RSA Certification Authority
  COMODO RSA Organization Validation Secure Server CA

Certificate validation fails as described whether I point to the root
CA certificate bundle file or to the relevant root certificate only:

  set ssl:ca-file /etc/ssl/certs/ca-certificates.crt
  set ssl:ca-file /etc/ssl/certs/COMODO_RSA_Certification_Authority.pem
  set ssl:ca-file

It succeeds if I point to the intermediate CA certificate, but I
shouldn't have to do that, should I?

  set ssl:ca-file

I checked using lftp 4.6.3a (Ubuntu 16.04) and 4.7.7 (latest stable) BTW.

On Sun, Mar 12, 2017 at 8:29 AM, Alexander Lukyanov <> wrote:
> Your understanding of CA is correct. The Comodo certificate should be
> present in the CA bundle for the verification to succeed.
> вс, 12 марта 2017, 5:16 Nathanaël Naeri <>:
>> I'm trying to connect to a FTP server that supports explicit FTPS
>> using TLS, but I can't get certificate verification working. Most of
>> the online help I find advises disabling certificate verification with
>> "ssl:verify-certificate no", and I assume this is not good advice.
>> My current understanding of the process is that lftp downloads the
>> server's certificate when it negotiates TLS, then follows the
>> certificate chain up to the certificate of a root CA, and trusts that
>> root CA because it is in my list of trusted third parties, that I
>> indicate to lftp using "ssl:ca-file
>> /etc/ssl/certs/ca-certificates.crt" (the root CA certificates bundle
>> file). This is, as far as I know, what web browsers do when they
>> connect to HTTPS hosts (isn't it?).
>> This doesn't appear to work so I guess I don't understand right. The
>> debug output is:
>> $ lftp -d -p 21 -u USER,PASS
>> lftp> set ssl:ca-file
>> /etc/ssl/certs/ca-certificates.crt
>> lftp> ls
>> ---- Connecting to (IPADDRESS) port 21
>> <--- 220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
>> <--- [other 220 info]
>> ---> FEAT
>> <--- [feat reply]
>> ---> AUTH TLS
>> <--- 234 AUTH TLS OK.
>> ---> OPTS UTF8 ON
>> Certificate:
>> C=FR,postalCode=77310,ST=Seine-et-Marne,L=PRINGY,street=IMPASSE
>> DU BREAU,O=SDBX FRANCE,OU=0002 529997199,CN=*
>>  Issued by: C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA
>> Limited,CN=COMODO RSA Organization Validation Secure Server CA
>> ERROR: Certificate verification: Not trusted
>> **** Certificate verification: Not trusted
>> ---- Closing control socket
>> ls: Fatal error: Certificate verification: Not trusted
>> However, if I download the server's certificate beforehand, using a
>> web browser or the OpenSSL CLI (openssl s_client -connect
>> -starttls ftp), and then points lftp to this
>> certificate using "ssl ca-file
>> /path/to/manually/downloaded/server/certificate.crt", the certificate
>> verification succeeds. Why? What is verified in this case, precisely?
>> That the certificate lftp downloads from the server during TLS
>> negotiation is the same as one that was previously downloaded? How
>> does that authenticates the server?
>> And does this mean that the user has to maintain a certificate
>> database of the servers they connect to? I thought the point of
>> certificate hierarchies was that the user would only have to maintain
>> a short list of trusted third party certificates (the root CA
>> certificates).
>> Thanks in advance for your help
>> Naël
lftp mailing list

Reply via email to