Public/private keys are essential tools for secured traffic on the Internet. Each has its own place and function; you configure critical services with a private key and make a public key available to users who want to use that service. It is common to use an external commercial service such as Verisign to sign the public key in a public key certificate, thus guaranteeing the key's authenticity. For in-company use, however, there is no need to do that. In this tip, you will learn how to set up your own Certificate Authority (CA) using the command openssl, a product of the OpenSSL project. You will then create a public key certificate with that CA. This is an easy way to assure clients they will be secure while interacting with your email server.
Setting up a Certificate Authority
To manage certificate-related issues on Linux, you can use the openssl command. This command is used to create and manage certificates and certificate authority for your server. In this section, you'll learn how to use the openssl command to create a certificate and a self-signed CA. In this example, the self-signed CA is the highest level in the CA hierarchy, so it will be a root-CA. The following procedure explains how to proceed:
- Decide where you want to create the directory structure in which you will put the CA. The directory structure should be inaccessible to other users. For example, the home directory of the user root might be a good location because ordinary users don't have access to it.
- Some subdirectories must be created in this directory. From the directory of your choice, start with mkdir root-CA to create a subdirectory in which the CA will store its files.
- Next, you must create some subdirectories in this root-CA directory. The names of these subdirectories are pre-defined in the configuration file /etc/ssl/openssl.cnf:. Hence, you shouldn't try anything creative unless you are willing to change all settings in this configuration file as well. The command will create these directories for you. They serve the following purposes:
- Certs: All signed public key certificates are stored here. You may make this directory publicly accessible.
- Newcerts: This directory stores all new certificates that haven't yet been signed.
- Private: The private key of your server is stored in this directory. Protect it like the crown jewels! The least you should do is give this directory permission mode 700 (chmod 700 private).
- Crl: If any are needed in your environment, Certificate Revocation Lists are stored in here.
- To make creating the certificate for the root-CA a bit easier, open the configuration file /etc/ssl/openssl.cnf. In this file, you will find some default ...
To continue reading for free, register below or login
To read more you must become a member of SearchEnterpriseLinux.com
settings used when creating new certificates. Read the file and modify all settings as required.
- Make sure that all directory paths are OK by modifying the HOME and the dir variables. Also, it is a good idea to set the names of the certificates to the right value. Listing 1 shows what this could look like. All non-essential parameters have been omitted from the list.
Listing 1: Some important settings from the openssl.cnf file
Now that you have tuned the configuration file the proper way, you can create a self-signed certificate for the root-CA. The following command creates the certificate with a 1024-bits RSA key that is valid for 10 years:
The main command used here is the openssl command. This command has several parameters that operate as if they were independent commands. The parameter req in this example is used to create the self-signed certificate (check its man page to see everything it can be used for). To make sure there is no misunderstanding regarding the place where these keys are created, the parameter -keyout is used to specify where to put the private key and -out is used to define the location of the public keythat you create. All the other options are used to specify with what parameters the key must be created.
Creating the key will start an interface in which several questions are asked (see Listing 2). The most important of all these questions is the prompt for a passphrase. Since we are creating a root-CA in this example, using a passphrase is mandatory; otherwise, it would be possible for anyone who accessed your machine to create public key certificates signed by this CA, which would make this CA worthless.
Listing 2: While creating the public/private key pair, you are prompted for the associated owner information and a passphrase to protect the private key.
Note: You should always watch the output of the openssl commands carefully. It's not easy to see errors, but it is easy to make them through small typing mistakes. You should fix all errors before proceeding to the next step.
Congratulations! You now have your own root-CA. This makes it possible to create your own certificates and use them for any purpose. For example, think of server certificates that are used for secured email, or client certificates used to connect a notebook to a VPN gateway.
Creating the OpenSSL database and key pair
Before you can start creating your own certificates, you need to create the OpenSSL database. This database consists of two files where OpenSSL keeps track of all the certificates that it issued. You need to create these two files by hand before you start. Change to the home directory of your root-CA first. From there, use touch index.txt and then use echo 01 > serial to create this simple database.
- Now that the database index files are present, you need to create the key pair and the associated key signing request. To do this, first use to go to the root directory that is used by your certificate authority. Next, enter the command . In this example, I have used the name "mailserverkey," which makes it easy to identify what the key is used for. Of course, you can use any name you like here. With this command, you have created a new key pair of which the private key is stored in /root/root-CA/private. The public key is dropped in /root/root-CA/certs. Listing 3 shows what happens while creating these keys.
Listing 3: Creating a public and private key pair for your server.
Signing the key-pair
You have now created the CA and a key-pair that you need to get signed. If the CA that needs to sign the key would not run on your own server, you would now copy it to the server that does the signing. Since in this simple setup the CA is on the same server, you can sign the CA using the following command:
Make sure that you run this command from the root directory of the certificate authority as well. In this command, the default policy is used for signing the key. The name of this default policy is policy_anything and this is defined as a bunch of settings in the openssl.cnf configuration file. The option -notext is used to limit the amount of output produced by this command.
Then the name of the resulting certificate is given: certs/mailservercert.pem. This certificate can only be created because you created a signing request earlier with the name mailserver_req.pem. This mailserver_req.pem is in the certs directory. If you would need to sign a public key that is generated on another server, you only have to make sure that this public key is copied to this directory; the signing request would find it and the public-key certificate would be created without any problem. Listing 4 shows the output that is generated when signing this certificate:
Listing 4: Signing the certificate that was just created
You have now created the public/private key pair for your mail server and have signed it with your own self-signed root-CA. For more details on how to use the openssl command, check man openssl(1). Also note that all options, such as req and ca, have their own man page; check them for more specific details.
ABOUT THE AUTHOR: Sander van Vugt is an author and independent technical trainer, specializing in Linux. Vugt is also a technical consultant for high-availability clustering and performance optimization and an expert on SUSE Linux Enterprise Desktop 10 (SLED 10) administration.
