Verify pem certificate chain using openssl

certificateopensslSecuritysslssl-certificate

I am trying to write a code which receives a pcap file as an input and returns invalid certificates from it.

I have parsed certificate chains, and I'm trying to verify them.
Because I get the certificates chains out of a pcap the chain length are not constant (sometimes they includes only 1 certificate that is selfsigned (and valid)).

Let cert0.pem be the servers certificate and certk.pem the root CAs certificate.

According to my research online I'm trying to verify the certificate as follows:

Create a file certs.pem which contains the certificate chain in the order:
certk.pem, certk-1.pem,… ,cert0.pem
use the command (ca.pem is a file containing root certificates):
```
openssl verify -CAfile ca.pem certs.pem 
```

But sometimes the verification goes wrong even for valid certificates, as in the following output:

C = US, O = GeoTrust Inc., CN = GeoTrust Global CA <br>
error 20 at 0 depth lookup: unable to get local issuer certificate<br> 
error certs.pem: verification failed

please help me, how can I verify the certificate chain ?

Additionally is there a way to add a host name verification in the same line? (I have tried to add "-verify_hostname name" but again, the output was unexpected).

Best Answer

For remote certificate validation the error you mentioned here says that the first local certificate (depth 0) in your chain file that you are trying to verify namely being certk.pem as root CA certificate has to exist / imported in your local client trusted certificates store that you are performing your verification from.

As stated at thawte.com support site:

This is the verification output of the Server Certificate sent by the server. The server sends its complete chain consisting of 2 certificates, one (depth 0) being the server's certificate "CN=www.yourdomain.com" and the other one being the CA certificate "CN=Thawte Server CA". As all root certificates, this certificate is self-signed.
In order to avoid this error, your client must have a local copy of the root CA certificate in their trusted certificate store, either in CAfile of CApath.

ALSO: Consider using -show_chain verify option to view more details and/or errors in your certificate chain. Note that this error behavior is expected and by default when verifying a certificate from a non-trusted CA. You can check for the error codes in the openssl wiki.

Related Solutions

How to create the own certificate chain

You can use OpenSSL directly.

Create a Certificate Authority private key (this is your most important key):
```
openssl req -new -newkey rsa:1024 -nodes -out ca.csr -keyout ca.key
```

Create your CA self-signed certificate:

openssl x509 -trustout -signkey ca.key -days 365 -req -in ca.csr -out ca.pem

Issue a client certificate by first generating the key, then request (or use one provided by external system) then sign the certificate using private key of your CA:
```
openssl genrsa -out client.key 1024
openssl req -new -key client.key -out client.csr
openssl ca -in client.csr -out client.cer
```

(You may need to add some options as I am using these commands together with my openssl.conf file. You may need to setup your own .conf file first.)

Linux – SSL Root CA certificate is not recognized, although present in the trust store. Why

OpenSSL at least through current (1.0.2a) has a bug where s_client with NO -CA{path,file} argument doesn't actually use the default truststore as it should, and thus fails to verify certs that are valid according to that truststore. (Also s_server and s_time, but caring about verification in those is rare.) See https://serverfault.com/questions/607233/how-to-make-openssl-s-client-using-default-ca . A fix is announced in dev, but may take some time to be released and distributed. In the meantime you need to explicitly specify the -CA* argument(s). Note that openssl verify does not have this bug, and therefore correctly reported the cert/chain as valid.

UPDATES 2015/08/26: fix was released 2015/06/12 in 1.0.1o and 1.0.2c. Also, while investigating something else I found that RedHat packages may have been okay. More specifically the CentOS source RPM for openssl-1.0.1e-30.el6.11 which I understand is a copy of the RedHat one (but can't easily confirm) contains openssl-1.0.1c-default-paths.patch which contains changes to s_client.c s_server.c s_time.c dated 2012/12/06 that appear equivalent to (though not textually the same as) the 2015/06/12 upstream fixes. Assuming this patch was applied in RedHat and CentOS packages, which I can't easily go back and check, they would (have) work(ed) as expected.

Best Answer

Related Solutions

How to create the own certificate chain

Linux – SSL Root CA certificate is not recognized, although present in the trust store. Why

Related Question