Switching to HTTPS on Apache 2.4.7 on Ubuntu 14.04 on Digital Ocean

I’ve been updating my book sites over to HTTPS:

They’re all hosted on the same (virtual) box as adactio.com—Ubuntu 14.04 running Apache 2.4.7 on Digital Ocean. If you’ve got a similar configuration, this might be useful for you.

First off, I’m using Let’s Encrypt. Except I’m not. It’s called Certbot now (I’m not entirely sure why).

I installed the Let’s Encertbot client with this incantation (which, like everything else here, will need root-level access so if none of these work, retry using sudo in front of the commands):

wget https://dl.eff.org/certbot-auto
chmod a+x certbot-auto

Seems like a good idea to put that certbot-auto thingy into a directory like /etc:

mv certbot-auto /etc

Rather than have Certbot generate conf files for me, I’m just going to have it generate the certificates. Here’s how I’d generate a certificate for yourdomain.com:

/etc/certbot-auto --apache certonly -d yourdomain.com

The first time you do this, it’ll need to fetch a bunch of dependencies and it’ll ask you for an email address for future reference (should anything ever go screwy). For subsequent domains, the process will be much quicker.

The result of this will be a bunch of generated certificates that live here:

  • /etc/letsencrypt/live/yourdomain.com/cert.pem
  • /etc/letsencrypt/live/yourdomain.com/chain.pem
  • /etc/letsencrypt/live/yourdomain.com/privkey.pem
  • /etc/letsencrypt/live/yourdomain.com/fullchain.pem

Now you’ll need to configure your Apache gubbins. Head on over to…

cd /etc/apache2/sites-available

If you only have one domain on your server, you can just edit default.ssl.conf. I prefer to have separate conf files for each domain.

Time to fire up an incomprehensible text editor.

nano yourdomain.com.conf

There’s a great SSL Configuration Generator from Mozilla to help you figure out what to put in this file. Following the suggested configuration for my server (assuming I want maximum backward-compatibility), here’s what I put in.

Make sure you update the /path/to/yourdomain.com part—you probably want a directory somewhere in /var/www or wherever your website’s files are sitting.

To exit the infernal text editor, hit ctrl and o, press enter in response to the prompt, and then hit ctrl and x.

If the yourdomain.com.conf didn’t previously exist, you’ll need to enable the configuration by running:

a2ensite yourdomain.com

Time to restart Apache. Fingers crossed…

service apache2 restart

If that worked, you should be able to go to https://yourdomain.com and see a lovely shiny padlock in the address bar.

Assuming that worked, everything is awesome! …for 90 days. After that, your certificates will expire and you’ll be left with a broken website.

Not to worry. You can update your certificates at any time. Test for yourself by doing a dry run:

/etc/certbot-auto renew --dry-run

You should see a message saying:

Processing /etc/letsencrypt/renewal/yourdomain.com.conf

And then, after a while:

** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)
Congratulations, all renewals succeeded.

You could set yourself a calendar reminder to do the renewal (without the --dry-run bit) every few months. Or you could tell your server’s computer to do it by using a cron job. It’s not nearly as rude as it sounds.

You can fire up and edit your list of cron tasks with this command:

crontab -e

This tells the machine to run the renewal task at quarter past six every evening and log any results:

15 18 * * * /etc/certbot-auto renew --quiet >> /var/log/certbot-renew.log

(Don’t worry: it won’t actually generate new certificates unless the current ones are getting close to expiration.) Leave the cronrab editor by doing the ctrl o, enter, ctrl x dance.

Hopefully, there’s nothing more for you to do. I say “hopefully” because I won’t know for sure myself for another 90 days, at which point I’ll find out whether anything’s on fire.

If you have other domains you want to secure, repeat the process by running:

/etc/certbot-auto --apache certonly -d yourotherdomain.com

And then creating/editing /etc/apache2/sites-available/yourotherdomain.com.conf accordingly.

I found these useful when I was going through this process:

That last one is good if you like the warm glow of accomplishment that comes with getting a good grade:

For extra credit, you can run your site through securityheaders.io to harden your headers. Again, not as rude as it sounds.

