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.
Related
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.
For testing purposes I am trying to setup an https server, only for communication within a local network. TLS two way authentication and also OCSP stapling has to be used (due to the requirements of the client).
For nginx I have a basic setup:
listen 44300 ssl default_server;
listen [::]:44300 ssl default_server;
ssl on;
ssl_certificate /home/user/work/Telematics2/server/certificate.crt;
ssl_certificate_key /home/user/work/Telematics2/server/certKey.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_verify_client optional_no_ca;
ssl_client_certificate /home/user/work/Telematics2/client/certificate.crt;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /home/user/work/Telematics2/server/concat.crt;
For testing I created server and client keys on my local machine with following commands:
openssl genrsa -out rootCA.key 1024
openssl req -new -x509 -days 3650 -key rootCA.key -out rootCA.crt -config validation.cnf -subj /C=DE/ST=BW/L=Earth/O=CompanyName/OU=IT/CN=X.X.X.X/emailAddress=email#example.com
openssl genrsa -out certKey.key 1024
openssl req -new -x509 -days 3650 -key certKey.key -out certificate.crt -config validation.cnf -subj /C=DE/ST=BW/L=Earth/O=CompanyName/OU=IT/CN=X.X.X.X/emailAddress=email#example.com
openssl x509 -x509toreq -in certificate.crt -out CSR.csr -signkey certKey.key
openssl ca -batch -startdate 150813080000Z -enddate 250813090000Z -keyfile rootCA.key -cert rootCA.crt -policy policy_anything -config validation.cnf -notext -out certificate.crt -infiles CSR.csr
openssl req -new -nodes -out ocspSigning.csr -keyout ocspSigning.key -subj /C=DE/ST=BW/L=Earth/O=CompanyName/OU=IT/CN=X.X.X.X/emailAddress=email#example.com
yes | openssl ca -keyfile rootCA.key -cert rootCA.crt -in ocspSigning.csr -out ocspSigning.crt -config validation.cnf
The config contains following extra lines:
[ usr_cert ]
authorityInfoAccess = OCSP;URI:http://X.X.X.X:8080
[ v3_OCSP ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = OCSPSigning
I then started an OCSP server with openssl:
openssl ocsp -index demoCA/index.txt -port 8080 -rsigner ocspSigning.crt -rkey ocspSigning.key -CA rootCA.crt -text
and tried to access a simple html file on the server:
curl -v -L -k --cert /home/user/work/Telematics2/client/certificate.crt --key /home/user/work/Telematics2/client/certKey.key https://X.X.X.X:44300/index.html --cert-status --cacert /home/user/work/Telematics2/server/rootCA.crt
This gives me the following output:
* Trying X.X.X.X...
* TCP_NODELAY set
* Connected to X.X.X.X (X.X.X.X) port 44300 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /home/user/work/Telematics2/server/rootCA.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 Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Request CERT (13):
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Client hello (1):
* TLSv1.3 (OUT), TLS Unknown, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS Unknown, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, CERT verify (15):
* TLSv1.3 (OUT), TLS Unknown, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: C=DE; ST=BW; L=Earth; O=CompanyName; OU=IT; CN=X.X.X.X; emailAddress=email#example.com
* start date: Aug 13 08:00:00 2015 GMT
* expire date: Aug 13 09:00:00 2025 GMT
* issuer: C=DE; ST=BW; L=Earth; O=CompanyName; OU=IT; CN=X.X.X.X; emailAddress=email#example.com
* SSL certificate verify ok.
* No OCSP response received
* stopped the pause stream!
* Closing connection 0
* TLSv1.3 (OUT), TLS Unknown, Unknown (21):
* TLSv1.3 (OUT), TLS alert, Client hello (1):
curl: (91) No OCSP response received
and the nginx error.log says:
2020/02/19 14:53:04 [error] 29340#29340: OCSP_basic_verify() failed (SSL: error:2706A067:OCSP routines:ocsp_check_delegated:missing ocspsigning usage error:27069070:OCSP routines:OCSP_basic_verify:root ca not trusted) while requesting certificate status, responder: X.X.X.X, peer: X.X.X.X:8080, certificate: "/home/user/work/Telematics2/server/certificate.crt"
But the above started ocsp server actually prints:
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = DE, ST = BW, O = CompanyName, OU = IT, CN = X.X.X.X, emailAddress = email#example.com
Produced At: Feb 19 14:17:18 2020 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 3CFD1A620E876EB93992CA04B1903C354AC6C614
Issuer Key Hash: 1E01DD83D567E3E111FD89E26B2636964C26AFDC
Serial Number: 01
Cert Status: good
This Update: Feb 19 14:17:18 2020 GMT
I am not really an expert on this topic so I don't really know what to do next. I feel like the issue might be with the certificates, because it is the part I am most unsure about. I don't really need the security provided by OCSP but the client requires this step for a successful authentication, but it would be fine if I can just trust any CA if this is somehow possible.
Probably because your ocspserver is running on localhost. Assuming you server from which youre trying to access the https url is not in the same machine Not sure.Trying to do a similar thing. Please let me know if i am wrong. or if you have a solution
I'm using jetty v9.4.9. I want to authenticate the requests using client certificate. I have configured keystore file in 'jetty-base\etc'. I'm using self-signed certificates in both server and client.
I have a server certificate and root certificate. I have used OpenSSL to generate keystore file.
From https://www.eclipse.org/jetty/documentation/9.4.x/configuring-ssl.html,
Generating pkcs12 file:
$ cat example.crt intermediate.crt [intermediate2.crt] ... rootCA.crt > cert-chain.txt
$ openssl pkcs12 -export -inkey example.key -in cert-chain.txt -out example.pkcs12
Loading keystore file:
$ keytool -importkeystore -srckeystore jetty.pkcs12 -srcstoretype PKCS12 -destkeystore keystore
Using above methods, I have generatd 'new_keystore' file. I have configured the newely generated keystore file in jetty-base\start.d\ssl.ini as
jetty.sslContext.keyStorePath=etc\new_keystore
jetty.sslContext.trustStorePath=etc\new_keystore
Now I'm sending request using cURL in Windows
Request:
curl -v --cacert root.crt --key client.key --cert client.crt https://localhost:8443
This results in unknown certificate error
CApath: none
* 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, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS handshake, CERT verify (15):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS alert, certificate unknown (558):
* error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown
* Closing connection 0
curl: (35) error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown
In jetty, how to identify the reason behind the unknown certificate error? Can it be configured to displayed on log file? How to debug and fix it?
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
I have setup docker in non-ssl mode by editing /etc/default/docker and setting DOCKER_OPTS="-H=0.0.0.0:2375".
Now when I start docker and connect to it using curl curl -sv http://10.24.16.17:2375/v1.22/containers/json, I get some response.
When I secure the docker using certificates (ca.pem, server-key.pem, server-cert.pem) and editing /etc/default/docker
DOCKER_OPTS="--tlsverify --tlscacert=/home/ubuntu/certs/ca.pem --tlscert=/home/ubuntu/certs/server-cert.pem --tlskey=/home/ubuntu/certs/server-key.pem -H=0.0.0.0:2376"
I am not able to connect service using curl:
curl -sv https://10.24.16.17:2376/v1.22/containers/json
I get the following output:
* Hostname was NOT found in DNS cache
* Trying 10.24.16.17...
* Connected to 10.24.16.17 (10.24.16.17) port 2376 (#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 alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
I am able to run docker ps -a command using CLI though, only cURL to hit the API endpoint does not work.
When I try curl -sv --cacert /home/ubuntu/certs/ca.pem https://10.24.16.17:2376/v1.22/containers/json, I get:
* Hostname was NOT found in DNS cache
* Trying 10.24.16.17...
* Connected to 10.24.16.17 (10.24.16.17) port 2376 (#0)
* successfully set certificate verify locations:
* CAfile: /home/ubuntu/certs/ca.pem
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 key exchange (12):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS alert, Server hello (2):
* error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
* Closing connection 0
I read somewhere that the above error may be due to corrupt ca.pem file, but that may not be the case as the command docker ps -a was able to connect to docker host using the same ca.pem file.