11

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.

bjoster
  • 4,805
  • 5
  • 25
  • 33
  • Could there be some type of web proxy in place that is causing it to fail? –  Oct 08 '14 at 17:55

5 Answers5

21

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

John Matthews
  • 311
  • 2
  • 4
  • ditto. (Satellite) server had been upgraded between runs from the (RHEL 6.5) client; couldn't update anything until this was done. – Otheus Feb 01 '17 at 17:10
5

According to the source code that error means a time out. Your network connection to that host is most likely faulty. It might also be that Twitter filters out your IP for whatever reason.

liquidat
  • 520
  • 4
  • 3
  • This looks like the new URL for the source code https://dxr.mozilla.org/mozilla-central/source/nsprpub/pr/include/prerr.h#46 – Nobu May 02 '18 at 21:16
1

It can be a badly configured proxy responding in http instead of https. I've had the case of a proxy always responding in http to the client, no matter the original protocol, when the requested site was blacklisted.

So more generally, this error occurs also when you get a response not TLS encrypted.

Hexdump
  • 56
  • 2
0

I have this issue and also have another issue in Centos 6.6 full version.

yum upgrade Loaded plugins: aliases, auto-update-debuginfo, changelog, downloadonly, fastestmirror, filter-data, fs-snapshot, keys, list-data, local, merge-conf, post-transaction-actions, presto, : priorities, protectbase, ps, remove-with-leaves, rpm-warm-cache, security, show-leaves, tmprepo, tsflags, upgrade-helper, verify, versionlock Setting up Upgrade Process Determining fastest mirrors http://vault.epel.cloud/6.10/os/x86_64/repodata/repomd.xml: [Errno 14] problem making ssl connection Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: C6.10-base. Please verify its path and try again [root@ Packages]#

0

cURL error number 35 has to do with an outdated cURL version.

To resolve this, you need to update your cURL package.

nyedidikeke
  • 111
  • 6
  • How update solve this issue ? **35 mean SSL connect error. The SSL handshaking failed. ** – asktyagi Jun 02 '19 at 11:34
  • @asktyagi: What operating system are you using? CentOS? Ubuntu? What version? What's the version of your cURL library? – nyedidikeke Jun 02 '19 at 14:48
  • @nyedidikeke until now I thought that is true, however now I know that's no longer the case, as I just got same error even with `curlimages/curl:latest` version – alexus Mar 03 '20 at 04:31
  • @alexus: You are right. cURL error 35 may have appeared to be occur particularly with "older versions" and necessitated the then miraculous "update" as fix due to paths or permissions issues. With a newer version, this could be same underling cause, just as a file format or passwords issues, just to mention a few. Can you share more details about your environmental setup, the specific command run and the error buffer please? – nyedidikeke Mar 03 '20 at 06:54