7

Having a strange issue with cURL and PHP on a couple of CentOS boxes.

Locally, I'm running CentOS 6.3. Remote is CentOS 5.9

Locally, the box receives a request, scp's a file to the remote server, then performs a cURL request via PHP to the remote server to send some info. The request always fails on the first attempt of the day. Subsequent requests work fine. Remote has a valid SSL cert -- even so, turning off cert and host verification does not fix the problem.

The logging has not been very helpful. Turning verbosity up to 11, the most meaningful entries are as such:

* About to connect() to www.example.com port 443 (#0)
*   Trying 203.0.113.10... * connected
* Connected to www.example.com (203.0.113.10) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -5938
* Closing connection #0
* SSL connect error

Googling the error doesn't help much either. Looks like twitter was having a similar problem (https://dev.twitter.com/discussions/1549) which they apparently fixed, but didn't elaborate on how it got fixed.

Any ideas on where to look/what to do to mitigate the problem would be appreciated.

stormdrain
  • 1,377
  • 7
  • 28
  • 51

3 Answers3

6

it's general problem for curl compiled with NSS (only redhat-linuxes, debian and suse curl packages compiled without nss). you need compile curl from sources without nss-library.

so, i haven't solution how https-connections worked with nss-curl.

curl --version curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.14.3.0 zlib/1.2.7 libidn/1.26 libssh2/1.4.3 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz

curl --version curl 7.25.0 (x86_64-suse-linux-gnu) libcurl/7.25.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25 libssh2/1.4.0 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP

nexoma
  • 76
  • 4
  • 3
    For us the problem was specifically related to NSS support for TLS 1.2; forcing the TLS version to 1.1 resolved the problem, e.g. curl --tlsv1.1 www.example.com). Forcing the TLS version allowed us to continue using the NSS version. – El Yobo Nov 11 '15 at 03:20
  • Thanks for the help @ElYobo I was struggling for 4 days now. Was unable to find a root cause for this.You Rock – Amanpreet Feb 03 '20 at 12:37
  • Thanks @nexoma for the answer. Upvote for you as well – Amanpreet Feb 03 '20 at 12:38
3

I encountered a similar "NSS error -5938" when using an outdated CentOS 6.x system to connect to an embedded device that stopped accepting TLS 1.0, only allowing TLS 1.1 and higher. The solution for me was to do a yum update. I saw these updates occurred:

---> Package curl.x86_64 0:7.19.7-46.el6 will be updated
---> Package curl.x86_64 0:7.19.7-52.el6 will be an update
...
---> Package nss.x86_64 0:3.21.0-0.3.el6_7 will be updated
---> Package nss.x86_64 0:3.21.3-2.el6_8 will be an update

I think this might be the specific change that helped:

$ rpm -q --changelog curl
[...]
* Mon Jan 11 2016 Kamil Dudka <kdudka@redhat.com> 7.19.7-50
- use the default min/max TLS version provided by NSS (#1289205)
doshea
  • 133
  • 5
0

The NSS error 5938 message usually means the server killed your connection. You should check the server side logs of curl's target to see why your connection was killed.

It might be something as simple as "could not get a reverse dns hostname for X".

Andrew Domaszek
  • 5,103
  • 1
  • 14
  • 26
  • Yeah, there isn't anything in the server httpd logs. I see the POST to it, but that's it. Are there other logs I could/should check? – stormdrain Sep 11 '13 at 17:34