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.
Related
I have been given the following files for setting up TLS for a website running on the domain example.com:
example.com.key (containing the private key)
example.com.cer (containing one certificate)
intermediate_example.com.crt (containing two certificates)
example.com.csr (containing one certificate request)
I'm using Traefik to host the site, and I've configured Traefik like so in the dynamic.yml config:
tls:
certificates:
- certFile: "certs/example.com.cer"
keyFile: "certs/example.com.key"
stores:
- default
Doing so resulted in a website I could access via Chrome and Firefox, but whenever trying a request with curl (or any program using its libraries), I get the following error:
➜ ~ curl -v https://test.example.com/
* Trying xxx.xxx.xxx.xxx:443...
* Connected to test.example.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):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
Why is this working in browsers, but not via curl?
I have ensured that the ca-certificates package is installed on the host, and even when I download the most recent CA bundle and use curl --cacert cacert.pem …, it does not work.
What am I missing here?
The reason it does not work is that the intermediate certificate is missing in what Traefik is sending to the client.
The browsers can work around this using the Authority Information Access mechanism, and even macOS does this, fetching the missing information out-of-band, thereby allowing you to access the site normally. Some background is given here.
This is obviously a configuration error on the server. To fix it, at least for Traefik, you can concatenate everything into one .pem file. You don't need to add the CSR file here:
cat example.com.key example.com.cer intermediate_example.com.crt > cert.pem
Then, specify the same file twice in Traefik's config:
tls:
certificates:
- certFile: "certs/cert.pem"
keyFile: "certs/cert.pem"
stores:
- default
This is also mentioned in this discussion on the Traefik community board.
I have created a self signed certificate using keytool. Full command is
keytool -keystore server.p12 -alias server_key -keyalg rsa -ext ku=DigitalSignature,keyEncipherment,dataEncipherment
I added this keystore to my web server as well. There was no there. My question is about how to curl to the server without skipping verification. (I don't want to use -k option). I exported the server certificate using the following command
keytool -export -keystore server.p12 -alias server_key -file server.crt
With curl -v --cacert server.crt https://host:port, the following is the error even though server certificate is provided for curl.
* Rebuilt URL to: https://localhost:5443/
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 5443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /home/innsh/Downloads/cacert.pem
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* stopped the pause stream!
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.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 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.
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
Is there a command to check the TLS version required by a host site? Right now, the only way I know to check is by adjusting the max TLS version of my browser and checking if I can still access the site. However, I suspect there is a more sophisticated way to do this.
You can check using following commands.
For TLS 1.2:
openssl s_client -connect www.google.com:443 -tls1_2
For TLS 1.1:
openssl s_client -connect www.google.com:443 -tls1_1
For TLS 1:
openssl s_client -connect www.google.com:443 -tls1
If you get the certificate chain and the handshake then the TLS version is supported. If you don't see the certificate chain, and something similar to "handshake error" then its not.
From https://maxchadwick.xyz/blog/checking-ssl-tls-version-support-of-remote-host-from-command-line:
nmap ssl-enum-ciphers
Another option for checking SSL / TLS version support is nmap. nmap is not typically installed by default, so you’ll need to manually install it. Once installed you can use the following command to check SSL / TLS version support…
nmap --script ssl-enum-ciphers -p 443 www.google.com
nmap’s ssl-enum-ciphers script will not only check SSL / TLS version support for all versions (TLS 1.0, TLS 1.1, and TLS 1.2) in one go, but will also check cipher support for each version including giving providing a grade.
I like to use curl which can report a TLS version negotiation quite nicely.
For example, this tries to connect with TLS 1.1, which the server negotiates to upgrade to 1.2:
$ curl -Iiv --tlsv1.1 https://example.com
* Trying 192.168.205.11:443...
* TCP_NODELAY set
* Connected to example.com (192.168.205.11) 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.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
[...]
To forbid that the server upgrades the TLS version use the --tls-max option:
$ curl -Iiv --tlsv1.1 --tls-max 1.1 https://example.com
* Trying 192.168.205.11:443...
* TCP_NODELAY set
* Connected to example.com (192.168.205.11) 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 alert, internal error (592):
* error:141E70BF:SSL routines:tls_construct_client_hello:no protocols available
* Closing connection 0
curl: (35) error:141E70BF:SSL routines:tls_construct_client_hello:no protocols available
In this case, the connection fails because the client does not offer any TLS version above 1.1, but the server does not accept any version below 1.2. If used like this, the output is very similar to the openssl_client output.
It seems the most sophisticated way is to check like this for each version:
openssl s_client -connect : -
Nmap has very convenient TLS version and ciphersuite checking NSE script. All in one, multiplatform too: https://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html