DANE+TLSA record generation

[jvanasco]

@webprofusion

If you use Certbot to only renew the certificate (files) and not for any deployment then you can entirely separate the concerns and completely avoid modifying certbot at all.

I am 100% against modifying Certbot and/or leveraging private methods in 3rd party projects. My comment about "standard certbot" was meant to address standard usage and installation patterns.

The most compatible ways to use Certbot to eliminate the race conditions, IMHO, is to either:

• use --config-dir to completely isolate the DANE certificates from the normal system
• use a custom --cert-name to control what names the DANE certs use, (so there could be --cert-name=dane-mail.example.com that is isolated from the default mail.example.com cert used for https services).

Remember, with DANE, the DNS record has a hash of the active certificate that must match the https certificate. So these two services are tightly coupled and need to be kept in sync.

While it would be possible to just use the default Certbot install and cert names, that would require a lot of analysis and bookkeeping in the DANE deployment tools, you still have the issue where the initial phase of updating a DANE certificate (certbot renew) can cause the non-DANE processes (e.g. apache/nginx) to detect a change in a certificate they use and reload, and you still have an issue where someone (or automated systems) deciding to renew the HTTPS cert for mail.example.com can likely impact the DANE system if that is mid-update. While it is certainly possible to orchestrate everything within a single standard Certbot installation, the amount of coding and bookkeeping/state-maintaining to do this properly quickly becomes onerous.

Using --config-dir will completely decouple the DANE system from the standard install. Using --cert-name should offer enough isolation, though it would probably need to be configured to not renew automatically as well (as the daneupdate binary would be invoking it on demand or via cron).

@schoen

For my own interest (as I'm no longer part of the Certbot development team), is it possible to do this in a fully generic way for every issued certificate, or is there anything specific about the host system or deployment model? For example, does it need to encode TCP port numbers or protocol IDs in some way? I haven't really looked at the details of DANE in many years.

The DANE record contains encoded validation instructions: DNS-based Authentication of Named Entities - Wikipedia

It could possibly be handled by config/commandline defaults.

I think 2 1 1 and 3 1 1 are the current recommendations. But then trust anchors are recommended to be pinned, which changes.

These are some of the better recent topics (in terms of getting into the technical bits):

Short chain and DANE

N…

Understanding SMTP DANE implementation options

H…