News for hackers. Stuff that matters.
Re:Nginx Introduces Native Support for Acme Protocol by andreashaerter on Wednesday August 13, 2025 @06:18PM (#44894550)
CNAMEs. I do this for everything. Example:

1. Your main domain is important.example.com with provider A. No DNS API token for security.

2. Your throwaway domain in a dedicated account with DNS API is example.net with provider B and a DNS API token in your ACME client

3. You create _acme-challenge.important.example.com not as TXT via API but permanent as CNAME to _acme-challenge.example.net or _acme-challenge.important.example.com.example.net

4. Your ACME client writes the challenge responses for important.example.com into a TXT at the unimportant _acme-challenge.example.net and has only API access to provider B. If this gets hacked and example.net lost you change the CNAMES and use a new domain whatever.tld as CNAME target.

acme.sh supports this (see https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo... this also works for wildcards as described there), most ACME clients do.

I also wrote an acme.sh Ansible role supporting this: https://github.com/foundata/ansible-collection-acmesh/tree/m.... Example values:

  [...]
  # certificate: "foo.example.com" with an additional "bar.example.com" SAN
  - domains:
    - name: "foo.example.com"
      challenge:  # parameters depend on type
        type: "dns"
        dns_provider: "dns_hetzner"
        # CNAME _acme-challenge.foo.example.com => _acme-challenge.foo.example.com.example.net
        challenge_alias: "foo.example.com.example.net"
    - name: "bar.example.com"
      challenge:
        type: "dns"
        dns_provider: "dns_inwx"
        # CNAME _acme-challenge.bar.example.com => _acme-challenge.example.net
        challenge_alias: "example.net"
  [...]
Re:Nginx Introduces Native Support for Acme Protocol by theschmed on Wednesday August 13, 2025 @08:10PM (#44895404)
Thank you for this clear explanation.
Re:Nginx Introduces Native Support for Acme Protocol by teruakohatu on Thursday August 14, 2025 @01:49AM (#44897132)
This has blown my mind. Its been a constant source of frustration since Cloudflare stubbornly refuses to allow non-enterprise accounts to have a seperate key per zone. The thread requesting it is a masterclass in passive aggressiveness:

https://community.cloudflare.com/t/restrict-scope-api-tokens...

Re:Nginx Introduces Native Support for Acme Protocol by Jnr on Thursday August 14, 2025 @02:18AM (#44897268)
When setting up the API key, use the "Select zones to include or exclude." section. Works fine on the free account.
Re:Nginx Introduces Native Support for Acme Protocol by teruakohatu on Thursday August 14, 2025 @05:25AM (#44898456)
I should have clarified, you can’t for subdomains on a non-enterprise account.
Re:Nginx Introduces Native Support for Acme Protocol by Kovah on Thursday August 14, 2025 @02:11AM (#44897239)
Could you elaborate on the separate key per zone issue? It's possible to create different API keys which have only access to a specific zone, and I'm a non-enterprise user.
Re:Nginx Introduces Native Support for Acme Protocol by johnmaguire on Thursday August 14, 2025 @02:24AM (#44897310)
This allows you to restrict it to a domain (e.g. example.com) but not a sub-domain of that domain.
Re:Nginx Introduces Native Support for Acme Protocol by Kovah on Thursday August 14, 2025 @03:05AM (#44897555)
Ah I see, thanks for the clarification!