0

I'm in the process of setting up a FTP access over SSL on CentOS using VSFTPD and I'm having some issues.

I'm using an Apache with several Virtual servers, one for each domain.

Following some guides I've found on internet I managed to set up this config file, which I'm using together with the command openssl to generate both the cert and the key:

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
default_bits = 2048

[req_distinguished_name]
countryName                     = Country Name (2 letter code)
countryName_default             = ES
countryName_min                 = 2
countryName_max                 = 2

stateOrProvinceName             = State or Province Name (full name)
stateOrProvinceName_default     = My Province

localityName                    = Locality Name (eg, city)
localityName_default            = My City

0.organizationName              = Organization Name (eg, company)
0.organizationName_default      = My Company Ltd

organizationalUnitName          = Organizational Unit Name (eg, section)
organizationalUnitName_default  = WebServices

commonName                      = Common Name (eg, YOUR name)
commonName_default              = My Company Ltd
commonName_max                  = 64

[v3_req]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = myserver.com
DNS.2 = ftp.myserver.com
DNS.3 = mail.myserver.com
DNS.4 = julian.net
DNS.5 = ftp.julian.net
DNS.6 = mail.julian.net
DNS.7 = smith.org
DNS.8 = ftp.smith.org
DNS.9 = mail.smith.org
IP.1 = 111.112.113.114

I generate the cert and key using the following command:

openssl req -x509 -new -nodes -out certfile.crt -config certificate.conf -keyout keyfile.key -days 365 -newkey rsa:2048

After resetting vstfpd service, I connect to the server using FileZila and it complains with the message:

"ftp.myserver.com:21 - Host name does not match certificate"

In case I set the Common Name to "myserver.com", the problem is gone, but then the same problem appears with a different domain hosted on the server.

I suspect that I'm using the wrong approach and I should create a different cert for each domain, but the, sincerely, I don't know how to setup vsftpd.conf to point to a different cert, depending on the domain name.

Or maybe, do I have to store all certs for all the domains in a single file?

As you can see I'm pretty new to this, so I would really appreciate any help.

4
  • The config shows that you are trying to create a certificate request with the relevant subject alternative names. It does not show anything about the actual certificate. Likely this does not contain the subject alternative names. It is a common but wrong expectation that everything from the certificate request will definitely end up in the certificate. Check the actual certificate you use, i.e. openssl x509 -in cert.pem -text Commented Nov 26, 2020 at 14:37
  • @SteffenUllrich I've just executed that command and what I see is a bunch of parameters: Version, Serial Numbre, Signature Algorithm, Issuer, Validity, Subject, Public key, etc. But I don't see anything related to any of the domains described. Is there any way to incorporate this or should I merge several certificates into a single cert file, one after the other?
    – Carles
    Commented Nov 26, 2020 at 14:42
  • 1
    If you don't see any Subject Alternative Names (SAN) then these are not there - and this is the problem. It is unclear how you actually created your certificate, so I cannot tell you what you did exactly wrong. But there are several posts which ask why SAN where not included in the certificate and how to fix it, see stackoverflow.com/questions/30977264 or stackoverflow.com/questions/33989190 Commented Nov 26, 2020 at 14:51
  • I've just edited the question to add the full command with parameters used to generate the cert. I'll have a look to the post now
    – Carles
    Commented Nov 26, 2020 at 14:54

1 Answer 1

1
$ openssl req -x509 -new -nodes -out certfile.crt -config certificate.conf \
    -keyout keyfile.key -days 365 -newkey rsa:2048

This command is not using the extensions in the request. The extensions are only specified for req, i.e. for creating the certicate request but not the certificate. This means that Subject Alternative Names never end up in the certificate and thus the client rightfully complains about a mismatch.

To fix this specify that the extension should also be used in the certificate, using the -extension command line option:

$ openssl req -x509 -new -nodes -out certfile.crt -config certificate.conf \
    -keyout keyfile.key -days 365 -newkey rsa:2048 \
    -extensions 'v3_req' 

With openssl x509 -text this can then be checked:

$ openssl x509 -in certfile.crt -text
     ...
            X509v3 Subject Alternative Name: 
                DNS:myserver.com, DNS:ftp.myserver.com, DNS:mail.myserver.com, DNS:julian.net, DNS:ftp.julian.net, DNS:mail.julian.net, DNS:smith.org, DNS:ftp.smith.org, DNS:mail.smith.org, IP Address:111.112.113.114
1
  • Thank you very much! I've just realized the issue thanks to the links you gave me. That was very helpful!
    – Carles
    Commented Nov 26, 2020 at 15:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .