(Moved from StackOverflow) I've been asked to setup an FTPS connection, using a Client Authentication certificate. I'm the client, connecting to the server. I'm on a Windows 7 workstation, behind a firewall, although this connection will eventually be used on a dedicated CentOS VM. Some other info:

  • TLS 1.2 only
  • Passive mode only
  • My WAN IP is whitelisted
  • I'm connecting to a test URL, for now
  • There is no outbound firewall (only inbound rules)
  • Key should be sent in PEM format

I bought the certificate from Comodo, and generated the certificate with IE10. I exported the complete certificate from IE, with private key and extended properties, in the .pfx format.

I wrote a little batch file to extract the necessary parts from the .pfx, using OpenSSL:

::Extract the private key from the PFX
openssl pkcs12 -in comodo.pfx -nocerts -out encrypted.key
::Extract unencrypted private key
openssl rsa -in encrypted.key -out decrypted.key
::Extract the public cert in Base64 from the PFX
openssl pkcs12 -in comodo.pfx -clcerts -nokeys | openssl x509 -out comodo.cer
::Extract the chain bundle from the PFX
openssl pkcs12 -in comodo.pfx -nodes -nokeys -cacerts | openssl x509 -out comodo.crt

Using the extracted key parts, I have been trying various curl (v7.46.0) commands to connect to the FTPS server. The connection keeps failing. My latest attempt is below. The error is almost always the same.

curl -3 -k -v --ftp-ssl --tlsv1.2 --ftp-ssl-reqd --ftp-pasv --key decrypted.key --cacert comodo.crt --cert comodo.cer --user REMOVED:REMOVED ftp://ftps.REMOVED/

An example of the output is:

> curl -3 -v -k --user REMOVED:REMOVED --ftp-ssl --tlsv1.2 --ftp-ssl-reqd --ftp-skip-pasv-ip --cert comodo.cer --key priv.pem ftp://ftps.REMOVED/
*   Trying REMOVED_IP.
* Connected to ftps.REMOVED (REMOVED_IP) port 21 (#0)
< 220 Service ready for new user.
> AUTH SSL
< 234 Command AUTH okay; starting SSL connection.
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to ftps.REMOVED:21
* Closing connection 0 curl: (35) Unknown SSL protocol error in connection to ftps.REMOVED:21
>pause
Press any key to continue . . .

Strangely, if I connect with FileZilla, i can seem to get past the TLS handshake, but then I get different errors when I try to upload a file. As this connection will ultimately be made with curl, I've concentrated on this approach.

I've been trying this for over a week. The server admin has bought a certificate from my provider, and can connect without issue. I'm stumped on this one. Any help would be greatly appreciated. General curl / ftps debugging tips would also be appreciated.

  • Originally posted here: stackoverflow.com/questions/41124401/… – geonaut Dec 15 '16 at 10:23
  • Could you provide the config for the server side? – StackzOfZtuff Dec 15 '16 at 18:47
  • @StackzOfStuff I'm not in control of that side unfortunately, but it is a pretty big company that I'm connecting to, so I assume they are reasonably competent. I can ask them questions via their helpdesk, so if there is something specific I should check they are doing, I can try to get the info. – geonaut Dec 16 '16 at 14:59
  • Is it possible that the FTPS server's SSL stack is objecting to curl use/offering of "http/1.1" as the ALPN for an FTP session? To test this, you might try including --no-alpn in your curl command-line options. – Castaglia Dec 21 '16 at 3:27
  • Another test would be to run openssl s_client -connect <addr>:21 -starttls ftp -debug -msg. This would hopefully show more of the TLS handshake, as well as the alerts/messages involved. – Castaglia Feb 7 '17 at 3:11
up vote 0 down vote accepted

This ended-up being a non-FTP issue. The client system only allowed one CA certificate to be associated with one user, so some of our dummy users were preventing the CA key from being accepted. Thanks for everyone's help though.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.