nginx/nginx-acme

[RFC8555] DNS-01 Challenge

Opened this issue · 7 comments

bavshin-f5 commented

Feature Overview

Support identifier authorization using HTTP-01 challenge, as specified in RFC8555 Section 8.4

This one is problematic, because there are two ways to implement it and both are inconvenient:

  • DNS listener in the NGINX itself, and a CNAME delegation of _acme_challenge subdomains to the NGINX address.
    It's doable, with a bit of required configuration in the stream block, but we need to carefully consider the security aspects of the feature.
  • API client for popular DNS hosting and dynamic DNS services.
    Too much code to have in the NGINX itself, there's a dozen of DNS authenticator plugins in Certbot and who knows how many other services we'll need to support.

A mechanism of external challenge handlers (HTTP, FastCGI, or other socket-based protocol) may neatly solve this one, allowing to offload the logic to an external helper in Rust.

Alternatives Considered

No response

Additional Context

DNS-01 is the only challenge type that allows to issue wildcard certificates.

jc21 commented

Hi, I manage the Nginx Proxy Manager project, and I am very much looking forward to ditching Certbot once DNS-01 is supported.

From experience, the community wants DNS provider support for a lot more providers than you may think. My project supports 75 Certbot DNS plugins. Acme.sh supports more than 170.

bavshin-f5 commented

To be clear, I did not intend to add a DNS provider API client to this project.

The module schedules certificate renewals as a background task in a worker process, the same kind of process that handles incoming connections. It is unreasonable from the security perspective to keep the credentials for DNS providers anywhere near this process, no matter how confident we are in the safety of our code.
It also might be too overwhelming to maintain even a small subset of popular DNS provider adapters with our small team. But that's totally not the main reason.

A hook for invoking an external helper, such as an acme-dns client or a thin wrapper over lego's library of solvers would be the most likely outcome here. The feedback I've seen so far suggests that it is way more important than a DNS listener due to being suitable for internal network deployments.

  • 👍6
cschug commented

Using lego to obtain ACME certificates would be great as it already has support for a wide range of providers and also supports CNAME delegation by default.

  • 👍2
junlintianxiazhifulinzhongguo commented

+1 I also support issuing via DNS-01 method

  • 👎4
junlintianxiazhifulinzhongguo commented

I don't know if there is an implementation method, so I haven't seen any instructions on how to use it

  • 👎1
evlli commented

whoever wants to implement this, I can recommend looking at https://github.com/famedly/acmed-hook-rfc2136/blob/main/src/main.rs

yryz commented

@bavshin-f5 You can pay attention to this persistent verification feature (cabforum/servercert#608), which is more friendly for the scenario where nginx needs to issue wildcard certificates and is the best alternative to an integrated DNS solution. It is expected to pass through voting this year, and CAs will generally follow up quickly, so it should be applicable next year.

Security Benefits

  1. Reduced DNS Credential Risk: Eliminates need for overly powerful DNS credentials on web infrastructure
  2. No Third-Party Delegation: Avoids delegating _acme-challenge management to external services
  3. Enhanced Transparency: Persistent records enable better monitoring and misuse detection
  4. Enterprise LAN Support: Enables HTTPS for internal-only domains where HTTP/TLS-ALPN validation isn't possible
  • 👍5
  • 🎉3