It appears that "open -d"; works indeed
("Trusted", certificate chain printed out as in your previous
message), but "open -d -p 21 -u USER,PASS" doesn't
("Certificate verification: Not trusted", same output as reported in
my first message).

Using lftp 4.7.7 with GnuTLS 3.5.10 and my CA bundle. I also checked
manually that both your CA bundle and mine:
  * don't include COMODORSAOrganizationValidationSecureServerCA.pem
  * include COMODORSACertificationAuthority.pem
  * don't include COMODORSAAddTrustCA.pem
So they're not different in this respect. It's not clear to me, which
one is the root CA certificate. Only the AddTrust one is self-signed,
but the certificate chain printed by lftp with GnuTLS stops at the
second one, while that using OpenSSL includes the last one.

The server certificates coming from the HTTP and FTP servers are the
same: I downloaded one from using Firefox 52 >
Page Info and the other from using "openssl s_client
-connect -starttls ftp": they're the same except
for the end-of-line characters, and apply both to *

Is that an issue that this hosting company could do something about? I
can ask their sysadmins for help.

On Mon, Mar 20, 2017 at 12:52 PM, Alexander V. Lukyanov <> wrote:
> On Sat, Mar 18, 2017 at 09:13:27PM +0100, Nathanaël Naeri wrote:
>> Thank you for your answer. I have updated my version of GnuTLS to
>> 3.5.10 and compiled lftp 4.7.7 against it. The resulting "./lftp
>> --version" shows "Libraries used: Readline 6.3, Expat 2.1.0, GnuTLS
>> 3.5.10, zlib 1.2.8". Yet the error I reported in my first message
>> remains: "Certificate verification: Not trusted".
>> What commands did you use in your last message to verify certificate
>> chains? The output I get with openssl verify and certtool is quite
>> different.
> I did "open -d";. My CA bundle is attached.
> --
>    Alexander.
lftp mailing list

Reply via email to