[CentOS] VSftp, ssl/tls, slight issue with directory listings

Fri Mar 2 07:09:03 UTC 2012
Bob Hoffman <bob at bobhoffman.com>

Centos 6, stock installation, no additional repos added.

vsftp works fine in regular mode, going to ssl I got issues. I get as 
far as 'directory listing' and it dies. It times out and disconnects.

file: /etc/sysconfig/iptables-config
added: IPTABLES_MODULES="ip_conntrack_ftp"
(without this line, ftp normally fails, afraid it may be causing issues 
with the ssl)

-A INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT
again, normal ftp fine.

vsftp file
below are the additional commands I entered to get ssl/tls up and running.


implicit_ssl=yes <--- tried with and without this and the port 21 below
listen_port=21 <-- see above
force_local_data_ssl=NO <-- set this to yes so I can still test normal 
ssl_ciphers=HIGH <-- this was added as I was using filezilla and it 
wanted different ciphers. without this it would have a tls fatal error, 
adding this absolved that issue.

Now I have tried playing with the settings and in all cases when it can 
connect it dies at directory listing.
Implicit ssl wants 990, but the listen_port directive can tell it to go 
to 21. Again, full connect, changes folders, dies at trying to display 
contents of initial folder.

I have redone the pem a few times and even moved it in and out of the 
vsftpd folder just for kicks, no joy.

I tried opening port 990 and that made no difference at all (even 
changing listen_port or leaving it commented out)

so, cannot figure what is up. Most online notes are for non-centos 6 
and/or generally follow this same set of commands. Most of the debug 
threads about this issue deal with plain connections and not tls/ssl.

I can find no solution yet, has anyone out there secured their vsftp 
server and wanna throw me a bone?

Only this and two other things prevent me from throwing out a nice video 
tutorial of how to go from a stock install to a fully armed and 
operational webserver, ssl everywhere, etc....

all nighter and no where with this one. At least not yet.