In this process, we will learn how to create self-signed Secure Sockets Layer (SSL) certificates using the OpenSSL toolkit. SSL is a technology used to encrypt messages between two ends of communication (for example, a server and client) so that a third-party cannot read the messages sent between them. Certificates are not used for encrypting the data, but they are very important in this communication process to ensure that the party you are communicating with is exactly the one you suppose it to be. Without them, impersonation attacks would be much more common.
To Start With: What Do You Need?
To complete this process, you will require a working installation of the CentOS 7 operating system with root privileges and a console-based text editor of your choice.
Note
Generally speaking, if you are intending to use an SSL Certificate on a production server, you will probably want to purchase a SSL Certificate from a trusted Certificate Authority. There are many options open to you regarding what certificate best suits your requirements and your budget, but for the purpose of this process, we will confine our discussion to a self-signed certificate that is more than adequate for any development server or internal network.
The Process
- To begin, log in as root and go to the following directory so that we can use the Makefile to generate our intended certificates and keyfiles:
cd /etc/pki/tls/certs - Now, to create a self-signed certificate with an embedded public key (both in the file, server.crt) along with its private key for the server (with the filename as server.key), type the following:
make server.crt - You will then be asked for a password and will receive a series of questions, to which you should respond with the appropriate values. Complete all the required details by paying special attention to the common name value, which should reflect the domain name of the server or IP address that you are going to use this certificate for. For example, you may type:
mylocaldomainname.home - To create a pem file that includes a self-signed certificate and a public and a private key in one file, and is valid for five years, type the following:
make server.pem DAYS=1825 - Now, let’s create a key pair (a private key and self-signed certificate that includes the public key) for an Apache web server that we will need for enabling https, and which will be generated in /etc/pki/tls/private/localhost.key and /etc/pki/tls/certs/localhost.crt (use a secure password and repeat it in the second command):
make testcert - To create a Certificate Signing Request (CSR) file instead of a self-signed certificate, use this:
make server.csr
How Does It Work?
Here in this process we introduced you to the SSL technology that uses public key cryptography (PKI) (where two forms of keys exist: public and private). On the server, we store the private key and our clients get a public key. Every message sent from one end to the other is encrypted by the key belonging to one side and can only be decrypted by the corresponding key from the other. For example, a message encrypted with the server’s private key can only be decrypted and read by the client’s public key and vice versa. The public key is sent to the client through a certificate file, where it is part of the file. As said before, the public key is encrypting and decrypting the data and the certificate is not responsible for this, but rather for identifying a server against a client and making sure that you are actually connected to the same server you are trying to connect. If you want to set up secure services using SSL encryption in protocols such as FTPS, HTTPS, POP3S, IMAPS, LDAPS, SMTPS, and so on, you need a signed server certificate to work with. If you want to use these services for your business, and you want them to be trusted by the people who are using and working with them, for example, on the public Internet, your certificate should be signed from an official certification authority (CA). Certificate prices are paid by subscription and can be very expensive. If you don’t plan to offer your certificate or SSL-enabled services to a public audience, or you want to offer them only within a company’s intranet or just want to test out things before buying, here you can also sign the certificate by yourselves (self-signed) with the OpenSSL toolkit.
Note
The only difference between a self-signed certificate and one coming from an official CA is that most programs using the certificate for communication will give you a warning that it does not know about the CA and that you should not trust it. After confirming the security risk, you can work with the service normally.
So, what did we learn from this experience?
We started this process by going to the standard location where all the system’s certificates can be found in CentOS 7: /etc/pki/tls/certs. Here, we can find a Makefile, which is a helper script for conveniently generating public/private key pairs, SSL CSRs, and self-signed SSL test certificates. It works by hiding away from you complicated command line parameters for the OpenSSL program. It is very easy to use and will automatically recognize your target through the file extension of your filename parameter. So, it was a simple process to generate an SSL key pair by providing an output filename with the .crt extension. As said before, you will be asked for a password and a list of questions regarding the ownership of the certificate, with the most important question being the common name. This should reflect the domain name of the server you are planning to use this certificate for, because most programs, such as web browsers or email clients, will check the domain names to see if they are valid. The result of running this command was the certificate with its embedded public key in file server.crt, as well as the corresponding private key for the server called server.key.
Next, we created a .pem file and provided a DAYS parameter to make the certificate valid for five years instead of the default one year when you are running without it. A pem file is a container file that contains both parts of the key pair: the private keys and the self-signed certificate (with its embedded public key). This file format is sometimes required by some programs, such as vsftpd, to enable SSL encryption instead of providing the key-pair in two separated files. Next, we ran the Makefile target testcert, which generates a private key as well as a public key, plus the certificate in the correct location, where the Apache web server is expecting them for setting up HTTPS. Please note that, if you need to repeat any Makefile run later, you need to delete the generated output files; for example, for Apache, you need to delete the following files before you can build the output files again:rm /etc/pki/tls/certs/localhost.crt /etc/pki/tls/private/localhost.key make testcert
Finally, we showed you how to generate a CSR file, which will be needed if you plan to purchase an SSL certificate from a trusted certificate authority.
There's more…
We did not cover all the possibilities that the Makefile script has to offer to generate certificates. If you run the command, make, without giving any target parameter, the program will print out a usage help text with all possible options.
As we have learned, the public and private keys are generated in pairs and will encrypt and decrypt each partner’s messages. You can verify that your key pairs are valid and belong together by comparing the output of the following (which must be exactly the same):openssl x509 -noout -modulus -in server.crt | openssl md5 openssl rsa -noout -modulus -in server.key | openssl md5
