A B2B partner needs to make a callback from a Redhat machine to an API method on our web server (Centos7).

We added their IP address to our software firewall but nothing was going through.

They reported that they received an SSL connect error with the error message being: NSS error -5938

They sent us the response from their curl request:

# curl --verbose "https://web1.company.com/callback?param1=val1&param2=val2"
* About to connect() to proxy port 8215 (#0)
*   Trying connected
* Connected to ( port 8215 (#0)
* Establish HTTP proxy tunnel to web1.company.com:443
> CONNECT web1.company.com:443 HTTP/1.1
> Host: web1.company.com:443
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.21 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Proxy-Connection: Keep-Alive
< HTTP/1.1 200 Connection established
< Proxy-Connection: keep-alive
* Proxy replied OK to CONNECT request
* 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
curl: (35) SSL connect error
* NSS error -5938
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error
[1]+  Exit 35

Error ref: https://dxr.mozilla.org/comm-central/source/mozilla/nsprpub/pr/include/prerr.h?q=PR_END_OF_FILE_ERROR

I searched for the keywords curl nss error 5938 on the web (including stackexchange) and it mostly resulted in users recommending that curl be updated or recompiled.

The B2B partner expressed that updating or recompiling is not an option, at least in the near future.

Things that I've tried

I've tried curl from two other machines (with openssl not nss):

  • They were both successful

I've asked the B2B partner to try to force curl to use different SSL/TLS versions:

curl --tlsv1
curl --tlsv1.0
curl --tlsv1.1
curl --tlsv1.2
curl --sslv2
curl --sslv3

They all resulted in the same error.

I've also investigated the possibility of a cipher mismatch (considering the client had nss and the server had openssl), but there were some clear overlaps.

In my desperation, I've also asked them to try an inccorect cipher:

curl --ciphers TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 

when I meant ecdhe_rsa_aes_128_gcm_sha_256, but it resulted in the following error:

== Info: Unknown cipher in list: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
== Info: NSS error -5978
== Info: Closing connection #0
curl: (59) Unknown cipher in list: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Using a correct cipher ecdhe_rsa_aes_128_gcm_sha_256 resulted in the same 5938 error.

Note: I don't know if going through the proxy is a significant issue or not. Just stating the configuration as I currently have it.

Does anybody have any suggestions on what I can try next? Thanks

  • Are they able to get the information if they use curl with -k to complete an insecure connection? Normally you'd want to remedy the version or cert issue, but if they don't want to update curl maybe you can just bypass the SSL check... – saleetzo May 1 '18 at 1:04
  • I should have tried this first. Let me get them to try. They're a bit slow to get back – denormalizer May 1 '18 at 1:19
  • Hmm. Still same error: NSS error -5938 – denormalizer May 1 '18 at 5:04
  • May be related: unix.stackexchange.com/a/310696/126755 – LinuxSecurityFreak May 1 '18 at 6:06
  • Hi Vlastimil, most solutions out there regarding the 5938 error suggests upgrading curl and/or nss. At the moment, this isn't an option, at least on our B2B partner's end. – denormalizer May 1 '18 at 7:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.