Allow Certmagic to generate 'next' private key to allow safe TLSA/DANE deployment and rollover

What would you like to have changed?

DANE (DNS-based Authentication of Named Entities) is a protocol that allows X.509 certificates to be bound to DNS names using Domain Name System Security Extensions (DNSSEC). This is done by having TLSA records which publish the public key of a certificate. In this procedure a safe rollover of certificates is needed, to ensure that a the public key for a new certificate already exists in DNS before the TTL is up. This is documented by Viktor Dukhovni at ICANN61: https://imrryr.org/~viktor/ICANN61-viktor.pdf - see especially slides 20+21 for the rollover procedure ('current + next').

To enable this a 'next' private key should be created when the 'current' private is being used for the certificate renewal. Next time the certificate is renewed the 'next' certificate should be used.

The feature request is to implement an option in Certmagic to allow a 'next' private key to be generated when a certificate is requested. Currently the only (somewhat) viable ways to automate a safe DANE/TLSA rollover are provided by acme.sh and certbot. It would be helpful to have Certmagic (and by extension Caddy) to allow for this as well.

From a quick look it seems that generating a 'next' private key would be trivial - as would the checking for the existence of a 'next' private key when generating a certificate. The somewhat more complicated part seems to be saving just the private key to disk as now it seems all certificate resources are saved to disk at once; and here we would only have a private key to save.

Before starting any work on a PR or making changes I'd like to discuss (@mholt) if (1) this would be something in scope for Certmagic and (2) what would be the suggested way forward?

Why is this feature a useful, necessary, and/or important addition to this project?

This allows for the proposed (safest) procedure to offer DANE/TLSA

What alternatives are there, or what are you doing in the meantime to work around the lack of this feature?

Currently the alternatives are:

• Workaround: not follow documented procedure, but request a new certificate, sleep 2x TTL and only then rollover
• Use acme.sh or certbot, possibly in conjunction with https://github.com/nixigaj/cf-tlsa-acmesh

Please link to any relevant issues, pull requests, or other discussions.

Similar discussion in acme.sh https://github.com/acmesh-official/acme.sh/issues/3096

Start by tracing Certmagic’s certificate request and renewal flow, then inspect how certificate resources are saved to disk. Define how the optional next private key is generated, persisted, and selected on a later renewal. Done means the agreed current-plus-next rollover supports safe DANE/TLSA deployment without disrupting existing certificate issuance.