Making your own CA work that works with Google Chrome

Niels Basjes, 03 February 2018

This post is about one single aspect of running your own CA (usually for internal systems): Making it actually work with Google Chrome. The reason I writing this down is because I found all the other sources of information around the world very confusing.

The main problem is twofold:

  • Newer browsers (like Google Chrome) require that the “Subject Alternative Name” has been defined as part of the certificate.
  • When simply signing a certificate request (which includes a “Subject Alternative Name”) with openssl this property is lost and the resulting certificate doesn’t work.

Create your own CA.

On CentOS 7 (which I use right now) the openssl package contains the /etc/pki/tls/misc/CA script that makes doing this very easy.

Generate key and create a certificate request.

Now the confusing part here is that it doesn’t matter if the “Subject Alternative Name” is or isn’t present in the certificate request.

If the “Subject Alternative Name” is present in the certificate request it will be ignored anyway.

So you can create the key and certificate request with any existing system and manual.

Three basic ways for doing this: Some systems already have one and/or is capable of generating one as part of the solution (like I have seen in VMware ESXi). So this part is done for you. Simply using the script provided with openssl for this purpose

/etc/pki/tls/misc/CA -newreq

This will create newkey.pem and newreq.pem Manually via a config file. So if you create a config file with something like this:

default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
[ dn ]
ST=Noord Holland
OU=At home
CN =

then with this config file (let’s call it you can do

openssl req -new -sha256 -nodes \
        -out \
        -newkey rsa:2048 \
        -keyout \

Now sign the request and add the desired “Subject Alternative Name” values To do this we create this config file where we include all the hostnames and IP addresses we want to allow (let’s call it

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[ alt_names ]
DNS.1 =
DNS.2 =
IP =

Now we sign this where we add the config file (-extfile) and instruct to use the extra settings present under v3_req (-extensions). The actual name of the “v3_req” section doesn’t really matter.

openssl ca -policy policy_anything \
       -out \
       -in \
       -extfile \
                 -extensions v3_req

If during the signing you see something like this then everything went right.

Certificate Details:
    X509v3 extensions:
        X509v3 Subject Alternative Name: 
  ,, IP Address:

As you see the signing command is pretty standard and really only adds the config file with the SAN extension.

Last remark

And to actually make your own CA work with chrome you have to import the certificate of your own authority /etc/pki/CA/cacert.pem file into chrome as a new authority.