curl error despite --insecure and w/o proxy: ssl3_get_record:wrong version number

I'm using git-ftp for deployment of some sites, and with one server I don't manage to establish a connection through TLS.

curl -vv --insecure ftps://linux12.unixserver.org:21
* Rebuilt URL to: ftps://linux12.unixserver.org:21/
*   Trying 212.63.145.118...
* TCP_NODELAY set
* Connected to linux12.unixserver.org (212.63.145.118) port 21 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* error:1408F10B:SSL routines:ssl3_get_record:wrong version number
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

I already found several other questions, but my issue doesn't match.

I'm not using a proxy
Even --insecure will fail, so it can't be a cert trust issue
I tried --cacert as well, doesn't work
--tls-max 1.2 will change version to 1.2, but it doesn't change anything

Some source states that this error also occurs when the server doesn't deliver a cert at all.

openssl s_client -connect linux12.unixserver.org:21 -starttls ftp

Delivers a certificate, so that seems to be alright.

I can successfully connect by means of Nautilus, but it's warning me about the certificate, that the issuer is unknown.

Thanks very much for any hint on what else to try.

Solution

Actually two issues were involved in this case.

1) ftps is the wrong protocol for servers that only support explicit tls.

The right protocol would be ftpes. If curl is not compiled with support for it, you can use --ssl-reqd to enforce TLS, or just --ssl.

In context of git-ftp it works even if curl is compiled w/o ftpes.

2) The server didn't deliver a valid certificate chain, so the certificate could not be validated.

This is currently a ftp certificate bug in plesk.

The solution is to retrieve the certificate chain manually and provide the chain by means of --cacert <file>. If it's self-signed, extract the public key and use --pinnedpubkey <file>.

Thanks very much to Daniel Stenberg for the right hints.