Using OpenSSL to generate CSR’s with Subject Alternative Name

This post details how I’ve been using OpenSSL to generate CSR’s with Subject Alternative Name Extensions. You may have noticed that since Chrome 58, certificates that do not have Subject Alternative name extensions will show as invalid. Amazing, I must have missed the memo on that. Most of the certificates I use in my home lab do not have these extensions so I was getting untrusted certificate warnings. Yes, you can waive your “but certifcates should contain SAN as per the RFC” flag at me but if the device you generate the CSR from does not support adding subject alternative name extensions you have to generate them manually. I’ve had to regenerate pretty much all the certificates in my lab using OpenSSL.

This is the process I followed using OpenSSL on Ubuntu:

Step 1 – Create an OpenSSL configuration file

Create a configuration file and populate the details you need specific to you CSR. In the below example I was generating a new one for my prtg server:

more openssl-csr.conf
[ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
req_extensions     = req_ext
[ req_distinguished_name ]
countryName                 = GB
stateOrProvinceName         = Cambs
localityName               = Peterborough
organizationName           = Net Assured Limited
commonName                 = Common Name (e.g. server FQDN or YOUR name)
[ req_ext ]
subjectAltName = @alt_names
[alt_names]
DNS.1   = prtg1.corp.netassured.co.uk
DNS.2   = www.prtg1.corp.netassured.co.uk

Step 2 – Using OpenSSL to generate CSR’s with Subject Alternative Name extensions

Generate the request pulling in the details from the config file:

sudo openssl req -out prtg1-corp-netassured-co-uk.csr -newkey rsa:2048 -nodes -keyout prtg1-corp-netassured-co.uk.key -config openssl-csr.conf

You’ll notice that you’ll not be prompted for the SAN extensions but they’ll still be present in the CSR. You can view them by running:

openssl req -noout -text -in prtg1-corp-netassured-co-uk.csr

Now proceed as normal to have your certificate signed by a CA, import to your devices and hopefully not receive any more untrusted certificate errors.