Several applications which communicate over the internet or even on private networks, need to make sure that each communicating party is who it claims to be and securely communicate with each other. The Public Key Infrastructure (PKI) technique is one of the methods that tries to achieve this goal, using a pair of digital certificates. The first is the private key which is maintained in a secure location by its owner. The second is the public key, which, as its name implies, is known to everyone.

This article presents how to create self-signed certificates, to be used in the development and testing phase of software applications. In a real-world case, the certificates must be encrypted and stored in secure locations, but these issues are not going to be covered here.

OpenSSL has a huge number of commands and each command has several parameters. The cases below implement a small subset of them, as the purpose is to present a step-by-step example of obtaining digital certificates for testing purposes.

Normally, the process for creating digital certificates is as follows:

1. Any individual can create a long numeric sequence, using OpenSSL. This sequence is stored in a file, which is referred to as the private key. This private key is never shared with anyone and is kept in a secure location, where only the administrator has permissions to access.

2. The same individual uses the newly created private key in order to generate with OpenSSL a Certificate Signing Request (CSR). This is another long numeric sequence, stored in a file which usually has the extension .csr. The extension just signifies the usage of the file. Actually the format of the file is PEM, that is why both of our key files have the .pem extension. This is of course just for us humans. Files can be named anyway you like.

3. The individual sends the Certificate Signing Request to a trusted entity, which is known as the Certificate Authority (CA). The communication can take place even on a non-secure medium, because the CSR has been generated by the private key, but the private key still remains at the sole ownership of its creator.

4. The Certificate Authority (CA) performs a process which is called signing of the CSR. In this process, the CA uses their own private and public keys, in order to transform the CSR into a certificate, the public key. Before signing the CSR, the CA confirms the identity of the individual. The security behind this process is not discussed here.

5. The CA forwards the public key to the individual. As the key is public, it can be transmitted over non-secure media.

6. Finally, the individual can encode outbound data using its secret private key. The receiver uses the public key of the individual to decode the message, and be certain that the source of the message is actually the individual. Anyone can also send messages to the individual, using the public key to encode the message. This encoded message can only be opened if decoded by the private key of the individual.

In our case, we will not burden any third-party (and avoid any payments for their services), so we will build a process where we will also function as a CA. The steps are shown below:

As a CA, we must also have a private and a public key. We create both with the command:

$ openssl req -newkey rsa:2048 -sha256 -x509 -days 365 -out CAcert.pem -keyout CAkey.pem -outform PEM

We have therefore created files CAkey.pem which is the private key of our CA and CAcert.pem which is the public key of our CA.

Each CSR that is signed by the CA contains a serial number. The CA maintains in its memory the next serial number. We shall use file file.srl to keep track of this number.

$ echo '01' > file.srl 

This step needs to be performed only once, before creating our first certificate. To create additional certificates, we shall start with Step 2.

Now, we resume our identity as the individual who wishes to create its digital certificates. First, generate the private key. In our example, we are creating a key for a server, so we decide to call the file serverkey.pem:

$ openssl genrsa -out serverkey.pem 4096

This will create a sequence of 4096 bits and store it into file serverkey.pem.

Next, generate the CSR, using the private key:

$ openssl req -new -key serverkey.pem -sha256 -nodes -out servercert.csr -outform PEM

This will create the CSR in file servercert.csr. With parameter -nodes we make sure that the certificate will not be encoded and a password will not be required to open it.

We could also create private key and CSR with one command:

$ openssl req -newkey rsa:2048 -sha256 -nodes -out servercert.csr -keyout serverkey.pem -outform PEM

You can inspect the content of the certificate request file:

$ openssl req -text -noout -verify -in servercert.csr

In the next step, we assume the role of the Certificate Authority and we sign the CSR:

$ openssl x509 -req -in servercert.csr -CA CAcert.pem -CAkey CAkey.pem -CAserial file.srl -out servercert.pem -days 365

This command will create file servercert.pem, which is going to be our public key. The certificate will be valid for a limited period, specified by the -days parameter. In the above example, it will be valid for 365 days.

You can inspect the contents of the certificate with:

$ openssl x509 -in servercert.pem -text -noout

Going through the above steps, we have created our own Certificate Authority and we have created our own self-signed private and public keys. If we need additional certificates for more applications or servers, we can go through Steps 2 and 3 as many times as we like.