All we need is an easy explanation of the problem, so here it is.
Can someone enlighten me the meaning of “NSS error -5961 (PR_CONNECT_RESET_ERROR)”?
I am trying to connect to bitbucket.org with “https” protocol but got a refuse from the server. Then, I try to use curl on the command line and see this output.
# curl -v https://bitbucket.org * About to connect() to bitbucket.org port 443 (#0) * Trying 188.8.131.52... * Connected to bitbucket.org (184.108.40.206) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * NSS error -5961 (PR_CONNECT_RESET_ERROR) * TCP connection reset by peer * Closing connection 0 curl: (35) TCP connection reset by peer
With openssl, I got this output.
# openssl s_client -connect bitbucket.org:443 -msg CONNECTED(00000003) >>> TLS 1.2 Handshake [length 00f4], ClientHello 01 00 00 f0 03 03 55 59 80 fa 72 25 f4 a5 84 49 ... <I suspended this Hex value> write:errno=104 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 249 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE ---
How to solve :
I know you bored from this bug, So we are here to help you! Take a deep breath and look at the explanation of your problem. We have many solutions to this problem, But we recommend you to use the first method because it is tested & true method that will 100% work for you.
TCP connection reset by peer
This error from NSS is the same error you get with openssl (errno=104: ECONNRESET). This simply means, that the peer or some middlebox in between (firewall) is terminating the connection.
Since the site is reachable from my place I would suggest, that there is a firewall on your site blocking the connection.
The behavior is fairly typical for DPI firewalls in that the initial TCP connection is allowed but once you send the first data (ClientHello from TLS handshake) it will determine if your access is allowed by policy and let it pass or deny it by injecting a TCP RST.
yum update curl
solved the problem for me.
Note: Use and implement method 1 because this method fully tested our system.
Thank you 🙂