Curl: (35) SSL connect error

curl

I am trying to make a cURL HTTPS request to the Twitter API and I am getting this error:

[root@webscoming httpdocs]# curl -v https://api.twitter.com
About to connect() to api.twitter.com port 443 (#0)
Trying 199.16.156.199... connected
Connected to api.twitter.com (199.16.156.199) port 443 (#0)
Initializing NSS with certpath: sql:/etc/pki/nssdb
CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
NSS error -5990
Closing connection #0
SSL connect error
curl: (35) SSL connect error

I have tried this from another server and it works as expected. What does that error mean and how do I resolve it?

My server is running CentOS version 6.5.

Please note: I can correctly connect to https://encrypted.google.com but unsuccessful with https://api.twitter.com.

Best Answer

I saw a similar kind of problem, yet not accessing twitter.
Problem I saw was on RHEL 6.1 -> RHEL 6.4, using curl to access a REST API. curl showed error: curl: (35) SSL connect error

Issue ended up being that our server running the REST API was RHEL 6.6, using a newer version of NSS. Once we upgraded the client NSS version curl was successful.

We upgraded the client from: nss-3.12.10-2.el6_1.x86_64

to: nss-3.16.1-14.el6

Related Solutions

SSL Certificate – Displaying Remote SSL Certificate Details Using CLI Tools

You should be able to use OpenSSL for your purpose:

echo | openssl s_client -showcerts -servername gnupg.org -connect gnupg.org:443 2>/dev/null | openssl x509 -inform pem -noout -text

That command connects to the desired website and pipes the certificate in PEM format on to another openssl command that reads and parses the details.

(Note that "redundant" -servername parameter is necessary to make openssl do a request with SNI support.)

Curl SSL Certificate – How to Debug ‘Unable to Get Local Issuer Certificate’ in Curl

Using openssl s_client -connect thawte.com:443 shows:

---
Certificate chain
 0 s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/O=Thawte, Inc./C=US/ST=California/L=Mountain View/businessCategory=Private Organization/serialNumber=3898261/OU=Infrastructure Operations/CN=www.thawte.com
   i:/C=US/O=thawte, Inc./CN=thawte Extended Validation SHA256 SSL CA
 1 s:/C=US/O=thawte, Inc./CN=thawte Extended Validation SHA256 SSL CA
   i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2008 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA - G3
---

That last "i" shows the issuing self-signed root CA. I'm guessing that that particular Thawte root CA, _i.e. the Primary Root CA - G3 cert, is not in your /etc/ssl/certs directory (as stated in the curl output; openssl s_client does not have a default CA path, and needs to given one explicitly, e.g. -CApath /etc/ssl/certs).

Adding that certificate explicitly to your /etc/ssl/certs directory (and re-running c_rehash) certainly wouldn't hurt. And if it works, e.g. as verified using openssl s_client -connect example.com:443 -CApath /etc/ssl/certs, then you know that that update-ca-certificates command may need some examination/debugging, as to why it hadn't picked up this root CA.

Now, it may be that the above root CA is already in your /etc/ssl/certs directory, and the above steps had no effect. In that case, there are two other issuing CA certs to check (at least in the cert chain offered by thawte.com:443): thawte Primary Root CA, and thawte SSL CA - G2. Repeating the above steps to install these certs into your /etc/ssl/certs directory (and re-running c_rehash) might work. Since these two are intermediate CAs, and not root CAs, the absence of one of them would explain your results, and might be expected as overlooked certs by update-ca-certificates.

Hope this helps!