Generate self signed certificates with SAN using openSSL

As developers it is quite common to have the need for certificates that can be attached to web servers or application servers or processes(java, nodejs, python etc) to facilitate TLS communication for the applications. So self signed certificates is the most easiest way to generate our own certificates without relying on a public and trusted CA(certificate authority). In this article we will go through how to generate public key certificates with and without SAN and how to inspect a public key or X509 certificate.

Pre-requisite

openssl — mostly available by default in linux installations. If not, please install based on your OS support.

Generate self signed certificate:

To generate a self signed certificate, use below command. It will prompt you with several options, either press enter or provide values to your liking. The only value that really matters when establishing TLS communication with most of the applications is the Common Name (aka CN) . If SAN(Subject alternate name) is not available(later we will see how to add SAN to a cert) in the certificate to match a domain, most of the tools will try to match the domain with the CN and will fail if they don’t match. So if you don’t want to add SAN but want to rely on a hostname/CN, use below command

openssl req -x509 -nodes -newkey rsa:4096 -keyout api-server-key.pem -out api-server-cert.pem -sha256 -days 365

This should generate two files:

private key => api-server-key.pem

public key (aka generally referred as certificate) => api-server-cert.pem

Normally for enabling TLS communication for an application, both the above files are required to be provided to that application in some manner as specified by that application.

Inspect the generated certificate:

openssl x509 -in api-server-cert.pem -noout -text

Generate self signed certificate with SAN(Subject alternate name):

It is highly likely that we want to reuse the same certificate for multiple local applications and we want to use the same cert for different test domains.

For example, let’s say we want this self signed cert to be valid for test.local.com , test1.local.com , abc.sample.com DNS names, then we need to add these to Subject Alternate field. To achieve that we can use the openssl command but instead of providing the manual input , we will provide a config file.

Let’s create a config file name self-signed-config.conf

[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = WA
L = Seattle
O = mytravelquotient
CN = mytravelquotient
[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = test.local.com
DNS.2 = test1.local.com
DNS.3 = abc.sample.com

And now run this command, pay attention to the last parameter in the command( -config ) which feeds in above config file as input

openssl req -x509 -nodes -newkey rsa:4096 -keyout api-server-key.pem -out api-server-cert.pem -sha256 -days 365 -config self-signed-config.conf

Let’s inspect the generated cert again..

openssl x509 -in api-server-cert.pem -noout -text

There you go, now you can see that the SAN(Subject Alternative Name) field in the certificate contains the provided DNS entries.

Why add SAN to the certificate?

This means, if you have a local web/application server serving TLS, then you can use the above generated private key/public key pair with that server to accept traffic at the TLS endpoint and serve multiple domain names. And you can expose endpoints locally with different domain names and consume them in other client application with no certificate/tls handshake errors with hostname/SANmismatch errors. Don’t forget to map a local IP/remote IP for below DNS in your /etc/hosts or host file relevant to your OS platform.

https://test.local.com
https://test1.local.com
https://abc.sample.com

Hope this article helped you in creating a self signed certificate for local development! Happy coding!