Okay, so I have a multi-layered ca system that looks like this:
-ROOT_CA
----intermediate_CA
--------intermediate_CA2
------------client certs...
I have an OCSP responder set up on intermediate_CA2 that is started like so:
$ openssl ocsp -index intermedia_ca_2_index.txt -CA ca_crt_chain.crt -rsigner intermedia_ca_2.crt -rkey intermedia_ca_2.key -port xxxx -text
On the client side, I make an ocsp request like so:
$ openssl ocsp -issuer ca_crt_chain.crt -CAfile ca_crt_chain.crt -cert client.crt -text -host localhost:xxxx -verify_other... -trust_other
Note that client.crt is just the client cert, not the entire chain, though I have tried both ways and neither work. It always returns
Response verify OK
client.crt: unknown
If I change -cert client.crt to -serial 0xXXXXXXXXX (Obviously passing in a valid serial that cooresponds to client.crt) then everything works with:
Response verify OK
0xXXXXXXXXX: good
Oddly enough, if I examine the request in the first example, it is, indeed, sending the correct serial.
I can't for the life of me figure this out. Any ideas?
So the solution is that apparently openssl ocsp doesn't like chain files. So my server call looks like this now:
$ openssl ocsp -index intermedia_ca_2_index.txt -CA intermediate_ca_2.crt -rsigner intermedia_ca_2.crt -rkey intermedia_ca_2.key -port xxxx -text
Note that it would be more preferable to have an entirely seperate key pair for signing, but w/e.
The client connection would then look like so:
$ openssl ocsp -issuer intermediate_ca_2.crt -CApath /path/to/trust/store -cert client.crt -text -url http://localhost:xxxx
This has been fixed OpenSSL 1.1.1a (see this commit).
This can be verified with the commands listed in my issue.
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 trying to set up the simple OpenSSL OCSP responder server, using the following command:
openssl ocsp -index index.txt -port 9999 -rsigner ocsp_cert.pem -rkey ocsp_key.pem -CA root_cert.pem -out ocsp.log -text
and it works and waits for requests as long as index.txt is empty. once I fill it in with any content (specifically following this format: CA Database), the OCSP responder server exits right away.
The content of index.txt is:
V 211118000000Z 3039 unknown /C=IN/ST=TamilNadu/O=cbe/CN=test
Why is the server exiting? is the format correct?
Also - are spaces allowed in the "subject" fields?
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'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.
I have a flask application running using a self signed certificate. I'm able to send in a curl request using:
curl -v -k -H "Content-Type: application/json" -d '{"data":"value1","key":"value2"}' https://<server_ip>:<port>
The verbose logs show that everything went alright.
I wanted to avoid using the -k (--insecure) option and instead specify a .pem file that curl could use. Looking at the curl man page I found that you could do this using the --cert option.
So I created a .pem file using this:
openssl rsa -in server.key -text > private.pem
CURL throws me this error when using the private.pem file:
curl: (58) unable to use client certificate (no key found or wrong pass phrase?)
Any suggestions? - or is this only possible with a properly signed certificate?
Tnx
This is just another version of this question: Using openssl to get the certificate from a server
Or put more bluntly:
Using curl --cert is wrong, it is for client certificates.
First, get the the certs your server is using:
$ echo quit | openssl s_client -showcerts -servername server -connect server:443 > cacert.pem
(-servername is necessary for SNI so that you get the right virtual server's certificate back)
Then make your curl command line use that set to verify the server in subsequent operations:
$ curl --cacert cacert.pem https://server/ [and the rest]
special teaser
Starting with curl 7.88.0 (to be shipped in February 2023), curl can save the certificates itself with the new %{certs} variable for the -w option. Blogged about here.
To make request from https server through curl. I make use of below steps
Step1: Generate self signed certificate with below code at root of the project you want to make use of it.openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -nodes
Step2: Fill the prompt with required details but when you get to Common name input localhost e.g Common Name (eg, fully qualified host name) []:localhost
step3: When your openssl cert.pem & key.pem has being generated startup your server then in another terminal or command line run curl --cacert cert.pem https://localhost:443
Note: I use port 443 which is the default https port, you can make use of another port then make sure cert.pem file path is well referenced.