How to use Let’s Encrypt with lighttpd (sigh)

Everyone has legacy systems. It’s the same story. Some mostly unmaintained server that you really want to upgrade to the newest, shiniest tools but somehow never get around to.

I’ve got one of them, it’s an old internal service running a website behind lighttpd. I know, I know. Lighttpd is such a pain to configure compared to shinier toys like nginx (and honestly, somehow, even older mules like apache at times). So what if you want to use Let’s Encrypt with it?

  1. 1. Generate the cert in standalone mode, just like for nginx. See my previous post if you don’t know how to do that.
  2. 2. Modify your SSL config file for lighttpd. Mine is in /etc/lighttpd/config-enabled/10-ssl.conf. It looks a bit like this:
    # /usr/share/doc/lighttpd-doc/ssl.txt
    $SERVER["socket"] == "" {
            ssl.engine  = "enable"
            # ah, self-signed certs
            #ssl.pemfile = "/etc/lighttpd/selfsigned.pem"
            ssl.pemfile = "/etc/letsencrypt/live/"
   = "/etc/letsencrypt/live/"
            ssl.cipher-list = "whatever"
            ssl.honor-cipher-order = "enable"
  3. In order for lighttpd to accept a SSL cert, you’ll need to concatenate the key and cert into a single cert file:

    cd /etc/letsencrypt/live/
    cat privkey.pem cert.pem > lighttpd.pem

    Bam! Reload lighttpd to pick up changes, and you should be good to go.

Let’s Encrypt installer fails building OpenSSL for Python library

When upgrading my Let’s Encrypt SSL cert on my tiny DigitalOcean VM recently, I ran into an annoying error: the installer would get to installing Python dependencies, reach M2Crypto (a pretty awkward wrapper around OpenSSL, but unfortunately with no better alternative) and fail with the following error:

building '_openssl' extension

creating build/temp.linux-x86_64-2.7/build

creating build/temp.linux-x86_64-2.7/build/temp.linux-x86_64-2.7

x86_64-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/incl
ude/python2.7 -c build/temp.linux-x86_64-2.7/_openssl.c -o build/temp.linux-x86_64-2.7/build/temp.linux-x86_64-2.7/_op

x86_64-linux-gnu-gcc: internal compiler error: Killed (program cc1)

Please submit a full bug report,

with preprocessed source if appropriate.

See <file:///usr/share/doc/gcc-4.8/README.Bugs> for instructions.

error: command 'x86_64-linux-gnu-gcc' failed with exit status 4

Argh! It turns out that this error message doesn’t provide us with much juicy context, as I found out when I encountered it. The important part is near the end:

x86_64-linux-gnu-gcc: internal compiler error: Killed (program cc1)

Hmm, I thought. Must be the kernel! I only had about 250 megabytes of memory left, so I tried stopping a few non-critical but memory-heavy services (like Redis for my Hubot) and luckily, that saved me — it was just a lack of free memory. But what could you do it that wasn’t possible?

One option, while possibly quite slow, would be to create a temporary swapfile. Thankfully Digital Ocean’s small VMs use SSDs so it’s not the end of the world:

sudo dd if=/dev/zero of=/path/to/swapfile bs=1024 count=524288
sudo chmod 600 /path/to/swapfile
sudo mkswap /path/to/swapfile
sudo swapon /path/to/swapfile

And once you’re done, you can remove it:

sudo swapoff /path/to/swapfile
sudo rm /path/to/swapfile


Using Let’s Encrypt with an unsupported web server (like nginx)

Let’s Encrypt is a fantastic tool, there’s no doubt about it. However, as mentioned in a previous post, they only really support Apache using their completely automated method. If you’re using a more modern web server like nginx (I am!), it’s slightly more complicated but by no means insurmountable.

Read more

Let’s Encrypt and the SSL Cert Mafia

Since Google has started favouring HTTPS-enabled websites over plain old HTTP, SSL certs are almost mandatory for many website owners. Up until now, getting one has either meant:

  • self-signing (which is sub-optimal since browsers warn about self-signed certs as if they’re the end of days)
  • using a free cert from an untrusted CA such as StartSSL (which is sub-optimal because people visiting your website have to either install the StartSSL root certs or deal with more extreme browser warnings)
  • paying protection fees to the SSL Mafia (which is sub-optimal because it’s often prohibitively expensive – several times the cost of my inexpensive hosting setup)

Obviously, none of these seem like great solutions. But why is that the case? Read more

Markup Matryoshka: Jinja2 inside of Jekyll

Have you ever tried to write a Jekyll blog post with Jinja2 code inside of it? You probably wrote something like this:

Read more

Ansible secrets: death to Vault, long live Credstash!

I’ve been using Ansible for a while now. It’s a great tool — it’s quick, pretty intuitive and, most importantly, allows you to build up and tear down services on top of a clean slate pretty rapidly.

One thing, however, that I’m not a huge fan of is Ansible Vault. Read more