Anyone operating a server on any scale should want a digital certificate to encrypt data between clients and services, whether for personal, office, or public use. That's a broad statement, but it holds true no matter how you slice it.

With so many people accessing networks over WiFi or other untrusted networks for an increasing number of different kinds of services—calendars, contacts, Webmail, email, and so on—encryption is a must, whether via a VPN or by securing services one by one. While I recommend VPNs, they aren't always the practical, affordable, or correct solution. For remote email access, SSL/TLS is simpler and more straightforward, and you don't have to compromise on protection in the process.

There can be something technically imposing about getting and installing a digital certificate, even though it has a high utility value, so I'm here to make it easier by breaking it down into steps that someone without encryption and command-line knowledge should be able to work with.

I'll start with an explanation of how digital certificates create encrypted sessions. Then I'll describe how to get a free certificate from StartCom as a simple case, before giving a few examples of how to install your certificates.

Secret handshakes

A digital certificate comes in the form of server-side TLS certificate. TLS stands for transport layer security, and in common use it's a method of combining the advantages of public-key cryptography, external third-party (out-of-band) validation, and per-session encryption.

(TLS is the modern name for SSL, the preceding standard. This method is sometimes called SSL/TLS to signal to people who know the older name that it's the same thing; here, let's just call it TLS.)

Public-key cryptography lets one party send information to another, hidden by a public key that can be freely distributed. The receiving party has a private key which is kept strictly secret, and which is the only component which may extract the original message from the public-key-encrypted payload.

Public keys are unwieldy for encrypting long strings of text and for fast encryption of streams of data, such as files being transferred via email or website transactions. Philip Zimmermann created PGP in 1991 as a way around this. The public key transaction is used to exchange a strong session key that's symmetric: both parties use the same key to encrypt and decrypt data. The key is passed in perfect security via the public-key transaction, making the process impenetrable to sniffers and "man in the middle" attacks.

Certificates can be generated for domain names and other data by pretty much anyone; the party generating the certificate doesn't have to be the legitimate owner of the domain or data. So, just as with PGP and the open-source GPG alternative (and SSH and many other similar methods), you need an out-of-band method to validate that party issuing the certificate is really who they say they are.

That's where certificate authorities (CAs) come in. A CA is a group that provides some validation, from cursory to extensive (in the case of Extended Validation certificates), that the party that signed up for a certificate for a given domain name is approximately that entity.

When you connect via a browser to a secure website, for instance, the browser does some handshaking with the server, receives a certificate which contains a public key and some other fielded data, and then turns to a CA to confirm that the certificate is valid.

CAs are preinstalled in browsers, client software, and operating systems, so that the CA itself is validated by the software developer or OS maker. That's where the out-of-band trust comes for the CA!

Firefox alerts you when StartSSL asks for a personal certificate with which to authenticate yourself.

If the browser is mathematically convinced that the certificate is from a valid party for that domain, a key is exchanged, and a session is encrypted.

You can sign your own digital certificates, essentially acting as your own certificate authority, but that's a problem. Because a client and/or OS doesn't know that GlennFleishmanCA is a real authority, the client or OS has to prompt a user to accept an untrusted relationship. Depending on the process, the user may be able to trust a session or not, or to accept a CA's authority permanently.

In an organization, a self-signed cert can work because you can either tell everyone to accept the signing certificate's authority, or you can preinstall the root authority for your own CA in each person's computer. (That can be as simple as dragging a file into a system-wide key manager, clicking import and importing it, or clicking through a couple of dialog boxes.)

But instead of all that tedium and management, especially as new employees or colleagues come and go, it makes more sense to get a fully CA-validated certificate. And you can get one for free.

Start with StartSSL

StartCom's StartSSL service offers a Class 1 certificate at no cost, with fees for higher levels of identity validation (see the site's chart for comparisons). A basic Class 1 certificate doesn't validate all your details; email to a known domain contact address is the only real check. A Class 2 or 3 certificate with your identity or your organization's identity is $40 for two years. An extended validation certificate, which uses an industry standard for checking a submitter's details, is $110 for two years, and will tell a browser to show a green bar on connection.

While StartSSL is free, it isn't a clear process to those that haven't created a certificate before. Let me tell you how to walk through the site.

StartSSL uses an S/MIME personal certificate to let you log in after sign-up. This is certainly more complicated than requiring a username and a password, but it's ostensibly much more reliable because you have to have this cert, which can't be intercepted over a network or captured through keystroke monitoring. Direct access to someone's computer, likely with additional passwords, would be required to access it. (After creating the S/MIME certificate, you can use it to sign emails in programs that support S/MIME.)

(Note: Safari 4 under Mac OS X doesn't correctly interact with StartSSL's site for certificate download, validation, or menu selection. Use Firefox in Mac OS X or Firefox or Internet Explorer under Windows instead.)

Firefox manages personal certificates in its Preferences window under Advanced > Encryption > Your Certificates

Start at the Authenticate or Sign-Up page. Click Sign-up. Fill out the Personal Enrollment details and click Continue. (StartTLS offers many imprecations against trying to falsify data here.) Check the email account for the address you provided in step 3, get the validation code, and enter it, clicking Continue to proceed. Next, StartSSL will generate the private key needed for the client certificate it provides to you for authentication. There's no good reason to choose anything but 2048 (High Grade) as the option. Click Continue. Click Install when the Install button appears. This should be an automatic background process. In Firefox, the certificate is installed into an internal database, from which it can be exported. (If you want to use these credentials with another browser, you can download them again from within the StartSSL website, or you can export the certificate from Firefox and drag into or import into another browser on the same or a different computer.) Click Finish, and you're taken to an authenticated control panel page.

This S/MIME cert is vital to using the site again, so you should back up the certificate. In Firefox, via the Advanced preference's Encryption tab, you can export a certificate by selecting View Certificates, choosing the StartCom certificate from the Your Certificates tab, and clicking Backup. After setting a mandatory password and exporting the certificate, it can be imported into other programs that read the certificate format. See answer 4 in the FAQ for Internet Explorer export.