Viewed   11.3k times

When I try to connect to any server (e.g. using curl (or libcurl) I get the error message:

curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

Verbose output:

$ curl --verbose  
* Rebuilt URL to:  
* Uses proxy env variable no_proxy == 'localhost,,localaddress,'  
* Uses proxy env variable http_proxy == ''  
*   Trying  
* Connected to ( port 8080 (#0)  
* successfully set certificate verify locations:  
*   CAfile: /etc/ssl/certs/ca-certificates.crt  
  CApath: none  
* TLSv1.3 (OUT), TLS handshake, Client hello (1):  
* error:1408F10B:SSL routines:ssl3_get_record:wrong version number  
* Closing connection 0  
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number'  

For some reason curl seems to use TLSv1.3 even if I force it to use TLSv1.2 with the command --tlsv1.2 (it will still print TLSv1.3 (OUT), ..." I am using the newest version of both Curl and OpenSSL :

$ curl -V  
curl 7.61.0-DEV (x86_64-pc-linux-gnu) libcurl/7.61.0-DEV OpenSSL/1.1.1 zlib/1.2.8  
Release-Date: [unreleased]  
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp  
Features: AsynchDNS IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets HTTPS-proxy  

I think this is a problem related to my installation of the programms. Can somebody explain to me what this error message means?


* Uses proxy env variable http_proxy == ''   

The https:// is wrong, it should be http://. The proxy itself should be accessed by HTTP and not HTTPS even though the target URL is HTTPS. The proxy will nevertheless properly handle HTTPS connection and keep the end-to-end encryption. See HTTP CONNECT method for details how this is done.

Saturday, August 20, 2022

The server supports only ECC ciphers (ECDHE-*). The version of curl is built with the NSS library on Redhat/CentOS. There is a bug report that Redhat/CentOS overrides the curl settings and disables ECC ciphers by default. Because there are thus no ECC ciphers offered by the client but only ECC ciphers are supported by the server the connection will fail.

You might try to explicitly give the cipher, i.e.

curl --ciphers ecdhe_rsa_aes_128_gcm_sha_256 ...

Note that upgrading OpenSSL would not help because curl is not built with the OpenSSL backend. Also it does not help to disable certificate validation (bad idea anyway) or to change the root CA's since the problem is not related to certificate validation at all.

Trying to explicitly give the cipher with --ciphers ecdhe_ecdsa_aes_128_sha as the cipher to solve the problem goes into the right direction but will not help in this case, because this is not one of the ciphers supported by the servers. The server supports only various ECDHE-RSA-* ciphers but not ECDHE-ECDSA-* ciphers. See SSLLabs for details.

Tuesday, November 8, 2022
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 0);

Change that to 1. Also, set this after CURLOPT_SSL_VERIFYPEER:

curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
Thursday, September 8, 2022

curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2

You are using a very old version of curl. My guess is that you run into the bug described 6 years ago. Fix is to update your curl.

Sunday, August 14, 2022

It usually happens when the certificate does not match with the host name.

The solution would be to contact the host and ask it to fix its certificate.
Otherwise you can turn off cURL's verification of the certificate, use the -k (or --insecure) option.
Please note that as the option said, it is insecure. You shouldn't use this option because it allows man-in-the-middle attacks and defeats the purpose of HTTPS.

More can be found in here:

Friday, August 12, 2022
Only authorized users can answer the search term. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :