Automating (Wildcard) certificate renewal with Acme.sh, DeSec.io and some DNS magic

Mark Janssen — Tue, 11 Jul 2023 16:15:26 GMT

Automatically requesting TLS/SSL certificates using the ACME protocol is quite nice. Usually to just get a regular TLS certificate, you just have to run an ACME capable tool or webserver, which will place a textfile in /.well-known/acme-challenge on your webserver, which is then used to validate control over the domain.

Alternatively you can use DNS based validation. This is even required when requesting wildcard certificates, for example, when requesting a certificate for '*.sig-io.nl'.

When validating using DNS, you need to have your ACME client create a DNS record '_acme-challenge' in your DNS domain. This can be done using various ACME clients, and I myself have written modules/plugins for Dehydrated for various DNS providers over the years.

Recently I've switched from Dehydrated as my preferred ACME client to Acme.sh. This client has a massive amount of DNS providers supported in the main codebase. So it will usually have an interface to whatever DNS system you might use.

Some of my customers however use domains hosted by (for example) TransIP.nl, which does have an API to update DNS-records, but usually takes very long (5-10 minutes) to update records, and also has no granulated access-control to their API. If you have API access, you can do everything with all domains under that account. This means you can't really leave credentials to this account in config-files somewhere.

However, I've now found a solution to these problems that I'm quite satisfied with. I'm using deSEC.io, a new non-profit, community-oriented DNS provider, with a nice API to do DNS validations. With deSEC I can create an API key that is limited in time and source-network. And since deSEC is free, I can create a seperate account just for acme-validation on an otherwise unused domain.

So to create a certificate for a customer-domain, I just have them create a CNAME entry in whatever DNS system they use, which points to my acme-validation only domain-name hosted at deSEC.io.

For example, for sig-io.nl I could create a CNAME record '_acme-challenge.sig-io.nl' pointing to '_acme-challenge.sig-io.nl.acme.example.com'. And then (given that example.com is a domain I manage with deSEC.io) use Acme.sh to create certificates using this alias domain using:

export DOMAIN="sig-io.nl" acme.sh --issue -d "*.${DOMAIN}" --challenge-alias "${DOMAIN}.acme.example.com" --server letsencrypt --dns dns_desec

LUA-DNS migration

Mark Janssen — Sun, 10 Jul 2022 15:50:17 GMT

At Sig-I/O we have (mostly) been using OpenProvider for DNS registrations and hosting over the last few years. This has mostly been fine, but OpenProvider has been having some issues every now and then, and is changing things, but not allways for the better.

After a period of stagnation, they now seem to be developing new features again, but none of those appeal much, while important bugs and wishlist items remain unfixed.

We've been looking at alternatives for at least the DNS hosting parts for a while, and even started looking into setting up our own anycast network of DNS servers, but concluded that his was too much effort (and money) for what we needed, so the search for a good matching DNS provider was continued.

After looking at various options, and trying out some of them with test-domains, we were most charmed with LuaDNS.net, which is a small Romenian company with a nice working anycast DNS system and an interesting method for pushing DNS updates.

LuaDNS has a webinterface for inspecting the zones and records that are served by their servers, but this interface doesn't allow updates. For updating DNS records there are 2 possible options:

Using a REST api
Using GIT and a notify-hook

Using the REST api

We use the REST-api for updating temporary records, like the 'acme-challenge' records needed for ACME validation by Lets-Encrypt, ZeroSSL or BuyPass. This is done using the dns_lua hook in acme.sh

Using GIT and notify-hooks

The primary method to add zones and records to LuaDNS is by creating a lua-script or bind-formatted file in a git repository. This has the added benefit of having an archive of all previous DNS records. In our case, we host the git repository ourselved on a Gitea instance.

Every time a git commit is pushed to this Git repository, gitea sends a webhook to the LuaDNS api server, which then clones the git repository, parses the lua-scripts and/or bind zone files, and updates its zone files. A log of this parsing it then sent via e-mail to the admin account.

DNSSec

LuaDNS supports DNSSec, which we had enabled at OpenProvider as well, so for the migration to LuaDNS we temporarily disabled this (to ease migration). Sadly, LuaDNS doesn't allow configuring (or querying) the DNSSec keys from the API at this point, but when we asked about this, we got a quick reply that this would be added in the coming weeks.

Update 2022/07/12: I just got an e-mail from LuaDNS that this feature has been added, so there is an API endpoint for DNSSec now.

This however meant that configuring the DNSSec keys was still somewhat of a manual excersize at this time. We manually enabled DNSSec on all LuaDNS hosted zones and copy/pasted the public-keys to a textfile. We then used the OpenProvider API to reconfigure all our zones to be hosted by LuaDNS and configured the DNSSec keys at the same time.

This mostly worked, though some domains gave some issues, so these were then updated by hand.

Updating the zones in Openprovider can be done with this api-call:

curl -X PUT \
  https://api.openprovider.eu/v1beta/domains/${ID} \
  -H "Accept: */*" \
  -H "Authorization: Bearer ${OPENPROVIDER_API_BEARER}" \
  -d "{ \"ns_group\": \"luadns\", \"dnssec_keys\": [ { \"alg\": 13, \"flags\": 257, \"protocol\": 3, \"pub_key\": \"${DNSSEC}\", \"readonly\": 1 } ] }"

Where {ID} is the ID of the zone at OpenProvider (which we gathered in a previous script), and {DNSSEC} is the DNSSec key from LuaDNS, which we manually gathered.

Post Migration Checks

After migration we received an e-mail from dnssec-tools, complaining about missing records we had earlier, so we re-created some tlsa-records and did some more checks while we were at it.