cURL SSL connect error 35 with NSS error -5961
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.
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
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 <TRUSTARGS> -n <certificate nickname> -i <certificate filename>
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 <certificate nickname> -i <certificate filename>
Importing an intermediate CA certificate
certutil -d sql:/etc/pki/nssdb -A -t ",," -n <certificate nickname> -i <certificate filename>
Trusting a self-signed server certificate
certutil -d sql:/etc/pki/nssdb -A -t "P,," -n <certificate nickname> -i <certificate filename>
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 <certificate nickname>
Deleting a certificate
certutil -d sql:/etc/pki/nssdb -D -n <certificate nickname>
Hope this helps.