It seems like any time anyone has to configure a server for SSL/TLS, they treat it like some kind of voodoo magic. And I guess it can seem that way: if you get your certificates in the right formats from your certificate authority, you basically just drop them into Apache/NGINX/whatever and let it go.
But what happens if those files aren’t in the right format by default? And what if you actually want to understand what’s going on with your server?
The truth is, encryption is not terribly difficult to understand. It’s a little tricky to explain, and the maths in the nitty gritty of it can get really intense, but a high level understanding is important for anyone who works with SSL.
The basis for SSL is public-key
(asymmetrical) cryptography. The idea is that you create a pair of files that have matching abilities:
* the “public” file can encrypt content so that the matching “private” file must be used to decrypt it. It can also verify the signature of the “private” file.
* the “private” file can decrypt content that was encrypted by the matching “public” file. It can also leave a unique digital signature which can be verified by the matching “public” file.
If you’ve ever used the PGP encryption
system, that’s basically how it works. You publish your public key in a publicly available directory, and keep your private key to yourself. That way, anyone can use your public key to encrypt content for you, and only you can decrypt it.
In the context of web communications, this model is taken to the next level. We use the encryption aspect of it, but we also use those digital signatures. Here’s the process.
1) You create this “key pair” for yourself, and hide the private key away somewhere. Optionally the private key can be password-protected.
2) You create a Certificate Request file (.CSR, usually). A Certificate Request is just a copy of your Public Key, with some identifying information about your organization. The most important piece of this information is the domain name this Request is for. You submit your CSR file to a Certificate Authority (abbreviated as “CA) company like RapidSSL
, or any number of other Certificate Authorities out there.
3) The CA verifies that you really own the domain name specified in the CSR. How they verify that is up to the CA. Maybe they email the owner of the domain, maybe they ask you to modify a DNS record, maybe they just take you on your word (hopefully not!). Whatever they do, when the CA is satisfied that you really do own that domain name, they send you back your Certificate Request file. This version of the file is signed by the CA’s own private key, and that difference makes it the actual “SSL certificate” file. If you’ve been keeping score at home, the SSL certificate is simply your public key with your organizational information attached, and your CA’s signature.
Great, now people can send you encrypted messages, right? Well, sorta. How do people know they can trust the CA? Maybe that CA is just some yahoo who lives up the hall, or your great aunt Edna. How can I trust Edna to vouch for you?
4) The solution is a “chain of authority” file. This is just your CA’s public key (which the browser needs to check that signature on your SSL certificate, remember?). What makes this public key special is that it’s ALSO signed by whoever granted your CA permission to be a CA, and by whoever granted THAT person the permission to be a CA, all the way back to one of the “root” certificate authorities, whose public keys are bundled with every browser. (there are about 30 of them). So the chain file from aunt Edna might contain signatures from her daughter Annie, Annie’s company AnnieCA, and GeoTrust, who granted AnnieCA the authority to give out certificates. GeoTrust is a root CA, so your browser already knows they’re trusted.
So when a web browser connects to your server, your server sends out its SSL certificate file (ie the server’s public key with Edna’s “Seal of Authenticity” on it). The browser can then encrypt communications to send to your server, and your server can decrypt them with its private key. The browser can also check on Edna’s Seal of Authenticity, because there’s a chain of other CAs who have signed Edna’s certificate, right back to one of the CAs that the browser already trusts.
With a one-way secure channel open, and with confidence that your server really does own that public key, the browser sends its own public key to the server. This is really as far as you need to understand in order to set up your own webserver. Once the server and browser have exchanged public keys, the rest is automatic. For the sake of completion in this blog post, you should know that they don’t continue using this asymmetric encryption for long. This secure channel is only used to set up a symmetric encryption method - that is, an encryption method where both sides have identical keys for encryption and decryption. The actual content is sent over this symmetrically encrypted connection, because symmetrical encryption is lighter on the CPU and the data overhead, and is actually harder to break.
All we sysadmins really care about is the handshake, because that’s where all those confusing key files go. So, TL;DR time. Here’s what you need:
1) Your server’s private key file. Note that this can be encrypted with a password, but most web hosts would rather you not. If there’s a password, someone has to enter it every time they restart the server!
2) The SSL Certificate, signed by your Certificate Authority.
3) Your Certificate Authority’s chain of intermediate certificates.
Most (Drupal-centric) web hosts will want all of these in PEM format. PEM is a text format, which means you can just copy and paste the key around. If your certificates are in another format, it’s pretty easy to convert them to PEM with the openssl command, like this:
openssl <old-cert-format> -in old-cert-file -out new-cert-file.pem
There are also a handful of options that can come in handy in specifying the output, but they really go beyond the scope of this blog post. The resource I always use is the CERN openSSL conversions cheat sheet