Why bother with SSL?

I have to admit, I was a bit skeptical about the need for enabling secure https access to my website. I am not engaging in any ecommerce. I don’t ask anyone for their money or even their opinions. But a friend of mine whose job it is to keep large corporate systems running smoothly and securely convinced me that offering https access may soon become expected from any website visitors. Indeed, I have thoroughly indoctrinated my kids to always look for the https ‘lock’ icon in the browser bar before doing anything on the internet that involves the input of financial information.

Soo.. What do you need to do in order to enable an SSL-capable website?

Purchase an SSL certificate from an SSL provider

The service these SSL providers perform is to act as a trusted third party in a web exchange. You can read about this on this mostly reliable wikipedia article. The short version is that they provide the assurance to someone using your website that you are who you say you are and not some evil hacker lurking in a basement in Belarus stealing credit card information from unwary visitors who think they have logged onto www.mylittlepony.com but are in fact logging onto www.StealYouBlind.com.

There are a number of these third party certificate providers, and the prices they charge you for a certificate are all over the place. Full-on ecommerce sites need a certificate that provides for multiple domain names and variations and all sorts of other fancy stuff that your personal website probably does not need. On the advice of the same friend, I decided to purchase a certificate from GlobeSSL for a not-too-terrible price of $8 per year for the no-frills basic certificate.

Getting the actual certificate is mostly an exercise in answering a series of questions about your identity and then brandishing a credit card to-and-fro until they decide to finalize your certificate after confirming your email address, and probably working out whether the domain owner’s address is in more or less the same zip code as the person purchasing the certificate. Of course, I am being flip here, and they do confirm your identity and your authorization to receive a certificate. Every situation is likely to be different, but at the minimum, make sure you have a live, valid email address attached to your domain registrar so they can confirm your identity.

Download your certificate and keys

The end of all this cloak and dagger stuff will result in your downloading a few files:

domainName_com.crt - this is your certificate

domainName_com.key - this is your private key

domainName_com.csr - this is your request for a key

domainName_com.ca-bundle - this is bundled version of some of previous files

Where domainName_com is your domain’s name and top-level-domain descriptor. In other words, it might be domainName_net or something similar.

Your ssh access and sFTP access should be working on your server. The next step is to copy the files to a temporary spot on your server so you can then invoke superuser powers to install them in the appropriate directories. I suggest copying them to a ~/tmp directory using your sFTP client.

Log in to your server with ssh, and then navigate to your temporary directory. Enter the following sequence of commands:

The next step is to use the intuitive vi editor to modify the ssl.conf file. So fire up the editor in super user mode thusly:sudo vi +/SSLCertificateFile /etc/httpd/conf.d/ssl.conf The cool +/ trick in that command will take your editor cursor right where you need to be. You will need to modify this file by uncommenting the SSLCertificateFile and the SSLCertificateKeyFile lines and adding the names of the files copied from the previous step. It should look like so:

The final step is to stop and then restart the http server. Typing sudo service httpd restart should do the trick quite nicely.

One trick I found when googling around how to do this is that the AMI (Amazon Machine Image) linux installs are based on CentOS. So any how-to google searches probably should begin with CentOS and AMI as search terms. ↩