I have a remote Windows 7 server that is accessible only via HTTPS on port 768. The server is using a signed certificate from a CA listed in the local CentOS server.
Whenever I try to access the remote server via cURL using the following command, it errors out as follows:
[usr@serv certs]# curl -3 -v https://1.1.1.1:768/user/login * About to connect() to 1.1.1.1 port 768 (#0) * Trying 1.1.1.1... connected * Connected to 1.1.1.1 (1.1.1.1) port 768 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * NSS error -5961 * Closing connection #0 * SSL connect error curl: (35) SSL connect error
(Note that the IP address has been hidden for security reasons).
I am running the following version of cURL:
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
It's worth noting that this is working on two other remote servers which are both running Windows XP rather than windows 7.
I have tried forcing cURL to use SSLv3 (using the -3 flag and the -SSLv3 flag) with no success.
I have just tested the same CURL command on a Raspberry Pi running Raspbian and have been able to connect successfully. I therefore believe it may be an issue with the version of cURL in use on the CentOS server. The raspberry pi is running the following version:
curl 7.26.0 (arm-unknown-linux-gnueabihf) libcurl/7.26.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25 libssh2/1.4.2 librtmp/2.3 Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp Features: Debug GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
curl with NSS read the Root CA certificates by default from "/etc/pki/tls/certs/ca-bundle.crt" in the PEM format.
* Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt
You can specify another (your) CA certificate (or bundle on the NSS Shared DB) by curl's option --cacert with the PEM file containing the CA certificate(s).
If you don't specify the certificate manually with --cacert option, NSS tries to select the right one from the NSS database (located at /etc/pki/nssdb) automatically. You can specify it's nickname by curl's option --cert, this should be sufficient if the key is embedded in the cert, if not you can specify the PEM file with the certificate key using the --key. If the key is protected by a pass-phrase, you can give it by curl's option --pass so you can import your certificate to the NSS shared DB using the nss-tools (yum install nss-tools)
Adding a certificate (common command line)
certutil -d sql:/etc/pki/nssdb -A -t -n -i
About TRUSTARGS
Specify the trust attributes to modify in an existing certificate or to apply to a certificate when creating it or adding it to a database.
There are three available trust categories for each certificate, expressed in this order: " SSL , email , object signing ". In each category position use zero or more of the following attribute codes:
- p prohibited (explicitly distrusted)
- P Trusted peer
- c Valid CA
- T Trusted CA to issue client certificates (implies c)
- C Trusted CA to issue server certificates (SSL only) (implies c)
- u Certificate can be used for authentication or signing
- w Send warning (use with other attributes to include a warning when the certificate is used in that context)
The attribute codes for the categories are separated by commas, and the entire set of attributes enclosed by quotation marks. For example:
-t "TCu,Cu,Tuw"
Trusting a root CA certificate for issuing SSL server certificates
certutil -d sql:/etc/pki/nssdb -A -t "C,," -n -i
Importing an intermediate CA certificate
certutil -d sql:/etc/pki/nssdb -A -t ",," -n -i
Trusting a self-signed server certificate
certutil -d sql:/etc/pki/nssdb -A -t "P,," -n -i
Adding a personal certificate and private key for SSL client authentication
pk12util -d sql:/etc/pki/nssdb -i PKCS12_file_with_your_cert.p12
Listing all the certificates stored into NSS DB
certutil -d sql:/etc/pki/nssdb -L
Listing details of a certificate
certutil -d sql:/etc/pki/nssdb -L -n
Deleting a certificate
certutil -d sql:/etc/pki/nssdb -D -n
Hope this helps.
I recently ran into the same issue in a CentOS 6 box. It turned out that the server had not been updated for quite some time and the NSS version was too old. Fixed by updating both curl and NSS:
yum update -y nss curl libcurl
What's Happening
It sounds as though you are experiencing a timeout issue when connecting to the Windows 7 server.
Possible Solutions
One possible answer indicates the root cause of error 5961 turned out to be a networking MTU setting issue. It's not clear if you have access to the Windows 7 server or the full components of the environment to identify the exact cause of the timeout that is causing the connection to fail. I would check the MTU of the Windows 7 Server and compare the MTU setting with that of the other servers. If you find that you need to modify the settings you can follow this procedure.
This error is also issued when the ssl protocol is not supported by the server, Try specifying all the variants/protocols in the server.xml file.
This also will happen when ciphers between client and server are not overlapped.
For example server only accept ECHDE cipher but client(some old version curl built with nss) did not have this cipher.
in this case, server will send a TCP RST to the client to terminate the SSL connection attempt when it found that no cipher overlapped (client will include supported cipher in the 'client hello').
