From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1)
Gecko/20040707

Description of problem:

I want to use lftp to connect to an FTP server that encrypts the
control connection.

The local machine has the trusted root CA certificate in 
/etc/ssl.crt (files and hash symlinks)

/etc/lftp.conf shows the following lines:

---------
set ssl:ca-path "/etc/ssl.crt"
set ssl:verify-certificate yes
---------

But the connecion fails:

"Fatal error: SSL connect: unable to get local issuer certificate"

When one checks the parameters on the lftp commandline using 'set -a',
one notices that the value for "ssl:ca-path" is somehow mangled.
Apparently there is a Form Feed character immediately after "/etc",
because the first line at the top of the screen now shows:

--------- 
/ssl.crt
set ssl:cert-file ""
set ssl:crl-file ""
set ssl:crl-path ""
set ssl:key-file ""
--------- 

But if one scrolls back, it is clear what happened:

---------
set ftp:ssl-force no
set ftp:ssl-protect-data no
set ftp:stat-interval 1
set ftp:sync-mode on
set ftp:sync-mode/ftp.idsoftware.com on
set ftp:sync-mode/ftp.microsoft.com on
/ssl.crt
set ssl:cert-file ""
set ssl:crl-file ""
set ssl:crl-path ""
set ssl:key-file ""
set ssl:verify-certificate yes
---------

I tried various ways of getting a 'good' value into 'ssl:ca-path'
from lftp's command line but it looks like lftp has a real problem 
with an absolute path in "ssl:ca-path". Any attempt to use an
absolute path results in a mangled value.

Using a relative path works. And this means there is a workaround:

Set up:

set ssl:ca-path "etc/ssl.crt"

Start lftp from "/". The certificate file can now be found.

This may or may not be related to bug 89172.



Version-Release number of selected component (if applicable):
lftp-2.6.3-5

How reproducible:
Always