Getting TLS certs locally because why not
I have the domain
bouke.dev that I use for serving local content—for example, to run Jekyll on my machine. I have set up the DNS to point
127.0.0.1. Because I was bored I decided to serve it over TLS as well, here’s how to do that:
- Install Lego:
go get -u github.com/go-acme/lego/v4/cmd/lego
- Figure out how to configure it for your DNS Provider by reading the docs
legofrom your home directory, e.g.
lego --accept-tos -d '*.bouke.dev' -d 'bouke.dev' -m <email> --dns namecheap run
You should now have valid certificates under
~/.lego/certificates. For example, I have one called
You should consider certificates unreliable, unless you have a renewal process in place! So, I created the following file in
#!/usr/bin/env bash cd $HOME export NAMECHEAP_API_KEY=... export NAMECHEAP_API_USER=... exec lego --accept-tos -d '*.bouke.dev' -d 'bouke.dev' -m <email> --dns namecheap renew
Don’t forget to make it executable with
chmod +x ~/bin/update-cert. Then just add it to your crontab by running
crontab -e and adding:
lego will run daily, and keep your certificate nice and fresh. Cool!
Sharing is caring
This process can also be used for certificates that need to be shared with other people. You can set-up a monthly scheduled job with GitHub Actions or Google Cloud Scheduler that runs something like this:
lego --accept-tos --domains=example.dev --email@example.com --dns=gcloud --pem --path=lego run gcloud secrets versions add projects/xxx/secrets/star-company-dev-cert --data-file=lego/certificates/_.company.dev.pem
And now you can have a certificate that can be used by anyone who has access to the secret. Or if you don’t care that much you could even commit it directly to the repository automatically, since it’s just for local development anyways.