To download these tutorials for OFFLINE viewing or for archive purposes please (Click here to download)
(Clicking the “.zip” will open the Archive, un-zip the .mht files then use one of the plugins below to view them)
You can open .mht WebArchive files directly inside FireFox Or Google Chrome by installing a plugin
How to obtain and install an SSL/TLS certificate, for free
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.
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!
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.)
- 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.
In Mac OS X, you can add the certificate securely to Keychain Access (Applications > Utilities). Enter the password after dragging the backup file into Keychain Access, and it’s now stored (and available to programs that support keychain-stored certificates).
In the control panel, you need to validate yourself in two ways to generate a certificate.
- Click the Validations Wizard tab to get started. (If you get an error at this point, check that your S/MIME certificate was correctly installed.)
- Select Email Address Validation and click Continue.
- Enter an email address and then click Continue. You have 15 minutes to retrieve and enter the validation code sent to that address.
- Enter the code and click Continue.
- If successful, you’ll see a Validation Success message, at which point you can click Finish.
Now, validate yourself for a domain.
- Click the Validations Wizard tab.
- Select Domain Name from the popup menu, and click Continue.
- Enter a domain name in one of the top-level domains that StartSSL supports as a domain plus top-level suffix. Click Continue.
- The site looks up the registration or whois record for the domain, and then asks you to select an email in that record to send a verification request to, as well as postmaster@, hostmaster@, or webmaster@ the same domain. Select the email you want to use, and click Continue.
- Check your email, get and enter the verification code, and click Continue.
You can now create a certificate for this domain:
- Click the Certificates Wizard.
- From the Certificate Target menu, choose Web Server SSL/TLS Certificate, and then click Continue.
- To avoid having to use terminal commands, I recommend choosing a password at this step. Enter the Key Password and type the same password in Confirm Password. Leave the Keysize at 2048 (Medium). Click Continue. (If you know how to create a certificate signing request or CSR, you can follow the alternate path by clicking skip and entering the CSR in the next field.)
- The Save Private Key page shows a generated, encrypted private key that’s part of what a server needs to manage TLS connections. Copy and paste the contents into a text file. You need to protect your private key as if your security depends on it—it does! Click Continue.
- Select the validated domain from the Domain pop-up menu that you want to generate a certificate for, and click Continue.
- Enter a subdomain or host name, such as “secure” or even “www” to use to associate the certificate with a specific fully qualified domain name. Click Continue.
- The next step creates a certificate request, which can be useful if you need to regenerate the certificate later, but you can typically ignore, and click Continue.
- Finally, the certificate is generated, which you can copy out of the Save Certificate screen, and save in a file such as ssl.crt. (I recommend naming it descriptively, like secure_example_com.crt.)
- Click Finish.
Now you have three files you will need to set up TLS on a server.
- The private key file, which is encrypted by default and should be protected at all costs from anyone gaining access to it. (Set permissions in whatever way is available to read-only by the owner, and no access to any other system user; chmod 0400 under Unix, for instance.)
- The certificate file, which contains the public key and other data and is fed out to clients to initiate a secure session.
- The intermediate file, which links the CA used by StartCom to generate this certificate to a higher-level CA that works with all browsers and operating systems. You download this file as a bundle from the Tool Box tab, clicking SmartCom CA Certificates, and then right-clicking the Class 1 Intermediate Server CA to save it as a standalone file. (StartCom is a valid CA, but this intermediate certificate assures that all clients will correctly validate its status.)
The encrypted private key can be used directly with many server configurations, but it’s more likely that you will want a decrypted version that’s protected by the server software or other components that you work with.
You can decrypt the key by clicking the Tool Box tab, then the Decrypt Private Key link. Paste the private key into the main text area, and then enter the password you set for that key. Click Decrypt. You can then select and copy the key out from the Save Decrypted Key field that appears.
If you like the command line, you can save the private key to a file named, for instance, ssl.key, and use this command:
openssl rsa -in ssl.key -out decrypted.ssl.key
Enter the password you set when prompted, and the decrypted.ssl.key file will have the private key you need.
Now, let’s install!
Choose a location on your server where you can store the three files above, naming the files descriptively. The private key and certificate files will be particular to each TLS certificate you set up, and I tend to use the domain name as I noted above: secure_example_com.key and secure_example_com.crt.
For an Apache configuration under any operating system, you need to have all the SSL/TLS settings already in place, which you can get from a model SSL file that’s included with Apache. The key items to change or add for a server are just three lines that should come after the line that says SSLEngine on.
SSLCertificateFile /path/to/file/secure_example_com.crt SSLCertificateKeyFile /path/to/file/secure_example_com.key SSLCertificateChainFile /path/to/file/sub.class1.server.ca.pem
Now you can restart the server and attempt a secure connection to the server’s secure address. Using your browser, click whatever lock icon (lower right for Firefox) that lets you view certificate information, and confirm that your just-created certificate is what’s being fed out.
StartSSL has more configuration details in its installation guide, which also describes using the certificate with other Web servers.
Many other servers can use SSL certificates, with configuration typically involving the three files noted earlier, referencing them correctly through a GUI or a text configuration file.
I’d like to call out Mac OS X 10.6 Server, which I’ve begun using, for having one of the nicest approaches to importing certificates through its Server Preferences tool (used on a server) or Server Admin (used on a server or remotely for advanced configuration).
From Server Admin, after connecting to a server, you click the Certificates tab, and then choose Import a Certificate Identity from the + pop-down menu.
This is a drag-and-drop affair, remarkably. You drag your key, certificate, and chain certificates into the dialog box.
It automatically recognizes and interprets them. Click Import, and the certificate is now ready to use.
Throughout Mac OS X Server, you can apply SSL/TLS settings against services that allow those methods. For instance, to create a secure website, you click the Web service in the Server Admin sidebar, click sites, and click the + sign. Set the Port to 443 for security in the General tab, and, in the security tab, check Enable Secure Sockets Layer (SSL) [sic!], and choose the certificate you just imported. Click Save, and the secure server is up and running.
There are a lot of steps up there, but most of them are just required once through, or get easier with practice. The value of a TLS certificate far outweighs the hassle. By encrypting data as it flows among user and services, you can bypass the requirement and cost of a VPN for many common purposes, while preventing snoopers at coffeeshops and elsewhere from having their way with your data—and your company’s.