I am trying one curl command on different servers. One is working and the other one is reporting "nss error -5938".
Server1:
OS:
Linux 4.1.12-61.1.10.el6uek.x86_64 x86_64 x86_64 x86_64 GNU/Linux
CURL -V:
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1
Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2 Protocols: tftp ftp
telnet dict ldap ldaps http file https ftps scp sftp Features:
GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
Command Running Status:Error
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
HTTP/1.0 200 Connection established
HTTP/1.0 200 Connection established
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
Server2:
OS:
Linux 412c25016c7b 4.1.12-37.5.1.el7uek.x86_64 #2 SMP Thu Jun 9
16:01:20 PDT 2016 x86_64 x86_64 x86_64 GNU/Linux
CURL -V
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.2.3
Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2 Protocols: tftp ftp
telnet dict ldap ldaps http file https ftps scp sftp Features:
GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
Command Running Status: Without Error
Could you please help give some suggestions on how to make server1 work with curl command? Thank you so much!
Thanks all for the help!
Finally I found the solution that using the command like
curl --tlsv1.2
Related
Is there any command line API change in Debian 9 curl?
Recently I started to use Debian 9 (9.4, from Debian 8.x) and a script involving curl stopped working. I connect to internet through a squid proxy on localhost connected to a parent proxy.
My environment variables are configured like this
root#server:~# printenv | grep -i proxy
HTTP_PROXY=http://127.0.0.1:3128
FTP_PROXY=http://127.0.0.1:3128
https_proxy=https://127.0.0.1:3128
http_proxy=http://127.0.0.1:3128
HTTPS_PROXY=https://127.0.0.1:3128
ftp_proxy=http://127.0.0.1:3128
When I use wget, it works:
root#server:~# wget https://www.google.com.cu
--2018-03-14 09:08:53-- https://www.google.com.cu/
Connecting to 127.0.0.1:3128... connected.
Proxy request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html’
index.html [ <=> ] 11.12K --.-KB/s in 0.001s
2018-03-14 09:08:54 (14.9 MB/s) - ‘index.html’ saved [11389]
when I use curl, this is what I get
root#server:~# curl -v https://www.google.com.cu
* Rebuilt URL to: https://www.google.com.cu/
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to (nil) (127.0.0.1) port 3128 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Curl_http_done: called premature == 0
* Closing connection 0
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
I know these two commands are not equivalent, this is just to illustrate the HTTPS transfer problem.
I need to use curl because the script uses a web API, so it needs to use POST instead of GET request, and to set some headers and data to the POST request. (api.dropboxapi.com is the target site)
This all used to work on Debian 8 without a hitch, and besides wget WORKS, only curl is failing with the debian version change. All the other HTTPS clients seem unaffected (FF, Chrome, Edge, wget all seems to work as always)
Is there any workaround, fix, command line option change or whatever for making debian 9's version of curl work?
There must be a way, I can't conceive curl can't make a HTTPS connection to google. There must be a command line or something that allows the connection.
Output of "curl -V"
root#server:~# curl -V
curl 7.52.1 (x86_64-pc-linux-gnu) libcurl/7.52.1 OpenSSL/1.0.2l zlib/1.2.8 libidn2/0.16 libpsl/0.17.0 (+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
Output of "curl --insecure" as suggested
root#server:~# curl --insecure -v https://www.google.com.cu
* Rebuilt URL to: https://www.google.com.cu/
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to (nil) (127.0.0.1) port 3128 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Curl_http_done: called premature == 0
* Closing connection 0
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
"curl -v https://www.google.com.cu --sslv2" output
root#server:/etc/squid# curl -v https://www.google.com.cu --sslv2
* Rebuilt URL to: https://www.google.com.cu/
* Trying 192.168.4.65...
* TCP_NODELAY set
* Connected to (nil) (192.168.4.65) port 81 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Curl_http_done: called premature == 0
* Closing connection 0
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
Many, many thanks to Michael Hampton. It turns out the problem was in the proxy configuration. It should say
https_proxy=http://127.0.0.1:3128
HTTPS_PROXY=http://127.0.0.1:3128
So curl was trying to connect to squid using TLS and failing of course.
Original answer in https://serverfault.com/questions/901626/debian-version-change-affecting-scripts-using-curl-and-https
OS: CentOS release 6.9 (Final)
CURL: curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Hello,
I have a host which I am trying to run a curl command from, for testing only
curl https://api.twitter.com/ -v
Returns the below
* About to connect() to api.twitter.com port 443 (#0)
* Trying 104.244.42.2... connected
* Connected to api.twitter.com (104.244.42.2) port 443 (#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
After some lengthy reading I have come to the conclusion this is possibly a SLL issue due to either my OS version or CURL version, or both!
First question would be is that right? Are there indeed known issues with this configuration?
Second, can I build from source a working combination? I am unable to update my OS due to legacy dependencies
Try with specific ssl/tls or cipher suits for example: curl --tlsv1.2 https://api.twitter.com/
Since you say this is for testing only, you could try -k to connect insecurely:
curl -k https://api.twitter.com/
Or, if you think it’s an outdated SSL cert bundle you could download a newer certificate and trust store from the internet and try that by using the --cert and --cacert options
Rebuild a fresh server running centos 7
Worked straight away no issues!
In Ubuntu 14.04 when I try to use curl I get the below messages:
curl www.google.com
curl: /usr/local/lib/libldap_r-2.4.so.2: no version information available (required by /usr/lib/x86_64-linux-gnu/libcurl.so.4)
curl: /usr/local/lib/liblber-2.4.so.2: no version information available (required by /usr/lib/x86_64-linux-gnu/libcurl.so.4)
curl version:
curl --version
curl: /usr/local/lib/libldap_r-2.4.so.2: no version information available (required by /usr/lib/x86_64-linux-gnu/libcurl.so.4)
curl: /usr/local/lib/liblber-2.4.so.2: no version information available (required by /usr/lib/x86_64-linux-gnu/libcurl.so.4)
curl 7.35.0 (x86_64-pc-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
any one else has experienced this issue?
This error means libcurl was compiled with a version of libldap_r other than what you have in /usr/local/lib.
As a solution you can create a symbolic links for missing files:
$ sudo ln -fs /usr/lib/liblber-2.4.so.2 /usr/local/lib/
$ sudo ln -fs /usr/lib/libldap_r-2.4.so.2 /usr/local/lib/
I've looked at several similar questions here, but none of them have helped me. I want to connect to a web service that uses single-sign-on via an RSA SecurID keyfob. I start by trying to load any cookies provided by the initial GET request. Here's my command:
curl -A "Mozilla/5.0" -L -b cookies.txt -c cookies.txt -v -X GET \
https://sso.example.com/sso/login.htm
I get this in response:
* About to connect() to sso.example.com port 443 (#0)
* Trying 23.12.245.199... connected
* Connected to sso.example.com (23.12.245.199) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs/
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to sso.example.com:443
* Closing connection #0
curl: (35) Unknown SSL protocol error in connection to sso.example.com:443
Here's what I'm using:
# curl --version
curl 7.19.7 (x86_64-suse-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8j zlib/1.2.7 libidn/1.10
Protocols: tftp ftp telnet dict ldap http file https ftps
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
# more /etc/*-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 3
# uname -r
3.0.101-0.21-default
Any ideas?
This is OpenSSL in your client that has a problem to understand what the server is saying and it errors out because of that.
You can sometimes work around these kinds of issues by forcing curl to speak SSLv3 (-3), TLS1.0 (-1) or even SSLv2 (-2)
... it is also conceivable that your severely outdated versions of curl and OpenSSL simply have a bug or two that cause this and that you can fix this problem by upgrading to modern versions (and then also fix the numerous security problems your versions contain).
I've tried a variety of things to upload a file via SFTP using the curl package from Hackage, so far all of them produce the following error:
* About to connect() to [redacted] port 22 (#0)
* Trying [redacted]... * connected
* Connected to [redacted] ([redacted]) port 22 (#0)
* Failure establishing ssh session
* Closing connection #0
* Failed initialization
ERROR: CurlFailedInit
I'm setting the following options in Haskell:
[…]
Curl.setopt curlLib (Curl.CurlFailOnError True)
Curl.setDefaultSSLOpts curlLib url -- not necessary for sftp:// protocol, but shouldn't be a problem
Curl.setopt curlLib (Curl.CurlURL url)
Curl.setopt curlLib (Curl.CurlSSLVerifyHost 0)
Curl.setopt curlLib (Curl.CurlSSLVerifyPeer False)
Curl.setopt curlLib (Curl.CurlSSHAuthTypes [Curl.SSHAuthAny])
Curl.setopt curlLib (Curl.CurlUserPwd "user:password")
Curl.setopt curlLib (Curl.CurlUpload True)
[…]
I have verified that the URL, username, and password are correct. Additionally, I've also tried using the SSHAuthPassword auth type option, and setting the username and password with CurlUserName and CurlUserPassword.
Executing curl from the command line
$ curl -vvv --upload-file test.txt --user 'user:password' "sftp://[redacted]/~/test.txt"
Succeeds
* About to connect() to [redacted] port 22 (#0)
* Trying [redacted]... connected
* Connected to [redacted] ([redacted]) port 22 (#0)
* Failed to read known hosts from [redacted]
* SSH host check: 0, key: [redacted]
* SSH authentication methods available: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
* Using ssh public key file [redacted]
* Using ssh private key file [redacted]
* SSH public key authentication failed: Unable to open public key file
* Initialized password authentication
* Authentication complete
[…]
* Closing connection #0
The versions of the OS and libraries are as follows:
$ uname -r
2.6.32-131.12.1.el6.x86_64
$ cat /etc/redhat-release
Red Hat Enterprise Linux Workstation release 6.1 (Santiago)
$ cabal info curl
[…]
Latest version installed: 1.3.8
[…]
$ curl --version
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.3.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
I don't control and have no influence over the server I'm connecting to, so switching to ssh-agent is not an option.