Securing your site with SSL

I have now implemented SSL a couple of times and each time I attempt an install it feels like I am starting over from scratch with my SSL knowledge.  It can be complicating for a newbie but it is entirely possible for someone with a technical aptitude to achieve.  In this article I describe things to look out for when you are doing work with SSL.

This article assumes that you are working on a Debian Linux installation, but would probably work on Ubuntu and other modern Linux distributions as well.

Generate the Keys

In every article you read you are going to see that same heading.  Keys are the things that keep your privacy, and you must generate them on your own.   In this example my certificate signing authority wanted an AES-256 type of key (that's the type of encryption) so I ran the following command in Debian:

openssl genrsa -aes256 -out personal.key 1024

Update 2011-11-02: new recommended command from my provider: openssl req -nodes -newkey rsa:2048 -keyout personal.key -out personal.csr

As you may have guessed, that creates a file called personal.key.  That's your key!  Keep it safe.  You're probably wanting to do more with it though, because if you go this route you will need to get the certificate signed as well.  If you aren't looking to get a signed key you could alternatively generate a self-signed certificate, but always keep in mind that modern browsers do not like these.  They throw all kinds of errors, security warnings and other messages about your security settings.  So if you want that, go check it out, otherwise let's get that key signed:

openssl req -new -nodes -keyout personal.key -out request.csr

If you're using the italics version above, you can probably skip this step!

In this example you take that key you just created and you generate a signing request.  It wants information - so be honest!  This is your online reputation when someone clicks to view the certificate so make sure it is accurate.

The Waiting Game

After your SSL signing request is ready to go it is time to contract your signing authority.  I have gone to two different ones in the past - a Vancouver company called Omegasphere issues these and I have also signed up for one through Godaddy.  You could buy one from Verisign too, but you will pay a lot more for the privelege.

Once your certificate signing authority gets your request they will do some kind of verification with you and/or your site.  Typically you can pay more for deeper inspection of records.  I'm not sure exactly how that benefits the site owner, but it could make users feel better (provided they understand SSL really well - I'm going to assume most users don't give a F*#$).

All they want is your request.csr file with accurate information.  Be available to respond to their inquiries and requests.  After waiting you should get two new files if your request is approved:

personal.crt
ca-bundle.crt

The file names will certainly differ but the concept is always the same.  You need to install three files when you get into your SSL setup (coming up next, read on!).  First, you need your personal.key.  That has your secret data.  Then you have your personal.crt.  That has your information and signature that says your key is legit.  Lastly, the Certificate Authority Bundle (ca-bundle.crt) is a file that says who vouched for you, and I believe it might also provide a way of authenticating them.  Rest assured, no matter what the case, that last file is about your service provider, not you, but you still need it.

Confirm the Goods

The biggest challenge when you are debugging these files that you just paid for is knowing if you got what you paid for before you spend countless hours trying to force the key into your system(s). I found the solution to this one here, but I'll warn you that the forum is all in French.  Here is a translation.

Run these two commands, they should provide the same answer:

openssl x509 -noout -modulus -in personal.crt | openssl md5
openssl rsa -noout -modulus -in personal.key | openssl md5

Do those look the same?  Good.  Ok, you got what you paid for.

Just in case though, let's do one more test.

openssl x509 -noout -text -in server.crt
openssl rsa -noout -text -in server.key

This one is more complicated.  Check that the exponent is the same.  Typically it is 65537 in most configurations.  So long as you have a match you are gold.

Installing Away

Using Apache2

Installation on Apache2 is "simple" in the sense that there are lots of howto documents out there for you to sink your teeth into.  Sometimes you will chip a tooth.  I took one recommendation and accidentally removed PHP5 while trying to setup SSL.  Be wary of what you copy and paste, it is a mixed bag out there.

Your server will not restart if you do not get this configuration right.  So do it when the sun is not shining.  Also, be sure you checked out the test steps above, they will save you some headaches here.

Enable mod-ssl

Apache2 needs modules to get SSL support configured.  So install it with this command:

a2enmod ssl

Edit ports.conf

You need to enable Port #443 to get SSL in gear.  Update your ports.conf as such:

Listen 80
Listen 443

There, the "Listen 80" line was there so we added a second entry.

Virtual Hosts

This is where virtual hosts get weird.  You need to add the NameVirtualHost directive and define at least one new site.  You can only have one SSL certificate per IP address so start adding some to your account if you intend to run a few different certificates on your server.

NameVirtualHost 127.0.0.5:80
NameVirtualHost 127.0.0.5:443

Be sure to replace 127.0.0.5 with your server's IP address. 

Now define your new site.  Copy your existing virtual host entry and paste it into the same file, making sure to paste it after the end of the primary virtual host.

Now, change your IP address and port in the new entry:

From: 
To: 

Be sure to skip the from/to part that I typed in there, that was just for reference.  You can customize the other settings in here now or come back to it later.  You might want to setup a different log file for SSL errors, for example.

Now, somewhere in the definition of the ssl virtual host add the following lines. 

SSLEngine on
SSLCertificateFile /etc/apache2/personal.crt
SSLCertificateKeyFile /etc/apache2/personal.key
SSLCertificateChainFile /etc/apache2/ca-bundle.crt

Note that you must change the path to these files to match where you have stored them on your system.  As mentioned earlier, if this statement fails your server will not start any more.  You can comment out "SSLEngine on" by putting a # in front of it if you need to get your site back up in a hurry (obviously without SSL).

If you added a password during the setup process you will now need to enter it each time you start Apache2.  It is possible to remove this "feature" if you automate updates and can't predict when your server restarts itself.

For other services

When it comes time to expand your SSL presence beyond Apache2 you can start plugging these three files into your other servers.  You need to keep in mind that the IP address and domain name should be the same as the Apache2 server. 

In my experience certain programs requrie you to change the format of the information to convert it to a PEM file.  This will also probably reduce the number of files you need to install the key, but your mileage may vary.  Ideally, you still want your CA-Bundle in there but sometimes it isn't necessary. 

For Drupal

If you plan on using your SSL certificate with Drupal setup Apache as noted above and then install the Secure Pages Drupal module in your site.  I had to add "user" as one of the paths to encrypt so that visitors know their data is safe.  Otherwise it handled the web side of things quite gracefully.