cURL / Mailing Lists / curl-users / Single Mail

curl-users

Re: curl not using tls even if told to do so

From: Kamil Dudka <kdudka_at_redhat.com>
Date: Wed, 05 Nov 2014 10:55:20 +0100

On Wednesday 05 November 2014 09:37:48 George wrote:
> > Those are not from the CentOS repository but they seem to be linked with
> > NSS. Please paste the verbose output of NSS-powered curl with the
> > --tlsv1.2 option and without the --cipher option.
>
> Here it is:
> /usr/bin/curl -v --tlsv1.2 --key ./key.pem --cert ./cert.crt
> https://somedomain.com/somepath
> * Hostname was NOT found in DNS cache
> * Trying 1.1.1.1...
> * Connected to somedomain.com (1.1.1.1) port 443 (#0)
> * Initializing NSS with certpath: sql:/etc/pki/nssdb
> * CAfile: /etc/pki/tls/certs/ca-bundle.crt
> CApath: none
> * NSS: client certificate from file
> * subject: serialNumber=CVR:51975413-FID:46287736+CN=hidden //
> CVR:51975413,C=DK
> * start date: Oct 04 06:42:29 2014 GMT
> * expire date: Oct 04 06:40:52 2017 GMT
> * common name: hidden
> * issuer: CN=TRUST2408 OCES CA II,O=TRUST2408,C=DK
> * NSS error -12227 (SSL_ERROR_HANDSHAKE_FAILURE_ALERT)
> * SSL peer was unable to negotiate an acceptable set of security parameters.
> * Closing connection 0
> curl: (35) SSL peer was unable to negotiate an acceptable set of
> security parameters.

So it fails with the same scenario in both cases. The server responds with
handshake failure alert.

Back to your original question. I believe that TLS 1.2 is used in both cases.
The verbose output of OpenSSL is just misleading. You can use e.g. wireshark
to check what exactly is being negotiated and figure out why it fails.

Kamil
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ: http://curl.haxx.se/docs/faq.html
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-11-05