Tuesday, 7 September 2021

openssl - Get your subject right

I'm tinkering with OpenSSL to create a Certificate Authority, server keys/certificates and client keys/certificates and keys.

Having done all of this, I was then looking to verify the server's certificate - server-cert.pem - again using openssl as follows: -

openssl verify server-cert.pem 

C = GB, O = IBM, CN = david_hay.uk.ibm.com
error 18 at 0 depth lookup: self signed certificate
error server-cert.pem: verification failed

Wait, what now ?

Thankfully, this came to my rescue: -

I think you missed this part of the instructions:

Whatever method you use to generate the certificate and key files, the Common Name value used for the server and client certificates/keys must each differ from the Common Name value used for the CA certificate. Otherwise, the certificate and key files will not work for servers compiled using OpenSSL.

When OpenSSL prompts you for the Common Name for each certificate, use different names.


When I created the server's certificate: -

openssl req -newkey rsa:2048 -nodes -keyout server-key.pem -out server-req.pem -subj '/C=GB/O=IBM/CN=david_hay@uk.ibm.com

I'd used the same Subject as I used for the Certificate Authority (CA) e.g.

openssl req -new -x509 -nodes -days 365 -key ca-key.pem -out ca-cert.pem -subj '/C=GB/O=IBM/CN=david_hay@uk.ibm.com

which is a pretty bad idea.

Once I did it properly: -

openssl req -new -x509 -nodes -days 365 -key ca-key.pem -out ca-cert.pem -subj '/C=GB/O=IBM/CN=etcd_ca'

for the CA and: -

openssl req -newkey rsa:2048 -nodes -keyout server-key.pem -out server-req.pem -subj '/C=GB/O=IBM/CN=etcd_server'

for the server, all was well.

For reference, this is from where I started wrt using openSSL in this context: -

No comments:

Yay, VMware Fusion and macOS Big Sur - no longer "NAT good friends" - forgive the double negative and the terrible pun ...

After macOS 11 Big Sur was released in 2020, VMware updated their Fusion product to v12 and, sadly, managed to break Network Address Trans...