Securing the Connection: Creating a Security Certificate with OpenSSL

Today we will be taking a look back at OpenSSL. In this the first episode of our web security series we have a tutorial that will walk you through the nuts and bolts of creating a security certificate.

Certificates are hashed keys that tie an entity to a specific originating address/domain name. They are also used during HTTPS communication to generate the tokens that enable the encryption of application data by a web server. By allowing the web server to cipher its incoming and outgoing traffic it makes it harder to achieve man in the middle attacks or eavesdropping. Thus, having security certificates provides an additional layer of security and privacy. The certificates that we make reference to here are the ones used for the HTTPS protocol. There are other types of certificates otherwise known as digital signatures which have a few important differences and uses but we will not touch on them in this session.

You can generate the keys and the resulting Certs (short for Certificate) with many tools but by the far the most common toolchain is the open source OpenSSL library. If you have no idea what OpenSSL is then review our earlier Key Based Encryption Using OpenSSL primer which covers the basics.

Before we begin ensure that the library and commandline tools are installed on your chosen workstation's Operating System (OS). This tutorial assumes that this a Linux/Unix based environment and that you need to generate an initial Certificate Signing Request (CSR) which will be submitted to a Certificate Authority (CA) who will then generate and provide the final publicly recognized Cert file. However, we do go over the process to generate a valid Cert by self signing the CSR produced.

Generating a Security Certificate

1st step is to generate a private key.

Creating a Private Key

A private key can be created with the openssl command when the genpkey option is used. In the below example, a 2048 bit private key is created using the RSA algorithm and DES triple pass encryption and saved to the file private.key.

openssl genpkey -algorithm RSA -des3 -out private.key -pkeyopt rsa_keygen_bits:2048

Removing Passphrase from Key File

Depending on the options selected during creation of the keys a password may have been associated with the private key. It is sometimes useful to remove this password as it will need to be manually entered by the web server to access any certs produced from a CSR based on a password protected private key. [1] Also most CA's will ask that you not password protect the CSR.

Follow these steps to remove the password before the creation of the CSR.

  1. Backup the passphrase protected key file cp private.key private.key.orig
  2. Remove the passphrase openssl rsa -in private.key.orig -out private.key

Creating a Certificate Signing Request (CSR)

After the private key has been generated a CSR file needs to be created from this key. The CSR is the file that will be submitted to the CA for signing. Essentially, a CA is a public company that has been given the rights to vouch for another entity's identity. The CSR allows them to generate a unique key i.e Certificate which has been signed by a key produced from combining the CA's keys with the CSR.

openssl req -new -key {private key file} -out {output file}

A Self Signed Certificate

There are instances when a CA is not always available or needed. The most common reason to forgo a CA are when deploying to a test environment or when using a certificate on an internal network (LAN) where encryption of communication over the transport is more important than validating the originating identity. In these scenarios trust is implicit but encryption is still desired.

To satisfy such use cases a certificate can be self-signed. Self signing produces a valid Certificate for which there is no CA or a CA that cannot be reached. When clients connect to a site whose identity cannot be verified they will be presented with a warning by the User Agent (browser in most instances).

openssl x509 -req -days 365 -in {csr file} -signkey {key file} -out {cert file}

Now that we have a Certificate the next step will be to configure the web server to actually utilize it. As a part of this configuration the port that the server binds to will be migrated from port 80 to 443. That is the server will go from using HTTP to using HTTPS.

Look out for the follow up articles in this series where the setting up of the web server aspect is demonstrated for Nginx, Apache httpd and Tomcat.

  1. Once the passphrase is removed from the private key the key can be freely moved to another system and reused potentially allowing an attacker to fake the original server's identity. If a private key is compromised then the CSR and certificates will have to be generated again and resigned by a CA. Ensure that the read permissions for the key is restricted to root only. ↩︎