Setting Up HTTPS Is Cheap And Not Too Hard

Introduction

When I advocate that people use HTTPS for their web sites, I get a lot of pushback, usually along these lines:

I am going to address the first 2 points in this article. To find out if setting up HTTPS is too difficult or expensive, I found a domain name I had already bought but had not set up a web server for, and stood up an HTTPS server for it from scratch.

I decided to use Amazon EC2 to get a virtual server, to use Apache as my web server software (just because I am familiar with it), and sslmate.com as my X.509 certificate provider. Here is my tale.

Step 0: Buy a domain

I had already bought nonfreesoftware.org from register.com. Their prices: 1 year: $38, 2 years: $70, 3 years: $79. I bought it for 1 year.

Step 1: Get a virtual server

Start time: 11:15 20 Aug 2014.

I had to create an Amazon AWS account before I could rent an EC2 instance. I did so, and then started up a t2.micro Ubuntu 14.04 instance. I created a new security group to allow SSH, HTTP, and HTTPS from anywhere on the internet.

Step 2: Install Apache

I created an SSH key for the instance, logged in, and installed Apache.

~ # apt-get install apache2

Step 3: Set up DNS

Now that I had an IP address from Amazon, I set the A records for nonfreesoftware.org and www.nonfreesoftware.org to point to my IP.

Step 4: Set up an sslmate.com account

On the web site, I created an account.

Then I tried to install the sslmate client software on my EC2 instance using the .deb for Ubuntu 14.04, as documented at https://sslmate.com/help#install, but I got this error:

E: Release file for
http://packages.sslmate.com/ubuntu/dists/trusty/InRelease is expired (invalid
since 41d 3h 58min 21s). Updates for this repository will not be applied.

So, I sent this message to sslmate.com’s tech support using the form on the web site:

Trying to install the .deb for Ubuntu 14.04, I get:
~ # apt-get update
[...]
Get:7 http://packages.sslmate.com trusty InRelease [5,357 B]
E: Release file for http://packages.sslmate.com/ubuntu/dists/trusty/InRelease is expired (invalid since 41d 3h 58min 21s). Updates for this repository will not be applied.

Tried to change the URL in /etc/apt/sources.list.d/sslmate.list to https://, and got this warning:

W: Failed to fetch https://packages.sslmate.com/ubuntu/dists/trusty/main/binary-amd64/Packages gnutls_handshake() warning: The server name sent was not recognized

Time: 11:46. Took a break.

Started again at 11:55. I decided to try installing sslmate via npm, as the web site also suggests. npm and its dependencies are a 127 MB install, including the GCC compiler. Yikes. Oh well.

~ # apt-get install npm
[...]
~ # npm install sslmate
npm http GET https://registry.npmjs.org/sslmate
npm http 200 https://registry.npmjs.org/sslmate
npm http GET https://registry.npmjs.org/sslmate/-/sslmate-0.1.4.tgz
npm http 200 https://registry.npmjs.org/sslmate/-/sslmate-0.1.4.tgz
sslmate@0.1.4 node_modules/sslmate

Since that worked, I decided to try buying a certificate for 1 year ($15.95).

~ # sslmate buy www.nonfreesoftware.org 1
sslmate: command not found
~ # find / -name '*sslmate*'
/etc/apt/sources.list.d/sslmate.list
/etc/apt/trusted.gpg.d/sslmate.gpg
/var/lib/apt/lists/partial/packages.sslmate.com_ubuntu_dists_trusty_InRelease.reverify
/home/ubuntu/node_modules/sslmate
/home/ubuntu/node_modules/sslmate/bin/sslmate
/home/ubuntu/node_modules/.bin/sslmate
/home/ubuntu/.npm/sslmate
/home/ubuntu/.npm/sslmate/0.1.4/package/bin/sslmate
~ # ./node_modules/sslmate/bin/sslmate buy www.nonfreesoftware.org 1
/usr/bin/env: node: No such file or directory

I take it the sslmate program is a Node JS script that starts with #!/usr/bin/env node. Unfortunately, I don’t have a program called node, even though I installed npm. Hmm. Word to the wise: apt-get install node gets you something called ax25-node — not what we want.

Interlude

