I'm testing certificate revocation with a test server. I'm trying to use openssl s_client with crl_check parameter for testing the revocation. I have appended ca certs to a chain file I give in CAfile parameter.
With the command:
openssl s_client -connect <host>:<port> -crl_check -cert cert.pem \
-key key.pem -CAfile ca_chain.pem -state -verify_return_error debug
I get a response:
Verify return code: 3 (unable to get certificate CRL)
Which is natural because I don't give the CRL.
How should I give the CRL (where the server cert is revoked) to the openssl s_client to get certificate revocation checked in negotiation?
With 1.02 you should be able to do this. From the changelog:
*) New options -CRL and -CRLform for s_client and s_server for CRLs.
[Steve Henson]
In versions before that the behavior is undocumented: You have to include the CRL together with the certificate in the same file if you are using a single file with -CAfile. If you are using a directory with -CApath instead it gets even harder.
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 am working with a certificate chain with 3 certificates :
ca.crt : Root CA certificate
intermediate.crt : intermediate CA certificate (signed by ca.crt)
cert.crt : the final certificate
I first try to verify with:
openssl verify -CAfile ca.crt -untrusted intermediate.crt cert.crt
I get as result cert.crt: OK
So it's all fine.
But if I create a certificate chain with cat cert.crt intermediate.crt > cert.chain
And then I verify with openssl verify -CAfile ca.crt cert.chain
The result is error 20 at 0 depth lookup:unable to get local issuer certificate
And the cert.chain file is also rejected by a server for the exact same reason.
I don't understand where is the problem.
I first try to verify with: openssl verify -CAfile ca.crt -untrusted intermediate.crt cert.crt
This will take the first certificate out of cert.crt and try to build the trust chain using the given untrusted CA certificates in intermediate.crt up to some root CA certificate in ca.crt.
And then I verify with openssl verify -CAfile ca.crt cert.chain
This will also take the first certificate out of cert.chain. It will ignore remaining certificates in this file. It will then try to build the trust chain to some root CA certificate in ca.crt without using any intermediate CA certificates since none are given. It will thus fail.
And the cert.chain file is also rejected by a server for the exact same reason.
It is unknown what exactly happens here. If it is "rejected by a server" then you likely talk about validating a client certificate by the server. It might simply be that the client application does not send the whole chain to the server but only the first certificate from the file. None is known about this client application though, so this is only speculation.
Thanks to all. Yes, the correct way to verify a chain is with using the "untrusted" parameter of openssl verify to specify the intermediate certificate.
The connection to server was tried with openssl s_client and specifying the certificate chain in the "cert" parameter but it fails. Using a recent openssl version (1.1.0 or newer), it is now possible to add the "cert_chain" parameter to specify the intermediate certificate to use.
Hello you error just related in the fact that you chain is not build correctly.
Normally your verify with untrusted shall not work, that why you're confusing.The correct sequence is below. I invite you to regenerate and recreate your chain.
openssl verify -CAfile ca.crt -untrusted cert.crt intermediate
This will start at the end, (Root > intermediate > cert)
So that, your chain shall be build as following :
cat intermediate.crt cert.crt > chain.crt
Then it shall work.
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 recently had a problem where a server certificate was not set to expire, but the intermediate cert in its chain had expired, thus preventing my WebLogic server from starting. I am familiar with using openssl s_client -connect server:443 -showcerts | openssl x509 -enddate to get the server cert expiration date, but is it possible to do the same for the other certs in the chain? Thanks.
openssl s_client -connect server:443 -showcerts returns all certificates in chain except for root (which is correct). Just parse these certificates out of the output and run openssl x509 -enddate on each of them.
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.)