Use of DANE (IETF RFC 6698) for ACME-client authentication


I want to add Let’s Encrypt certificates to my embedded systems without having access to the web-server configuration. My idea was to use the DNS-based authentication of the ACME-clients. For security reasons my DNS service provider uses a hidden primary nameserver without public APIs (e.g, no RFC 2136) for script access.

With the current approach to create DNS challenge records dynamically per request there is no way to automate certificate renewal.

I suggest to let the ACME-client create a static asymmetric key-pair. The public key is added to the DNS zone manually as a TLSA resource record. The ACME-client uses the private key to authenticate with the CA (e.g. TLS) and the CA checks the private key against the TLSA-RR in the DNS zone.

1 Like

This would require changing/ adding to the “10 Blessed Methods” for domain control validation. These are part of the Baseline Requirements (agreed by browser vendors and CAs) and the Mozilla trust programme policy.

So a post here definitely can’t get it done although you might be able to drum up support to take to those other forums.

1 Like

In addition to @tialaramex's response (Thanks!) about requiring this change to be made at the policy level in the baseline requirements it would also entail a change to the ACME protocol. That's something that would have to be raised for discussion on the IETF ACME protocol mailing list - it wouldn't be something Let's Encrypt would likely implement ourselves even if the baseline requirements allowed it if there wasn't support baked into ACME.

You could CNAME or delegate the _acme-challenge records to a more flexible DNS provider.

Or entirely switch DNS providers.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.