You know, I probably should have said this at the start of this post, but I should clarify that any advice I’ve given here should be taken with a huge pinch of salt—I have little to no idea what I’m doing. I’m not responsible for any flame-bursting-into that may occur. It’s probably a good idea to back everything up before even starting to do this.

Yeah, I definitely should’ve mentioned that at the start.

Have you published a response to this? :

Responses

Peter-Paul Koch

@adactio Read it a while ago, but it didn’t really put my mind at ease. I appreciate the confirmation that it is possible to install HTTPS.

3 Shares

# Shared by Marcel Mengerink on Monday, August 29th, 2016 at 12:59pm

# Shared by David G. Smith on Monday, August 29th, 2016 at 1:29pm

# Shared by CW Petersen on Monday, August 29th, 2016 at 3:27pm

19 Likes

# Liked by वैभव || vaibhav on Sunday, May 29th, 2016 at 6:11pm

# Liked by marc thiele on Sunday, May 29th, 2016 at 6:13pm

# Liked by Alen Abdula on Sunday, May 29th, 2016 at 6:42pm

# Liked by Chris Shiflett on Sunday, May 29th, 2016 at 6:49pm

# Liked by Christiane on Sunday, May 29th, 2016 at 6:49pm

# Liked by Dave Rupert on Sunday, May 29th, 2016 at 6:49pm

# Liked by Marc Drummond on Sunday, May 29th, 2016 at 9:29pm

# Liked by Matthias Ott on Monday, May 30th, 2016 at 12:11am

# Liked by justin avery on Monday, May 30th, 2016 at 9:12am

# Liked by Marcel Mengerink on Monday, August 29th, 2016 at 1:15pm

# Liked by Juan Fernandes on Monday, August 29th, 2016 at 1:16pm

# Liked by David Nyhuis on Monday, August 29th, 2016 at 1:17pm

# Liked by Wilson Ngo on Monday, August 29th, 2016 at 1:39pm

# Liked by Arelia Jones on Monday, August 29th, 2016 at 1:39pm

# Liked by David G. Smith on Monday, August 29th, 2016 at 1:39pm

# Liked by Walter Higgins on Monday, August 29th, 2016 at 1:40pm

# Liked by Jan Skovgaard on Monday, August 29th, 2016 at 3:43pm

# Liked by CW Petersen on Monday, August 29th, 2016 at 3:43pm

# Liked by m0rk on Monday, August 29th, 2016 at 4:12pm

Related posts

Someday

Changing defaults in browsers …someday.

Homebrew header hardening

Step-by-step instructions for more secure response headers on Apache.

Insecure

Security or access: choose one.

This is for everyone with a certificate

The browser beatings will continue until morale improves.

HTTPS

Doing the right thing.

Related links

So We Got Tracked Anyway

Even using a strict cookie policy won’t help when Facebook and Google are using TLS to fingerprint users. Time to get more paranoid:

HTTPS session identifiers can be disabled in Mozilla products manually by setting ‘security.ssl.disablesessionidentifiers’ in about:config.

Tagged with

ISP’s are updating your site without your permission

One more reason to make the switch to HTTPS.

Tagged with

Extended Validation is Broken

How a certificate with extended validation makes it easier to phish. But I think the title could be amended—here’s what’s really broken:

On Safari, the URL is completely hidden! This means the attacker does not even need to register a convincing phishing domain. They can register anything, and Safari will happily cover it with a nice green bar.

Tagged with

Certified Malice – text/plain

Following from that great post about the “zone of death” in browsers, Eric Law looks at security and trust in a world where certificates are free and easily available …even to the bad guys.

Tagged with

We need more phishing sites on HTTPS!

All the books, Montag.

If we want a 100% encrypted web then we need to encrypt all sites, despite whether or not you agree with what they do/say/sell/etc… 100% is 100% and it includes the ‘bad guys’ too.

Tagged with

Previously on this day

10 years ago I wrote 100 words 068

Day sixty eight.

22 years ago I wrote Gaming for good, not evil

According to recently published research that has geeks the world over rubbing their hands with glee, playing video games may actually be quite beneficial: