Unknown SSL protocol error in connection to using curl on RedHat - ssl

Please see the output below. I'm just trying to access the website using curl 7.52.1 on RedHat Enterprise Server 6.9.
[root#fti ~]# curl -v https://testweb.dms.com
* Rebuilt URL to: https://testweb.dms.com/
* Trying 12.121.156.219...
* TCP_NODELAY set
* Connected to testweb.dms.com (12.121.156.219) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: /root/anaconda3/ssl/cacert.pem
CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to testweb.dms.com:443
* Curl_http_done: called premature == 1
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to testweb.dms.com:443
openssl works fine.
[root#fti ~]# openssl s_client -connect testweb.dms.com:443
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 307 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1508957433
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
curl -V O/P
curl 7.52.1 (x86_64-pc-linux-gnu) libcurl/7.52.1 OpenSSL/1.0.2l zlib/1.2.8
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets HTTPS-proxy
As none-root user
[denimi#fti ~]$ curl -v https://testweb.dms.com
* About to connect() to testweb.dms.com 443 (#0)
* Trying 12.121.156.219... connected
* Connected to testweb.dms.com (12.121.156.219) 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
How can I solve this?

Try connecting using specific protocol or cipher suits. Seems supplied protocol by curl is not accepted by server.
try this:
curl --tlsv1.2 https://testweb.dms.com

Related

SSL cert schannel: disabled automatic use of client certificate with VPN

I read the lot of blogs about the issue but none of the workaround /solutions worked for me.
I am using the curl command like below
curl -v https://golang.org/dl/?mode=json
* Trying 142.250.80.113:443...
* Connected to golang.org (142.250.80.113) port 443 (#0)
* schannel: disabled automatic use of client certificate
* ALPN: offers http/1.1
* schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.
* Closing connection 0
curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.
I changed the setting in gitbash (windows) to use openssl using the below command
git config --global http.sslBackend "openssl"
I am getting the below error after changing openssl
$ curl -v https://golang.org/dl/?mode=json
* Trying 172.253.62.141:443...
* Connected to golang.org (172.253.62.141) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
* CApath: C:\Users\AL25229
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self signed certificate in certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
I have the CA cert/pem file which my organization provides. I am getting all those error messages when I connect with VPN. Connecting VPN is mandatory. By disabling the VPN, it works fine.

gitlab SSL_ERROR_SYSCALL

I had a running gitlab on an online server with ssl for several years now. Due to a server problem, the provider restarted the machine. Since then, I cannot connect to my gitlab anymore. Does anybody have an idea, how to solve the problem?
Thanks.
root#git:~# curl -v -H -GET "https://gitlabAdress.com"
Rebuilt URL to: https://gitlabAdress.com/
Trying xxx.xxx.xxx.xxx...
TCP_NODELAY set
Connected to gitlabAdress.com (xxx.xxx.xxx.xxx) port 443 (#0)
ALPN, offering h2
ALPN, offering http/1.1
successfully set certificate verify locations:
CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs
TLSv1.3 (OUT), TLS handshake, Client hello (1):
OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to gitlabAdress.com:443
stopped the pause stream!
Closing connection 0 curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to gitlabAdress.com:443

GET request ssl_choose_client_version:unsupported protocol

I have a problem dealing with an upgrade of an application doing GET request to a remote server.
First thing first : a functional example of a GET done by the old version, and as expected it works
curl -k -vvvvv https://mywebsite.com/mywonderfulwebsite/mypage.php
* Trying 192.168.0.70...
* TCP_NODELAY set
* Connected to mywebsite.com (192.168.0.70) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.0 (IN), TLS handshake, Certificate (11):
* TLSv1.0 (IN), TLS handshake, Server finished (14):
* TLSv1.0 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.0 (OUT), TLS change cipher, Client hello (1):
* TLSv1.0 (OUT), TLS handshake, Finished (20):
* TLSv1.0 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.0 / AES128-SHA
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: CN=MYWEBSITE.COM
* start date: Mar 24 10:20:51 2020 GMT
* expire date: Mar 24 00:00:00 2021 GMT
* issuer: CN=MYWEBSITE.COM
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET /mywonderfulwebsite/mypage.php HTTP/1.1
> Host: mywebsite.com
> User-Agent: curl/7.58.0
> Accept: */*
....... and here the content of the page.....
And now from the new version, it doesn't work
curl -vvvvv https://mywebsite.com/mywonderfulwebsite/mypage.php
* Trying 192.168.0.70:443...
* TCP_NODELAY set
* Connected to mywebsite.com (192.168.0.70) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS alert, protocol version (582):
* error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
* Closing connection 0
curl: (35) error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
So I think it was from the TLS version, no problem let's force it :
curl --tlsv1.0 -vvvvv https://mywebsite.com/mywonderfulwebsite/mypage.php
* Trying 192.168.0.70:443...
* TCP_NODELAY set
* Connected to mywebsite.com (192.168.0.70) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS alert, protocol version (582):
* error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
* Closing connection 0
curl: (35) error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
and it's a fail.
I've tried adding the certificates from the remote website, and I have the same answer.
I've looked at a request using openssl client :
# openssl s_client -connect mywebsite.com:443 -tls1
CONNECTED(00000003)
139820362433856:error:141E70BF:SSL routines:tls_construct_client_hello:no protocols available:../ssl/statem/statem_clnt.c:1112:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 7 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
And now I'm playing with versions and requests and I have no clue where I should check.
Do you know how I could troubleshoot my problem ?
Here is the solution : https://askubuntu.com/questions/1233186/ubuntu-20-04-how-to-set-lower-ssl-security-level
Late openssl package is configured to forbid the usage of TLS < 1.2 however, the first curl request shows a communication using TLS 1.0
So in debian Buster openssl package was too new
dpkg -l | grep openssl
ii openssl 1.1.1d-0+deb10u7
I didn't have to downgrade Openssl
Edit /etc/ssl/openssl.cnf
add in the beginning of the file
openssl_conf = default_conf
And this to the end of the file
[ default_conf ]
ssl_conf = ssl_sect
[ssl_sect]
system_default = system_default_sect
[system_default_sect]
MinProtocol = TLSv1
CipherString = DEFAULT:#SECLEVEL=1
Changing the configuration allow the usage of minimal version of TSL starting TSL 1.0 and more, so from now I can request my legacy partner.

CouchDB not connecting over SSL

I installed CouchDB on an Ubuntu server on EC2 on AWS.
Then, I got an SSL cert with Let's Encrypt.
I edited the local.ini file to enabled SSL and point to the cert files.
I opened port 6984 on the EC2 instance.
I restarted CouchDB.
But, I still can't access it over SSL : (
Any help would rock!
Here's my curl
$ curl https://example.com:6984 -v
* Trying ip.add.re.ss...
* TCP_NODELAY set
* Connected to example.com (ip.add.re.ss) port 6984 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /path/to/certs/ca-certificates.crt
CApath: /path/to/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to example.com:6984
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to example.com:6984
Some help would rock.

curl issue with sites that do not support Secure Renegotiation

Context:
Server: Debian 8.6
curl 7.38.0-4+deb8u11
libcurl3:amd64 7.38.0-4+deb8u11
openssl 1.0.1t-1+deb8u8
CASE 1 (KO)
When I try to connect to a website that DOES NOT SUPPORT Secure renegotiation using curl by command line I am always getting this error:
Unknown SSL protocol error in connection to xxxxx
This the complete output of the command:
curl -v --tlsv1.2 xxxxxxxxx
Rebuilt URL to: xxxxxxxxxx
Hostname was NOT found in DNS cache
Trying XXXXXXX...
Connected to xxxxxxxxxxxx (x.x.x.x) 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 xxxxxxxxxx:443
Closing connection 0
curl: (35) Unknown SSL protocol error in connection to xxxxxx:443
Additional info: the remote website does not support secure renegotiation (I checked with openssl s_client -connect domainname:443).
It looks like curl always tries to perform the SSL handshake using SSLv3 and the server immediately refuse connection not performing any renegotiation.
CASE 2 (OK)
When I try to connect to a website that DOES SUPPORT Secure renegotiation using curl by command line I am able to connect.
This the complete output of the command:
root#web1:~# curl -v --tlsv1.2 XXXXXXX
Rebuilt URL to: XXXXXX
Hostname was NOT found in DNS cache
Trying XXXXXXX...
Connected to XXXXXXXX (XXXXXXX) port 443 (#0)
successfully set certificate verify locations:
CAfile: none
CApath: /etc/ssl/certs
SSLv3, TLS handshake, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS handshake, Server finished (14):
SSLv3, TLS handshake, Client key exchange (16):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSL connection using TLSv1.2 / AES256-GCM-SHA384
Additional info: the remote website supports secure renegotiation(I checked with openssl s_client -connect domainname:443).
It looks like curl always tries to perform the SSL handshake using SSLv3, then the server performs a renegotiation and curl accepts the new ssl protocol version (tlsv1.2).
The root cause looks like curl is ignoring the option --tlsv1.2 or am I wrong?
I already updated packages to latest version (Debian 9 is not an option).
Any suggests?
Thank you