Normal web traffic is sent unencrypted over the Internet. Anyone with access to the right tools can intercept all of that traffic. Obviously, this can lead to problems where security and privacy are necessary. As such, the Secure Socket Layer (SSL) is used to encrypt the data stream between the server and the client.
SSL makes use of what is known as asymmetric cryptography, commonly referred to as public key cryptography (PKI). Using this model, two keys are created (one public and one private.) Anything encrypted with either key can only be decrypted with its corresponding key. Thus, if a message or data stream were encrypted with the server's private key, it can only be decrypted using its corresponding public key. This allows us to ensure that the data has come from the intended server, free of third party interception.
Using the tools like the OpenSSL Toolkit, we have the ability to manage our SSL key creation process.
Self-Signed Certificates
The process for creating self-signed certificates is pretty easy, and really only involves two necessary steps.
- Create your private key
- Create a signed public key
Creating your private key
Just about every linux distribution these days comes with openssl installed by default, but if not it should be easy to apply to your system. Once done, you can use a single command at the commend line the create your private keys. For example, supposing we would like to create a private key using openssl, you can use the follwoing command:
$ openssl genrsa -out priv.key 1024
In this example, we have generated a default RSA key with an encryption level of 1024 bits. For further security, you can encrypt the encryption key itself, requiring that a password be applied before you can even read the key. To do this, you just need to specify the encoding type for the key.
$ openssl genrsa -des3 -out priv.key 1024
Openssl will then prompt you for the password to use and it will encode the key.
Creating your public key
Similarly, the public key creation process is also simple.
$ openssl req -new -x509 -sha256 -key priv.key -out cert.pem -days 365
Here, you are requesting that a public certificate be created based off of your previously created private key. After entering this command, openssl will prompt you to enter in various certificate information for your key, such as the Country, State and Organization to be signed on the certificate. Most importantly, it will ask you for the Common Name of the certificate. This name must match the server's DNS address you are using to access your resource, otherwise you may receive notifications from your client software about the mismatched names. Although not a problem functionally, this can create a lot of problems with your users, especially those who are less technically inclined.
Creating PEM files
PEM files are a certificate container format that has been defined in RFC 1421 - 1424. It stands for Privacy Enhanced electronic Mail, and as the name suggests, it was originally designed for a (failed) attempt at securing email on the web. The container format, however, has persisted past the original intended mechanisms.
A PEM file will include all or some of the certificates in a certificate chain (public and private certificates, intermediate certificates, and root certificates). If your application requires more than just the public certificate contained inside your PEM, you can easily create a new PEM by concatenating multiple certificates together. For example:
$ cat priv.key pub.cert > certificate.pem
CA-Signed Certificates
If you are having your certificates signed by a third party Certificate Authority (CA), the process is very similar to that of the self-signed certificates. Instead of creating a public signed-key, however, you will create a certificate signing request (CSR). Continuing from the examples above, we can use the following to make a CSR from the private key:
$ openssl req -new -key priv.key -out request.csr
Once completed, you will hand off your CSR to your CA and they will provide you with the new public key, signed by their CA chain. Make sure you request a certificate signed with the sha2 family (for example, sha256), as some browsers will no longer support sha1 signatures (i.e., Chrome).