Time: 12:03. I got an email from the founder of sslmate.com, saying that he had forgotten to update the .deb file. He thanked me for pointing out the problem and said he’d fix it. He noted, correctly, that since the .deb files are signed with GPG, that they don’t need to transported over HTTPS for authentication and integrity. I replied saying thanks, and that I was only trying to download the apt source via HTTPS on a lark anyway. (Still, it would seem to be nice to make it available.)

Back to work

But, this works:

~ # nodejs ./node_modules/sslmate/bin/sslmate buy www.nonfreesoftware.org 1
If you don't have an account yet, visit https://sslmate.com/signup
Enter your SSLMate username: noncombatant
Enter your SSLMate password: *
Linking account... Done.
Generating private key... Done.
Generating CSR... Done.
Submitting order...

We need to send you an email to verify that you own this domain.
Where should we send this email?

1. postmaster@www.nonfreesoftware.org
2. webmaster@www.nonfreesoftware.org
3. hostmaster@www.nonfreesoftware.org
4. administrator@www.nonfreesoftware.org
5. admin@www.nonfreesoftware.org
6. postmaster@nonfreesoftware.org
7. webmaster@nonfreesoftware.org
8. hostmaster@nonfreesoftware.org
9. administrator@nonfreesoftware.org
10. admin@nonfreesoftware.org

Oops, I have to set up an email account for the domain first.

Step 5: Set up Gmail for the domain

I added the new nonfreesoftware.org domain to my existing noncombatant.org account. Following Google’s tech support page instructions, I proved to Google that I own the domain by setting up a TXT record in DNS, in register.com’s web interface. Again following instructions, I added MX records in DNS to point to the Gmail servers. I verified that the settings work with dig.

Time: 12:19. Stopped, waiting for Google to finish verifying MX setup. Ate a piece of cold pizza and finished my coffee.

12:30: Started again, adding a new webmaster@nonfreesoftware.org account to satisfy sslmate.

Step 6: Try buying a certificate again

~ # nodejs ./node_modules/sslmate/bin/sslmate buy www.nonfreesoftware.org 1
Generating private key... Done.
Generating CSR... Done.
Submitting order...

We need to send you an email to verify that you own this domain.
Where should we send this email?

1. postmaster@www.nonfreesoftware.org
2. webmaster@www.nonfreesoftware.org
3. hostmaster@www.nonfreesoftware.org
4. administrator@www.nonfreesoftware.org
5. admin@www.nonfreesoftware.org
6. postmaster@nonfreesoftware.org
7. webmaster@nonfreesoftware.org
8. hostmaster@nonfreesoftware.org
9. administrator@nonfreesoftware.org
10. admin@nonfreesoftware.org
Enter 1-10 (or q to quit): 7

============ Order summary ============
Host Name: www.nonfreesoftware.org
Product: Standard SSL
Price: $15.95 / year
Years: 1

=========== Payment details ===========
Credit Card: MasterCard ending in [censored]
Amount Due: $15.95 (USD)

Press ENTER to confirm order (or q to quit):
Placing order...
Order complete.

You will soon receive an email at webmaster@nonfreesoftware.org from
sslorders@geotrust.com. Follow the instructions in the email to verify your
ownership of your domain. Once you've verified ownership, your certs will be
automatically downloaded.

If you'd rather do this later, you can hit Ctrl+C and your certs will be
delivered over email instead.

Waiting for ownership confirmation...

I checked my webmaster@nonfreesoftware.org Gmail, and saw that I had a new email from RapidSSL. The email contained a magical link for me to click on to prove that I had received the email (hence that I can read email at the domain). I clicked on it. Then I Command-Tab'd back to my shell window, and found that sslmate had finished:

Your certificate is ready for use!

Private key file: www.nonfreesoftware.org.key
Certificate file: www.nonfreesoftware.org.crt
Certificate chain file: www.nonfreesoftware.org.chain.crt
Certificate with chain file: www.nonfreesoftware.org.chained.crt

Sweet!

Step 7: Configure Apache to use the certificate

Below is my Apache configuration file for the domain.

I want to use only strong protocol versions and ciphersuites, so I did a web search for [ apache ssl ciphersuites ]. That got me to http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html.

I also want the http:// site to automatically redirect to https://, so I searched for [ apache redirect ssl ]. That got me to https://wiki.apache.org/httpd/RedirectSSL.

