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.
Related
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 have created a SSl certificate using these commands:
openssl genrsa -out kc_ca-key 2048
openssl req -new -out san_domain.csr -key kc_ca-key -config openssl.cnf
openssl x509 -req -days 3650 -in san_domain.csr -signkey kc_ca-key -out kc_ca-cert -extensions v3_req -extfile openssl.cnf
openssl.cnf file contains the common name, country name, subject alternative name and all such information.
In browser, I am able to connect securely after importing this certificate but when i run curl command with same certificate, i get the following error:
NSS error -8156 (SEC_ERROR_CA_CERT_INVALID)
* Issuer certificate is invalid.
* Closing connection 0
curl: (60) Issuer certificate is invalid.
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
How to resolve this error
There is not enough information to determine what your problem is.
I am making the following assumptions:
You sent the certificate request (CSR) to a CA provider and got a certificate back.
You setup some sort of web server with that certificate
I am also assuming that you used a "Windows" web browser like IE or Chrome that uses the windows certificate store to test the certificate.
The CA that signed your certificate is a well known CA that has there root certificates in all the common CA Lists.
If the above is true and a web browser like Firefox (that uses it's internal CA list) fails it's because the web server is using a certificate without any intermediate certificates.
You need to go find the intermediate certificates for your CA signed certificate, combine them into a certificate chain and setup your web server with this certificate chain. The details of how to do this will depend on your web server.
Once the web server is setup with a correct certificate chain then your curl command (and firefox) should work fine.
The reason that windows works fine is because windows keeps a list of common intermediate certificates that it can verify a certificate chain with. A openssl based client doesn't, so the intermediate certificates have to come from the SSL socket server (e.g. web server) down to the client to be able to verify the certificate chain back to a trusted root certificate in the client CA list.
I have a root certificate which I created based on a previously provided keypair (private & public). The certificate is called Root CA in file rootca.crt.
I've now been tasked with verifying a given signature with the Root CA.
I'm fairly sure this needs to be done through X509 but I'm not familiar with the command? The signature which I need to verify was supplied in Base64 and I've decoded it and converted to binary, so I believe the final step I'm missing is an OpenSSL X509 verify command, but that doesn't seem to exist?
Any advice would be appreciated, cheers.
Use the openssl verify command.
openssl verify -CAfile rootca.crt certificate
See also the verify(1) man page.
For school we are currently studying SSL certificates.
For this week's assignment we had to install Fedora Workstation on VirtualBox and do some SSL-stuff.
One of the assignments was the following:
generate a public/private keypair and a CSR with the openssl command.
I generated a public/private keypair using the following command:
openssl genrsa -out Desktop/mykey.key 2048
After I generated the keypair I had to verify it. But how do you verify a key? What is really meant by that? Just get out the public key and check if it matches the private key? This is the first question.
I generated the CSR using the following command:
openssl req -new -key Desktop/mykey.key -out Desktop/myCSR.csr
This is the right way, right?
Checking/verifying the CSR file was done using this command:
openssl req -text -noout -verify -in Desktop/myCSR.csr
I think that's the right way too.
This was the "easy" part, now comes the harder part:
We had to use xca to create a database and a CA Root Certificate. Then we had to import the csr from above question and sign it. I signed it by right clicking on it and choosing sign. Then we had to export both the CA and the signed key and verify it. But what do they mean exactly? My guess is to verify that the certificate is signed by the CA, but I'm having problems with that.
We have to use openssl x509 for that, but it just isn't working.
When I right click the signed key and export it as a PEM file, in that file is the following:
----- BEGIN CERTIFICATE REQUEST -----
MIIC6......
----- BEGIN CERTIFICATE REQUEST -----
while the assigment says: export the signed certificate. But is this even a certificate?
And how do I verify it?
I used many commands, like
openssl x509 -in Desktop/exported.pem -text -noout
But the output I get is always something like this:
I have tried all sorts of commands and read all google pages, but nothing helps.
this is the second question
Hope you all can help, Thanks!
When you verify a certificate, you are checking whether it's CA is recognised, and it matches the CA's fingerprint. It doesn't look like you are providing the CA cert to the openssl command. Try specifying -CA <your CA cert file:
$ openssl x509 --help
...
-CA arg - set the CA certificate, must be PEM format.
I can not verify the certificate by openssl
openssl verify cert.pem
Gets something like this:
cert.pem: / C = PL / O = DATA
error 20 at 0 depth lookup: unable to get local issuer certificate
The same cert from the machine on Centos - verified correctly.
Debian: squeeze / sid
Is it a problem with the CA ROOT? Update openssl help?
Unlike browsers, which trust nearly everything from anybody, OpenSSL trusts nothing by default.
Its up to you to determine what should be trusted. You will have to specify something when using OpenSSL. It may be a cert or list of certs to trust.
The directory /etc/ssl/certs contains many certs. Using such directory should allow to verify almost anything:
openssl verify -CApath /etc/ssl/certs cert.pem
It is recommended that you reduce the number of trusted certs to one, two or the minimum possible.
You need to specify the CA cert in order to verify the issued cert since it's obviously not included in the pem (though this would be possible):
openssl verify -CAfile your_ca_cert_file cert.pem
If you do not get the error on centOS then there's the CA cert around and openssl can use it to successfully verify cert.pem
You need to make your CA trusted on the server. For example, if your cert is from goadday, run the following commands.
cd /tmp
sudo wget -O gd_intermediate.crt https://certs.godaddy.com/repository/gd_intermediate.crt
sudo cp /tmp/gd_intermediate.crt /usr/local/share/ca-certificates/gd_intermediate.crt
sudo update-ca-certificates
After running these commands, your certificate should be verified.
openssl verify cert.pem