This question already has an answer here:

I can't get curl to download on a CentOS 6.2 server.

The command curl -v -k -3 yields:

* About to connect() to port 443 (#0)
*   Trying connected
* Connected to ( port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* warning: ignoring value of ssl.verifyhost
* skipping SSL peer certificate verification
* NSS error -5938
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error

What I've tried so far:

1) Issue the very same curl command on servers hosted with other providers, on my linux dev machine and on my teammates machines: the page downloads just fine;

2) google for NSS error -5938, which did not provide a single helpful tip.

3) Ditch curl and use wget: won't work, since the remote server uses Transfer-Encoding:chunked, which wget doesn't play with.

4) Upgrade/downgrade/compile lastest version of Curl, NSS and OpenSSL: the problem persists.

5) Report the problem to the server provider. First they claimed it was a issue with the remote server certificate; I'm doubtful that's the case, since I've told curl do ignore certificate validation (-k flag).

6) Extract a tcpdump of the connection, where "funny" things where found (upper capture):

There are many transmission errors, and the server response to the "Client Key Exchange" phase never reaches our server - even though the ACK packet does! - note the 30s gap between packets 46 and 47. (this happens even if the firewall is disabled)

For comparison, curling paypal (lower capture) goes just fine.

7) Recontact the server provider, showing the tcpdump findings. They commented nothing about the dump, but said that they tried the command on other servers on their network, and the command failed the same way. Despite this, they still claim the problem is the remote server crappy certificate, and the way I handle it.

So, what am I missing?

PS: here are some version numbers:

curl -v

curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/ Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2 Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

uname -a

Linux [redacted hostname] 2.6.32-220.23.1.el6.x86_64 #1 SMP Mon Jun 18 18:58:52 BST 2012 x86_64 x86_64 x86_64 GNU/Linux

marked as duplicate by Hyppy, Nathan C, Jenny D, Michael Hampton Apr 28 '15 at 14:40

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • The problem is at the server end, not the client end. The server hung up on you. And anyway it is extremely insecure and desperately needs to be fixed as soon as possible. – Michael Hampton Apr 28 '15 at 14:41
  • Thanks Michael. Can you elaborate a bit more why the server hung up the connection from that particular server, but not the other servers? (as for security, I doubt the server will ever be fixed... but I will try to contact the administrators nevertheless) – Wagner Apr 28 '15 at 20:54
  • There's nothing more to say. To find out, you would have to be one of the administrators of that server, so that you could inspect its logs. – Michael Hampton Apr 28 '15 at 20:59

Browse other questions tagged or ask your own question.