I also want to use Strict Transport Security, so I searched for [ apache hsts ]. That got me to https://www.owasp.org/index.php/HTTP_Strict_Transport_Security.

To figure out the certificate chain business, I search for [ apache server intermediate certificate ], and found http://www.digicert.com/ssl-certificate-installation-apache.htm. You need to serve both the end-entity (EE) certificate, and any intermediate certificates that allow the EE to chain up to the root. As you’ll recall from the sslmate output, it got me the EE, the intermediate, and a file containing both.

<VirtualHost *:80>
  ServerName nonfreesoftware.org
  ServerAlias www.nonfreesoftware.org
  ServerAdmin webmaster@nonfreesoftware.org
  DocumentRoot /var/www/html
  LogLevel info ssl:warn
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined
  Redirect permanent / https://nonfreesoftware.org/
</VirtualHost>
<VirtualHost *:443>
  ServerName nonfreesoftware.org
  ServerAlias www.nonfreesoftware.org
  ServerAdmin webmaster@nonfreesoftware.org
  DocumentRoot /var/www/html
  LogLevel info ssl:warn
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined
  SSLEngine On
  SSLCertificateFile /etc/ssl/certs/www.nonfreesoftware.org.crt
  SSLCertificateChainFile /etc/ssl/certs/www.nonfreesoftware.org.chain.crt
  SSLCertificateKeyFile /etc/ssl/private/www.nonfreesoftware.org.key
  Header add Strict-Transport-Security "max-age=1576800"
  SSLProtocol all -SSLv2
  SSLCipherSuite HIGH:!aNULL:!MD5
</VirtualHost>

That config required me to enable modssl (for SSL/TLS), modsocache_shmcb (for TLS session cacheing), and modheaders (for the HSTS header directive):

/etc/apache2/mods-enabled # ls -l
[...]
lrwxrwxrwx 1 root root 26 Aug 20 19:42 ssl.conf -> ../mods-available/ssl.conf
lrwxrwxrwx 1 root root 26 Aug 20 19:42 ssl.load -> ../mods-available/ssl.load
lrwxrwxrwx 1 root root 36 Aug 20 19:43 socache_shmcb.load -> ../mods-available/socache_shmcb.load
lrwxrwxrwx 1 root root 30 Aug 20 19:57 headers.load -> ../mods-available/headers.load

Set-up complete

Time: 12:46. So, it took me about 90 minutes, including breaks and a technical mishap, to go from 0 to a running HTTPS web server with a valid certificate.

I spent another 90 minutes or so writing and editing this blog post. (I’m a slow writer.)

Conclusion

I spent $38 for the domain; $16 for the certificate; a small, ongoing cost (I don’t know how much yet) for the EC2 instance; and 90 minutes of my time. The certificate is probably the cheapest item, or perhaps on par with my t2.micro server instance for a few months or the year.

Especially given the fact that I am a software engineer — not a good operations engineer/systems administrator, as I think my command lines and configuration files prove — I think it’s fair to say that any technical person who can set up an HTTP server can also set up an HTTPS server with only marginal additional cost and in only marginally more time.

Sure, sslmate could be more perfect, and hopefully nobody will run into the .deb problem again. Also, perhaps the sslmate.com people should update their documentation to show the exact commands you have to run to launch the Node JS script. But avoiding those mishaps would have saved me 20 minutes at most.

Also, there are surely better Apache configurations — I haven’t used elliptic curve ciphers, I haven’t performance-tuned it all (including a good configuration for text compression), and so on. But it works, it’s reasonable, and it took 90 minutes from start to finish. I think that’s enough of an answer to people who believe HTTPS is too difficult or too expensive to set up.

Why not use HTTPS for noncombatant.org?

An excellent question! I’m glad you asked. I am using hosted WordPress, and unfortunately they do not offer HTTPS for custom domains. I asked a tech support representative about it, and she said they may offer it in the future but do not now. They definitely could, as a technical matter, but until Windows XP dies, it’s difficult given WordPress’ multi-tenant deployment.

So, I have to choose between having WordPress manage their software for me, and having a securely-transported blog. I definitely don’t want to manage WordPress myself on my own server, but perhaps I could move this blog to nonfreesoftware.org running some simpler blogging platform or as a static set of pages.

An Update

I just got an email from sslmate.com saying that they have now made packages.sslmate.com work over HTTPS, too. So that’s nice.