|
|
|
C Creating self signed SSL Certificates Using Openssl
Requirements apache2, openssl and
Install openssl and
Staring SetupFirst, we will create a directory where we can work. It does not matter where this is; I am arbitrarily going to create it in my home directory.
The certificate directory will contain: Our Certificate Authority (CA) certificate The database of the certificates that we have signed The keys, requests, and certificates we generate It will also be our working directory when creating or signing certificates. The certificates/newcerts directory will contain: A copy of each certificate we sign The Certificate/private directory will contain: Our Certificate private key This key is important: Do not lose this key. Without it, you will not be able to sign or renew any certificates. Do not disclose this key to anyone Our next step is to create a database for the certificates we will sign:
Rather than use the configuration file that comes with OpenSSL, we are going to create a minimal configuration of our own in this directory. Start your editor (vi, nano, ...) and create a basic openssl.cnf:
Creating a Root CertificateWith OpenSSL, a large part of what goes into a certificate depends on the contents of the configuration file, rather than the command line. This is a good thing, because there is a lot to specify. The configuration file is divided into sections, which are selectively read and processed according to openssl command line arguments. Sections can include one or more other sections by referring to them, which helps to make the configuration file more modular. A name in square brackets (e.g. " req ") starts each section. We now need to add the section that controls how certificates are created, and a section to define the type of certificate to create. The first thing we need to specify is the Distinguished Name. This is the text that identifies the owner of the certificate when it is viewed. It is not directly referenced in the configuration file, but is included into the section processed when certificate requests are created. The command is "openssl req ", so the section is titled req . Add the following to openssl.cnf:
Run the command as shown. In this case, the PEM pass phrase it asks for is a new one, which you must enter twice:
This process produces two files as output: A private key in private/cakey.pem A root CA certificate in cacert.pem cacert.pem is the file you want to distribute to your clients. We can query the contents of this certificate with openssl to learn to whom belongs, what it is valid for, etc.
Creating a Certificate Signing Request (CSR) Now that we have a root certificate, we can create any number of certificates for installation into our SSL applications such as https, spop, or simap. The procedure involves creating a private key and certificate request, and then signing the request to generate the certificate. Our configuration file needs some more definitions for creating non-CA certificates. Add the following at the end of the file:
Organizational Unit: a reminder of what the certificate is for Email Address: the postmaster Common Name: the server hostname The Common Name must be (or the IP address must resolve to) the server name your clients use to contact your host. If this does not match, every time they connect your clients will get a message asking them if they want to use this server. In effect, the client software is saying, "Warning! You asked for mail.example.com; the responding machine's certificate is for smtp.example.com. Are you sure you want to continue?"
Organizational
Unit Name (department, division) :Mail Server Email Address
:postmaster@example.com This process produces two files as output: A private key in key.pem A certificate signing request in req.pem These files should be kept. When the certificate you are about to create expires, the request can be used again to create a new certificate with a new expiry date. The private key is of course necessary for SSL encryption. When you save these files, meaningful names will help; for example, smtpserver.key.pem and smtpserver.req.pem. We can view the contents to make sure our request is correct:
Signing a CertificateNow we need to add the configuration file section that deals with being a Certificate Authority. This section will identify the paths to the various pieces, such as the database, the CA certificate, and the private key. It also provides some basic default values. Insert the following into openssl.cnf just before the req section:
To sign the request we made in the previous step, execute the following and respond to the prompts. Note that you are asked for the PEM passphrase selected earlier:
This process updates the CA database, and produces two files as output: A certificate in cert.pem A copy of the certificate in newcerts/.pem We can inspect the certificate using the following command
The certificate has both the encoded and a human-readable versions in the same file. You can strip off the human-readable portion as follows:
Installing the Certificate and KeyThis depends on the application. Some want the key and the certificate in the same file, and others want them separately. Combining them is easily done with:
After this step, you have three installable components to choose from:
Copy the appropriate files into the locations specified by the instructions for your application and system. Restart the applications, and you are in operation with your new certificate. Apache Apache has separate configuration directives for the key and the certificate, so we keep each in its own file. These files should be kept outside of the DocumentRoot subtree, so a reasonable directory structure might be:
Within the directive for the site (which of course should be on port 443), include the directives that point to these files:
Stunnel stunnel is used as an SSL wrapper for normal non-secure services such as IMAP and POP. It accepts as arguments (among other things) the service to execute, and the location of the certificate and private key. The key and the certificate are provided in the same file. These can go anywhere, but a good location might be /etc/ssl/certs. Specify it on the stunnel command line as follows: stunnel -p /etc/ssl/certs/key-cert.pem Distributing the CA CertificateThis is the step that stops the clients from complaining about untrusted certificates. Send cacert.pem to anyone who is going to use your secure servers, so they can install it in their browsers, mail clients, et cetera as a root certificate. Renewing CertificatesYour certificate chain can break due to certificate expiry in two ways: The certificates you signed with your root certificate have expired. Your root certificate itself has expired. In the second case, you have some work to do. A new root CA certificate must be created and distributed, and then your existing certificates must be recreated or re-signed. In the first case, you have two options. You can either generate new certificate signing requests and sign them as described above, or (if you kept them) you can re-sign the original requests. In either case, the old certificates must be revoked, and then the new certificates signed and installed into your secure applications as described earlier. You cannot issue two certificates with the same Common Name, which is why the expired certificates must be revoked. The certificate is in the newcerts directory; you can determine its filename by browsing index.txt and searching for the Common Name (CN) on it. The filename is the index plus the extension ".pem", for example "02.pem". To revoke a certificate:
You should be able to see the following screen
Now that the certificate has been revoked, you can re-sign the original request, or create and sign a new one as described above. |