22

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
Euan T
  • 2,041
  • 3
  • 20
  • 28
  • I faced the same issue. I updated openssl, curl, lib-curl and other things. could not solve. Finally i go that there needs to made firewall policy for this port on destination server. Problem solved after opening port between source and destination sever. – Ramgau Aug 29 '15 at 04:23

5 Answers5

25

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.

vzamanillo
  • 9,905
  • 1
  • 36
  • 56
11

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
Pang
  • 9,564
  • 146
  • 81
  • 122
qingbo
  • 2,130
  • 16
  • 19
  • 1
    I updated curl libcurl and ca-certificates, but forgot nss. That was the ticket for me, thanks! – n0nag0n Jun 01 '18 at 16:33
  • 1
    Yep. That fixed it for me. Thanks. – Terje Dahl Jun 25 '18 at 20:22
  • `2.6.32-573.12.1.el6.centos.plus.x86_64`, fixed the issue. – Gang Aug 22 '18 at 03:39
  • For me it didn't work as I had a third party repo requiring TLS 1.2. In that case I had to exclude that repo temporarily using the yum option `--disablerepo`. So for example: `yum --disablerepo= update -y nss curl libcurl` – SiXoS Feb 04 '19 at 14:49
1

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.

Community
  • 1
  • 1
Tommie C.
  • 12,895
  • 5
  • 82
  • 100
  • Hi Tommie C. I have limited access to the Windows 7 server. I have spun up a different virtual machine with the host running OpenSuse rather than CentOS (OpenSuse seems to come with cURL compiled with OpenSSL rather than NSS). This new VM has no problem connecting to either the Windows XP or WIndows 7 servers. I therefore believe that NSS may be to blame in some way (or at least the version distributed with CentOS 6.5). – Euan T Mar 03 '14 at 10:07
1

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.

SomethingDark
  • 13,229
  • 5
  • 50
  • 55
user4737628
  • 11
  • 1
0

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').

hgfeaon
  • 71
  • 1
  • 2