Good news, a security issue that was blocking the draft for the new DNS-PERSIST-01 challenge mode for TLS certificates has been resolved, meaning the challenge can resume moving forward.
Some background for those who aren’t up to date:
- TLS challenges are how self-hosters and many other TLS certificate users prove who they are in order to automate cert renewals.
- The most popular challenge methods are HTTP-01 (which involves having a live web server answering on port 80 somewhere) and DNS-01 (which involves putting a key given by the TLS authority in your DNS zone in a TXT record temporarily).
- All the current challenges are conducted “live” and require active online participation on the part of the domain owner each time a cert is approaching expiration.
- The new DNS-PERSIST-01 challenge would let owners keep a proof in their DNS zone indefinitely (or with self-imposed expirations), eliminating the need for those online sessions.
- DNS-PERSIST-01 was slated to come out in Q2 this year at the latest and all the popular tools (ACME bots, reverse proxies etc.) have been chomping at the bit to implement it.
- Unfortunately there’s been a security snag. Trying to do things the way DNS-01 did (record only the server-provided proof in DNS) would open DNS-PERSIST-01 to middleman attacks, because unlike DNS-01 where the proof is only there temporarily for a few seconds or a few minutes at the most, in this case the proof would be long-term.
- Hence issue #64, which has been trying to come up with a way to keep only a partial proof in DNS, and combine it with something issued by the server and something issued by the domain owner to make the whole proof, thus rendering the stuff stored in DNS impossible to use for malicious purposes, yet still sufficient for verifying ownership periodically.
Hopefully now that this hurdle has been passed things will proceed faster and we’ll get to use this in the near future.
So if I understand: hosters will be able to provide the proof at a time/schedule of their choosing. On actual servers a simpler, automated cert renew process without the need for them to hold nameserver API credentials.
You put an account id/token into dns, which allows machines to renew the cert under that account with just the account credentials (key).
So after setting it up, the token stays the same forever and you don’t need to touch dns.
Such tokens are already used by acme clients when they renew their certs. It’s also how acme providers can detect expiring certificates for example.
I find it a bit weird, since the whole deal of shortening lifetimes was in part to protect against stolen certificates, and now by stealing the account key you are again stealing the ability to indefinitely make certificates.
At least you can “revoke” such access by switching the account and updating the dns record authorizing it.