Apparently I haven’t posted this anywhere so I just want to go on record: Let’s Encrypt is amazing and fantastic. In five years the percentage of web pages loaded by Firefox using HTTPS went from 30% to 80%. That’s huge! A really impressive accomplishment1. And ACME, the protocol for validating domain ownership, is also great. A massive improvement over the old process of getting certificates. And all those certificates are only valid for 90 days, instead of the old standard of a year or more! So good.
A Quibble
I don’t like how Certbot is configured. To keep things in perspective let me say that this is just a minor usability complaint. It doesn’t stop Let’s Encrypt from being fantastic.
Certbot is a tool for obtaining certificates from Let’s Encrypt for https and other services. The configuration file is written automatically when the certbot command is run. Users are discouraged2 from modifying the configuration file directly. I can’t recall any other tool with this behavior. I don’t get it. Like, why? Sysadmins are used to writing config files, why is it important for this to be different? Maybe it’s supposed to be easier for users? But is it?
I guess usually this behavior is fine and not a problem. I find it inconvenient because I manage my two cloud servers using Salt (a configuration-as-code tool). It’s easy to place a config file on the server and apply changes to it. But since that’s discouraged I settled on running the certbot command but only if the config file does not exist. This is what I did, in case it helps anyone:
{% macro configure_certbot(primary_domain, additional_domains = none, require_file = none) %}
{#
@param require_file We use Certbot's "webroot" authentication plugin.
Certbot puts a file in our web server's root directory. This
means we need a working web server. This parameter should be a
Salt state that ensures Nginx is up and running for this
domain.
#}
{# Don't attempt this in VirtualBox because it will always fail. #}
{% if grains['virtual'] != 'VirtualBox' %}
run-certbot-{{ primary_domain }}:
cmd.run:
- name: "certbot certonly
--non-interactive
--quiet
--agree-tos
--email mark@kingant.net
--no-eff-email
--webroot
--webroot-path /srv/{{ primary_domain }}/www
--domains {{ primary_domain }}{{ ',' if additional_domains else '' }}{{ additional_domains|join(',') if additional_domains else '' }}
--deploy-hook 'install --owner=root --group=root --mode=444 --preserve-timestamps ${RENEWED_LINEAGE}/fullchain.pem /etc/nginx/{{ primary_domain }}_cert.pem &&
install --owner=www-data --group=www-data --mode=400 --preserve-timestamps ${RENEWED_LINEAGE}/privkey.pem /etc/nginx/{{ primary_domain }}_cert.key &&
service nginx reload'"
# Certbot saves the above arguments into a conf file and
# automatically renews the certificate as needed so we only need to
# run this command once. This would need to be done differently if
# we ever want to change the renewal config via Salt. The Certbot
# docs[1] describe using --force-renewal to force the renewal conf
# file to be updated. So we could figure out a way to do that once
# via Salt. Or we could manage the renewal conf file directly via
# Salt.
#
# [1] https://eff-certbot.readthedocs.io/en/stable/using.html#modifying-the-renewal-configuration-of-existing-certificates
- unless:
- fun: file.file_exists
path: /etc/letsencrypt/renewal/{{ primary_domain }}.conf
- require:
- pkg: certbot
- file: {{ require_file }}
{% endif %}
{% endmacro %}
{{ configure_certbot('kingant.net', additional_domains=['www.kingant.net'], require_file='/etc/nginx/sites-enabled/kingant.net') }}
It’s a bit messy and I don’t know what I’ll do when I need to change the config. If you want certbot to update the config file you have to use --force-renewal, but I certainly wouldn’t want to do that every time I apply my configuration state to my servers. I think I’ll have to either run certbot --force-renewal by hand (fine, but loses the benefits of configuration-as-code), or have Salt manage the config file (discouraged by the official docs). Either option is fine, it just feels like a dumb problem to have.
I’m not the only one who has been inconvenienced by this. A quick search turned up this question thread and this feature request ticket.
Anyway, but Let’s Encrypt really is fantastic! This one usability complaint for my atypical usage pattern is super minor.
- Yeah sure, Let’s Encrypt isn’t solely responsible. There had been a push to encrypt more sites post-Snowden anyway (e.g. Cloudflare in 2014). And there’s no way to know how big of an impact Let’s Encrypt had. Buuuuut, I bet it was huge. And yeah, it wasn’t Let’s Encrypt by themselves, hosts like Squarespace, DigitalOcean, and WP Engine have also done their part.
- “it is also possible to manually modify the certificate’s renewal configuration file, but this is discouraged since it can easily break Certbot’s ability to renew your certificates.”
