I've had an issue where connecting with curl to https://server failed with:
curl: (60) server certificate verification failed.
but initiating a connection with openssl s_client worked fine.
The problem was somehow related to the server side, but I do not understand what could cause curl to reject the connection while openssl s_client was ok. OpenSSL 1.0.2s-fips
Help ?
Bummer. it was not the chain but the actual cert that had expired.
Somehow openssl s_client did not catch that. Nor did I.
(openssl s_client -showcerts did show chain certs but not server cert)
Related
I can use the openssl s_server command to accept TLS sessions from clients, and to require mutual TLS - i.e. request client certificate - using a command such as: -
openssl s_server -accept 4433 -cert myCert.crt -key -myKey.pem -Verify 2 -CAfile myCA.crt
When I connect from a client, I can see from tracing that s_client sends a certificate request, correctly stipulating the certificate contained within myCA.crt. However it seems that s_server will accept any client certificate, regardless of whether it was signed by myCA.crt or not - i.e. it doesn't care which client cert is sent.
Does anyone know if this is expected behaviour, or am I doing something wrong?
openssl s_server and s_client by default verify the peers certificate and show the verification status but don't stop on errors. If this is necessary use the -verify_return_error option.
I have an issue with the server rejecting the client certificate in the handshake if I issue openssl call with just the cert (with chain) and private key.
This issue goes away if I also set the cafile param and point it to the same file as the cert.
It seems as if openssl cannot construct the chain without the cafile input even if the information is already in the cert input. I wonder if you guys had experience with this. I just find it a bit odd.
To summarize, this works:
sudo openssl s_client -connect <ip>:<port> -cert cert_with_chain.pem -key privkey.pem -CAfile cert_with_chain.pem
This doesn't work (Server reject with "null cert chain"):
sudo openssl s_client -connect <ip>:<port> -cert cert_with_chain.pem -key privkey.pem
Open SSL version:
OpenSSL 1.0.2k-fips 26 Jan 2017
The problem is not that "openssl cannot construct the chain without the cafile" but that it wasn't the intention in the first place to do so. The intended behavior is well documented in man s_client:
-cert certname The certificate to use, if one is requested by the server.
-CAfile file A file containing trusted certificates to use during server authentication and to use when attempting to build the client
certificate chain.
I am not able to verify webmaster account of one of my client.
Google is saying "Verification failed - The connection to your server timed out."
When I tried to do wget the URL, I found below error. Can someone please help me resolving this?
[pdurgapal]$ wget https://atlanticdiscountstore.com
--2017-06-28 11:48:48-- https://atlanticdiscountstore.com
Resolving atlanticdiscountstore.com... 188.241.58.18
Connecting to atlanticdiscountstore.com|188.241.58.18|:443... connected.
ERROR: cannot verify atlanticdiscountstore.com’s certificate, issued by “/CN=baldwincountyunited.com”:
Self-signed certificate encountered.
ERROR: certificate common name “baldwincountyunited.com” doesn’t match requested host name “atlanticdiscountstore.com”.
To connect to atlanticdiscountstore.com insecurely, use ‘--no-check-certificate’.
[pdurgapal]$
You must be using a very old version of wget which has no support for SNI. When using a proper client with support for SNI the certificate can be verified. Apart from that the server is terrible slow in responding after the TLS handshake is successfully done, but this is not the issue you asked about.
To demonstrate the problem an access to the site without SNI:
$ openssl s_client -connect atlanticdiscountstore.com:443 |\
openssl x509 -text
...
Subject: CN=baldwincountyunited.com
...
X509v3 Subject Alternative Name:
DNS:baldwincountyunited.com, DNS:mail.baldwincountyunited.com, DNS:www.baldwincountyunited.com
and with SNI:
$ openssl s_client -connect atlanticdiscountstore.com:443 \
-servername atlanticdiscountstore.com |\
openssl x509 -text
...
Subject: ... CN=*.atlanticdiscountstore.com
...
X509v3 Subject Alternative Name:
DNS:*.atlanticdiscountstore.com, DNS:atlanticdiscountstore.com
I'am trying to confirm, that our server will be ready for the SSL Certificate Change.
According to Microsite migration on www.sandbox.paypal.com is complete.
Running:
openssl s_client -CApath /etc/ssl/certs/ -connect www.sandbox.paypal.com:443
returned 0 (ok)
Does this test definitively confirm that our server is ready?
The openssl connection return code(0) will be affirmative for this cert check, but there’s a slightly change you may want to make for the call.
Run with the following line and try the conn one more time, (I’ve added the –showcerts parameter so that the cert chain will be printed out and you may easily identify Verisign G5 root cert in there)
openssl s_client -connect api-3t.sandbox.paypal.com:443 -showcerts -CApath /etc/ssl/certs/
So, I've key and cert file which are using without problem with CURL.
curl -k --key key --cert cert --url myurl
No problem with it. Buf if test connection with openssl s_client i've error 19 self-signed cert in chain.
openssl s_client -key key -cert cert -connect myurl:443
So, seems openssl must have alternative option '-k' of curl which means insecure, allow connections to SSL sites without certs (H). Somebody knows it?
curl will simply not make the connection at all without -k if the certificate isn't trusted.
In contrast, openssl s_client will make the connection anyway, but will display a warning if the certificate isn't trusted. (You would have to specify a list of trusted CA certificates using -CApath or -CAfile to get rid of that warning.)