Private OpenSSL CA and Certificates

A few days ago Thunderbird stopped connecting to a SSL-secured IMAP server. Digging around this showed that I would now only accept SSL certificates (from a private CA) which contain Subject Alt Names. As my CA setup in 2020 did not contain those I had to re-setup the whole thing. For the sake of documentation and reference the neccessary steps are outlined here. This is based on code snippets found on [1] and [2].

Setting up the CA

This is about setting up (a new) CA and using 4096 bits RSA keys:

$ mkdir CA
$ cd CA/
$ mkdir newcerts certs crl private requests
$ touch index.txt
$ echo '20' > serial

$ openssl genrsa -aes256 -out private/cakey.pem 4096
$ openssl req -new -x509 -key private/cakey.pem -out newcerts/private_CA.pem -days 3650 -set_serial 0

Generating a client certificate

Now generate a client certificate with SAN extenstions:

openssl genrsa -aes256 -out private/servername.key 4096
openssl req -new -reqexts SAN -config <(cat /usr/lib/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:servername.local,DNS:*.servername.local")) -key private/servername.key -out requests/servername.csr

Check for SAN extenstions:

$ openssl req -in requests/servername.csr -noout -text | grep -A1 "Subject Alternative Name"

Signing the client certificate

Finally sign the client certificate using the CA set up earlier and use SAN extensions:

$ openssl ca -extensions v3_ext -config <(cat /usr/lib/ssl/openssl.cnf <(printf "[ alt_names ]\nDNS.1 = servername.local\nDNS.2 = *.servername.local")) -in requests/servername.csr -out certs/servername.crt

Verify that the generated certificat contains the SAN extensions:

$ openssl x509 -in certs/servername.crt -noout -text | grep -A1 "Subject Alternative Name"

Remove the passphrase from private key

This is useful in case the keys are used for web- or mailservers and you do not want to enter the passphrase each time the processes are (re-)started.

$ openssl rsa -in servername.key -out servername_withoutpass.key

Update

As the certifcate as generated above did not work on a dovecot IMAP server the server certificate had to be revoked. This can be done using the command

$ openssl ca -revoke newcerts/SERIAL_NO.pem

The certificates had the following key usage constraints as per openssl.conf:

basicConstraints=CA:FALSE
keyUsage=keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth

The latter two were obviously causing the errors resulting in an error message like

KEY_USAGE_BIT_INCORRECT

Not sure shich of the two options caused the hickup but disabled both and re-generated certificates without the key usage constraints were working fine. It might have to do with [3].

Update 2

In order to compile a certificate revokation list ta file you can use:

$ echo '01' > crlnumber
$ openssl ca -gencrl -out revoked.crl.pem

And the result can be checked by issuing:

$ openssl crl -in revoked.crl.pem -noout -text

References

[1] https://networklessons.com/uncategorized/openssl-certification-authority-ca-ubuntu-server
[2] https://kubernetes.io/docs/tasks/administer-cluster/certificates/
[3] https://boringssl.googlesource.com/boringssl/+/d7266ecc9bf92ffad277bc39653919da79c8f42b