Showing posts with label website. Show all posts
Showing posts with label website. Show all posts

Friday, 29 March 2019

HTTPS for a small site - redux

A few years ago I set up LetsEncrypt for my sites, so I could create certificates, do HTTPS and blah blah security. Anyway, it all worked well until, nearly three years later...


Balls

Still, an automated process that has been running unattended for three years suddenly stopping working has never caused a problem, right?

It turns out some things have changed with LetsEncrypt in the last three years. Like, everything. Everything. Even the name. Now the thing I want is called Certbot. Fortunately (and against the trend in modern days) it has improved with time. Now there are packages and guides! Sadly, migration is going to be worse than setting things up in the first place. It's installing new software then making sure it's renewing certs generated in the old way, in the old place.

Sigh, here we go.

So I followed the install section of this guide then ran:
sudo certbot renew
And it ... just worked?! I don't understand. This is not computing.

Ok, I need to fix the cron too. That'll cause problems.

Starting as:
export PATH=<boring path stuff> && /another/path/letsencrypt/letsencrypt-auto renew >> /path/to/logs/renew.log
Change to:
/usr/bin/certbot renew >> /path/to/logs/renew.log
And ... that appears to just work too?!

Amazing. It looks like some things do get better.

Tuesday, 30 August 2016

Jekyll and the build scripts a few years on

A few years ago I moved my sites from a PHP templating system to static generation using Jekyll. How is it working out?

Pretty well. I’ve had no downtime (that I haven’t caused) which is to be expected on a low-traffic website serving HTML files. Updating content and templates has been easy, with Jekyll remaining simple to use. While I’m sure I’m in need of an update, that is less of a concern than if I was running code exposed to a user. Overall no problems with the technology or maintenance - indeed I find it much easier to work with than previous versions of the site as I don’t have to re-learn my configuration each time I want to do anything more complicated than change some words.

The biggest win - and something I actually considered skipping when I initially implemented - has been with the build scripts. In professional life I wouldn’t think twice about writing automated build scripts for a project but we all know that this kind of thinking isn’t as rigorously followed for personal projects. I wrote a simple mina script for deploying (and updating) my sites and several years on I deeply thankful to my past self. I haven’t had to keep my build process in my brain at all - just the magic command, which is in a README somewhere. This has meant small updates have been easy, the most boring part of site maintenance has all but gone away and consequently those updates have actually happened.

The lesson to take away here is that doing the hard (and dull) work up front of defining a development process and writing deployment scripts was worth it. Not so much because of time saving, or the consistency inherent in an automated process - but because these benefits actually encouraged me to maintain my sites in a way I simply wouldn’t have done had I been required to remember how to deploy my work each time I did anything.

Sunday, 24 April 2016

HTTPS for a small site

We all know it’s a good thing. Security, SEO and soon not being called out by Chrome and Firefox for being insecure. But for a small, personal site it’s a pain in the rear to set up and the certificate is prohibitively expensive, right? Right?

Maybe not. Let's try and change this:

The certificate

These days you can get a 90 day certificate for free from Let’s Encrypt, which is news to me and the reason I thought I’d give this a go.

Main stumbling block removed.

Apache config for SSL

Ok, I can write this config myself. However Let’s Encrypt has a magic tool which claims to do everything for me. Let’s find out.

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto --help
  • It downloaded a python environment for me.
  • It did a thing with root privileges courtesy of sudo. Probably shouldn't have used a window in which I’d previously sudo'd something. Oops.
./letsencrypt-auto --apache
The automated thing doesn't detect my domain. It detects a load of others, but I’m not ready to destroy those yet. Boo.

Also, I'm guessing with letsencrypt-auto. It seems to pass flags to the letsencrypt script which is buried somewhere. Turns out I am right. Great.

I have to agree with the T&Cs to register with the ACME server. Aside from the obvious, ACME seem to mean Advisory Committee on Mathematics Education which I don’t think is relevant here so clearly I am getting a cert from the same people who supply anvils to Wile E. Coyote.

Seems legit. Let’s do this.

./letsencrypt-auto --apache -d tomnatt.com
Still not finding my domain. Is it … confused by the number of domains? Nope, it doesn’t like files containing multiple vhosts. Oh. Reconfiguration time.

...

Ok, updated. Now time to fire this baby up. The original command now finds all the domains. Go! What could go wrong?

Wrrrrrr…


Well, shit.

Minor problem - apparently I'm loading my fonts over an insecure connection.


Bingo.

For those of you not up to speed with the arcane art of reading browser URL bars, the shield is gone which means the browser isn't blocking assets trying to load into a secure page over an insecure connection.

These certs expire in 90 days so time for a simple cron.

00 03 * * * $location/letsencrypt/letsencrypt-auto renew >> $location/letsencrypt/logs/renew.log 2>&1
Docs recommend checking daily, so that should keep things up to date. And potentially fill the filesystem. Meh.

So, my site is available over a secure connection. Hurrah! The “ensure all connections” setting seems to have set up a basic redirect, which is good although I'm going to have add the HSTS headers myself and hope that doesn't get toasted when I next run one of these scripts. Renew seems to behave though.

HSTS

HSTS removes a vulnerable step when redirecting from an insecure to a secure connection. Details on the magic can be seen on the OWASP site.

The important bit of Apache magic is:

Header always set Strict-Transport-Security "max-age=31536000; includeSubdomains; preload"
Which is stuck into the https vhosts and requires mod_headers enabled.

Testing this was a world of fun. I'd recommend disabling the cache (in the dev tools), using a plugin to inspect the headers (I like Live HTTP Headers) and making liberal use of this secret page to check the status of the HSTS settings. This is all in Chrome.

Tidying up

It seems only the automagic script doesn't like my old Apache config. Now it’s all set up I can put everything back in the same file.
So now I am handling four different connections in the same file:
  1. https://www.tomnatt.com
  2. https://tomnatt.com
  3. http://www.tomnatt.com
  4. http://tomnatt.com
With 2. and 3. redirecting to 1. and 4. redirecting to 2. so as to pick up the extra HSTS headers.

HKPK

Yeah, that can wait.

Overall though, this was not the trial I expected. Getting a cert is now really easy. The only parts that required any real thought were figuring out how to arrange my Apache config and checking the HSTS headers were being set correctly.

No excuses any more! Best do the others.

Wednesday, 21 November 2012

New skin for my website

In an effort to not look like I've learnt nothing in the last four years, I've reskinned my website. I don't kid myself that anyone actually wants to know this information, but by writing a post about it, in years to come I can find out when I released this particular version by looking at my blog. That's keeping some kind of digital timeline - the digital archivists would be proud.