4

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 127.0.0.1 port 8215 (#0) * Trying 127.0.0.1... connected * Connected to 127.0.0.1 (127.0.0.1) 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

Improve this question
7
  • 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... Commented May 1, 2018 at 1:04
  • I should have tried this first. Let me get them to try. They're a bit slow to get back Commented May 1, 2018 at 1:19
  • Hmm. Still same error: NSS error -5938 Commented May 1, 2018 at 5:04
  • May be related: unix.stackexchange.com/a/310696/126755 Commented May 1, 2018 at 6:06
  • 1
    Yeahp jumping through a lot of hoops. Their reasoning is that it's currently working for them (except to our machine). And therefore there could be a big impact if they do upgrade and potentially break it for everyone else. Commented May 1, 2018 at 23:17

0

Reset to default

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.