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.

Improve this question
1
  • Could there be some type of web proxy in place that is causing it to fail?
    – user247200
    Oct 8, 2014 at 17:55

5 Answers 5

Reset to default
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

Improve this answer
1
  • ditto. (Satellite) server had been upgraded between runs from the (RHEL 6.5) client; couldn't update anything until this was done.
    – Otheus
    Feb 1, 2017 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.

Improve this answer
1
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.

Improve this answer
0

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

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

Improve this answer
4
  • How update solve this issue ? **35 mean SSL connect error. The SSL handshaking failed. **
    – asktyagi
    Jun 2, 2019 at 11:34
  • @asktyagi: What operating system are you using? CentOS? Ubuntu? What version? What's the version of your cURL library?
    – nyedidikeke
    Jun 2, 2019 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 3, 2020 at 4: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 3, 2020 at 6:54
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]#

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .