SSL Certificate Management

In practice, any TLS or SSL encrypted communication requires that the server (e.g., web server or mail server) have an X.509 certificate.

Background

If a user wants to connect to a web server or a mail server and just wants all traffic between them to be encrypted, there is no direct need for any certificates at all. A simple symmetric-key encryption scheme (where the sender and receiver use the same key) like DES or RC4 is sufficient.

But how do the web server and web browser agree on a secret key to use without risking having an eavesdropper steal it and then be able to read their private messages? This is one of the situations where public key encryption is of great use.

Public Key Encryption

Public key encryption uses "key pairs", where one key is called the "private" key, held in secret by only the entity who generated the key pair, and the other is call the "public" key, which the entity who generated the key pair provides, openly, to anyone who wants it. Both keys can be used for encoding data, but after the data is encoded, only the other key can decode it. Namely, if some text is encoded using the public key of a key pair, the private key is needed to convert the encoded text back to the original. This is the public key mechanism for "encryption". And likewise, if some text is encoded using the private key of a key pair, the public key is needed to convert the encoded text back to the original. This is the public key mechanism for "authentication" or "digital signatures".

In more practical terms, when sending a message, if the sender wants to encrypt it, they encode it using the recipient's public key. Then only the recipient will be able to decode the message because no one else has the recipient's private key.

And if the sender wants to sign a message, they encode it using their own private key. Anyone can read that message and verify the signature beause everyone has access to the sender's public key, but no one can alter the message without destroying the signature because no one else has the sender's private key that is needed to create the signature.

And, of course, messages can be both encrypted and signed at the same time.

Certificates

A certificate is, in a very general sense, a document that identifies an entity in a way that is (theoretically) impossible for any other entity to impersonate and where that identification is marked (or signed) by another (trusted) entity in a way that the document cannot be altered without destroying the signature and that the signature cannot (theoretically) be counterfeited. The certificate is said to be "issued to" the entity that is being identified and "issued by" the (trusted) entity that signed the certificate. The entity issuing the certificate is also called the Certificate Authority (a.k.a., CA) or Trusted Third Party.

For example, a driver's license is a certificate. The picture on the license identifies the person--the entity to whom the license was issued--and it is marked (signed) with graphics and watermarks and a magnetic strip that only the state--the entity who issued the license--is able to make. Another person would not be able to impersonate the person to whom the driver's license was issued because they wouldn't look exactly like the person in the picture, the picture can't be altered without destroying the license, and no one other than the state can make licenses that have those exact same graphics and watermarks. Obviously, none of these statements are strictly true in the case of the driver's license, but the idea behind the construction of the driver's license fits the criteria for its being a certificate.

The idea behind certificates, in general, is that they delegate some limited sense of trust to the entity to whom the certificate was issued. Of course, that only has value if you already trust the entity who issued the certificate. For example, if someone presents you with their driver's license, you can trust that that person is probably a competent driver because only the state could have issued a document like that and the state wouldn't have issued it to someone whose driving ability hadn't been tested. Or, if you go to a secure website that has a certificate issued by Verisign, a commercial CA, you can trust that the company behind the website is a legitimate company with a known address, information that you (or a law enforcement agency) could obtain from Verisign if you needed to.

Digital Certificates

A (digital) certificate is a file that contains the issuee's public key, signed by the issuer's private key. No one can impersonate the issuee because no one else has the issuee's private key, and no one can alter the certificate without destroying the signature because no one else has the issuer's private key. Of course, this certainty depends on the private keys remaining secure. (And on the strength of the public key encryption scheme used. The strength of RSA encryption, the public key encryption scheme used most commonly in SSL, depends on the relative difficulty of factoring large numbers, a long standing mathematical belief.)

So, implicit in any discussion of certificates is that associated with every certificate, but not ever revealed, are the private key of the issuee (know only to the issuee) and the private key of the issuer (known only to the issuer).

To create a certificate, the issuee creates a "certificate signing request" which is a file that contains the issuee's public key and some identifying information, like name, organization, and country, that is signed by the issuee's own private key. The issuee then sends that "certificate signing request" to the issuer, who signs it with the issuer's own private key, producing the certificate. The issuer must verify the facts that they are certifiying about the issuee before signing the certificate signing request. For example, the state needs to verify that a person can, indeed, drive before creating issuing them a license, and Verisign must verify that a company requesting an SSL certificate is legally doing business at a known address before issuing them a certificate.

In practice, public key encryption is very computationally expensive

all that it required is that both the user and the server each have public-private key pairs. One of the most common reasons for wanting secure transactions on the web, thought, is to protect credit card information. But besides wanting their credit card information to be encrypted to prevent any eavedroppers from getting it, they also want to know that the company to whom they are sending their credit card information can be trusted. If the website where they are sending their credit card information has a certificate signed by one of the commercial CAs (trusted third parties), then the user can be more confident that the owner of the website can be trusted--or at least, be tracked down if they do steal the user's money.

Certificate Authorities (CA) and Self-signed Certificates

Certificate Authorities, themselves, also have certificates that can be signed by other, even more trusted CAs. But obviously, this chain of trust must stop somewhere, at some inherently trusted authority. If a CA is inherently trusted, it is called a "root" CA. They, too, have certificates, but their certificates are "self-signed".

What? I thought certificates were supposed to transmit some level of trust from the issuer to the issuee, but what good is that if the issuer and issuee are the same entity? That's true, a self-signed certificate doesn't have any more value than just the bare public key of the issuer/issuee. But the "root" CAs are made to also be represented by certificates just to keep file formats and all consistent.

Procedures

All the SSL libraries and support programs are contained in the openssl package. That package contains the program, openssl, that is used for all ssl key and certificate creation and management.

File Locations and Security

The Debian package, openssl, includes the directories, /etc/ssl/certs and /etc/ssl/private, which are meant to contain the certificate files and the key files, respectively. I also created the directory, /etc/ssl/reqs, for storing Certificate Signing Requests. The server doesn't actually need these, and once the certificate itself is generated from the request, it is not important to keep them anyway. For completeness sake, however, it is nice to keep a record of the Certificate Signing Requests.

The key files (in /etc/ssl/private) should be readable only by root and, possibly, the users under which the servers (that use ssl) run (e.g., postfix and cyrus). These files should never be transmitted over a network. They can be protected by passphrases, but that is a secondary line of defense in case someone breaks in and steals one of them. The key files should be treated as if they, themselves, are the "passwords". And in practice, server key files usually have no passphrase; otherwise, the services (e.g., web and mail) wouldn't be able to start up automatically. (If the server's key file has a passphrase, you would need to enter it every time you wanted to start each ssl service.)

The Certificate Signing Requests and the certificates themselves can (and possibly should) be world readable, and they can be transmitted safely over unsecure channels. They contain no information that could grant access to anything not already accessible.

Creating a Certificate Signing Request

This should be done on the server where the certificate will be installed because that is where its corresponding key file is. For example, to create a certificate signing request for mail.astro.columbia.edu on sedna (assuming you already have a key file), run the following command:

openssl req -new -key /etc/ssl/private/mail.astro.columbia.edu.pem -out /etc/ssl/reqs/mail.astro.columbia.edu.csr

If there is a passphrase on the key file (/etc/ssl/private/mail.astro.columbia.edu.pem), it will ask you for that. It will then ask you a series of questions which you need to answer:

Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Columbia University Astrophysics Laboratory
Organizational Unit Name (eg, section) []:services
Common Name (eg, YOUR name) []:mail.astro.columbia.edu
Email Address []:security@astro.columbia.edu

That will create the certificate signing request file, /etc/ssl/reqs/mail.astro.columbia.edu.csr, which you can examine with the command:

openssl req -noout -text -in /etc/ssl/reqs/mail.astro.columbia.edu.csr

You can send that request file to a commercial Certifying Authority (CA) (e.g., Verisign, Equifax, etc.) where they will create a certificate for you and send it back. The cheapest certificate, good for one year, costs around $300. Or if you have your own CA, you can transfer the Certificate Signing Request to the computer where you keep the CA key and sign it there yourself. That process is described in the next section, Signing a Request with Your Own CA. As mentioned earlier, it is perfectly safe to transfer both the Certificate Signing Request and the Certificate itself through an insecure channel, like email.

Installing the Certificate

Once you get back the signed Certificate file (whether through a commercial CA or your own), install it in:

/etc/ssl/certs/mail.astro.columbia.edu-cert.pem

If this is a certificate renewal, you may want to rename the old certificate so that you don't overwrite the old one with the new one.

You can check the contents of the certificate with:

openssl x509 -noout -text -in /etc/ssl/certs/mail.astro.columbia.edu-cert.pem

You will need to restart all the servers that use the certificate. For example on sedna, run:

/etc/init.d/postfix restart
/etc/init.d/cyrus21 restart
/etc/init.d/apache2 restart

Signing a Request with Your Own CA

To sign a Certificate Signing Request, you need to gather the Certificate Signing Request file (mail.astro.columbia.edu.csr), the CA Certificate file (CAL-CA_root_cert.crt, which can be found in /usr/share/ca-certificates/cal/CAL-CA_root_cert.crt on any CW) and the CA Certificate key file (cacert.key) and its passphrase. Switch into some working directory and place all those files there. Then run the following commands:

mkdir demoCA
touch demoCA/index.txt
echo "07" > demoCA/serial
mkdir demoCA/newcerts

This creates directories and files that are refered to in the default openssl config file, /usr/lib/ssl/openssl.cnf. (Alternatively, you could alter the config file to specify different directories and filenames.)

The file, serial, contains the "serial number" that will go in the certificate. It should just be a text file that contains a hexadecimal number. Normally, you would increment that every time you renewed any certificate. To see the serial number on the previous certificate, enter:

openssl x509 -noout -text -in mail.astro.columbia.edu-cert.pem.old

where mail.astro.columbia.edu-cert.pem.old is the old certificate file. Include the full path if it is not in the current directory. Note that the serial number needs to be unique among all certificates certified by that CA, not just among all certificates certified by that CA with the same Common Name (CN).

When all the files are in place, run the following command:

openssl ca -in mail.astro.columbia.edu.csr -out mail.astro.columbia.edu-cert.pem -cert CAL-CA_root_cert.crt -keyfile cacert.key

That will create your new certificate, mail.astro.columbia.edu-cert.pem, good for one year, which you can install according to the directions in the Installing the Certificate section.

Certificates Certified by the CAL CA

terra.astro.columbia.edu

This certificate is used for TLS connections to the LDAP server.

Server: terra
Path to Certificate: /etc/ldap/slapd.cert
Path to Key File: /etc/ldap/slapd.key
Valid: 07/13/2010 16:54:05 GMT - 07/23/2011 16:54:05 GMT
Serial Number: 0x1c
Subject: C=US, ST=New York, O=Columbia University Astrophysics Laboratory, CN=terra.astro.columbia.edu/emailAddress=security@astro.columbia.edu

mars.astro.columbia.edu

This certificate is used for TLS connections to the LDAP server.

Server: mars
Path to Certificate: /etc/ldap/slapd.cert
Path to Key File: /etc/ldap/slapd.key
Valid: 2/8/2011 18:44:13 GMT - 2/8/2012 18:44:13 GMT
Serial Number: 0x1E
Subject: C=US, ST=New York, O=Columbia University Astrophysics Laboratory, CN=mars.astro.columbia.edu/emailAddress=security@astro.columbia.edu

mail.astro.columbia.edu

This certificate is used for SSL/TLS connections to the mail server and HTTPS connections to webmail.

Server: sedna
Path to Certificate: /etc/ssl/certs/mail.astro.columbia.edu-cert.pem
Path to Key File: /etc/ssl/private/mail.astro.columbia.edu.pem
Valid: 07/13/2011 16:28:37 GMT - 07/12/2012 16:28:37 GMT
Serial Number: 0x1f
Subject: C=US, ST=New York, O=Columbia University Astrophysics Laboratory, OU=services, CN=mail.astro.columbia.edu, E=security@astro.columbia.edu

webmail.astro.columbia.edu

This certificate is used for HTTPS connections to webmail.

Server: neptune
Path to Certificate: /etc/ssl/certs/webmail.astro.columbia.edu.crt
Path to Key File: /etc/ssl/private/webmail.astro.columbia.edu.key
Valid: 07/13/2010 16:29:30 GMT - 07/23/2011 16:29:30 GMT
Serial Number: 0x1b
Subject: C=US, ST=New York, O=Columbia University Astrophysics Laboratory, CN=webmail.astro.columbia.edu, E=security@astro.columbia.edu

docs.astro.columbia.edu

This certificate is used for HTTPS connections to the wiki.

Server: uranus
Path to Certificate: /etc/ssl/certs/docs.astro.columbia.edu-cert.pem
Path to Key File: /etc/ssl/private/docs.astro.columbia.edu.pem
Valid: 2/8/2011 18:23:51 GMT - 2/8/2012 18:23:51 GMT
Serial Number: 0x1D
Subject: C=US, ST=New York, O=Columbia University Astrophysics Laboratory, CN=docs.astro.columbia.edu/emailAddress=security@astro.columbia.edu

bee.astro.columbia.edu

This certificate is used for HTTPS connections to the printer bee.

Server: bee
Valid: 1/17/07 20:53:47 GMT - 1/17/08 20:53:47 GMT
Serial Number: 0C
Subject: CN=bee.astro.columbia.edu, L=New York, ST=New York, C=us, O=Columbia University, OU=0017088B3F32, OU=J7949E, OU=Astrophysics Laboratory

cricket.astro.columbia.edu

This certificate is used for HTTPS connections to the printer cricket.

Server: cricket
Valid: 01/16/2008 21:48:53 GMT - 01/15/2009 21:48:53 GMT
Serial Number: 10
Subject: C=US, ST=New York, O=Columbia University Astrophysics Laboratory, OU=001438DB599E, OU=J7949E, CN=cricket.astro.columbia.edu