Automation of X.509 certificate issuance is an important step towards preparing for upcoming validity reduction to 47 days in 2029. The use of ACME with, for example, certbot to achieve this is well tested and robust and, for many use-cases, is seamlessand worry-free.
When used with Let’s Encrypt there are two options for validation (the proof that the requestor is in suitable control of the requested name(s)):
- HTTP–01: This challenge requires the requestor to publish a given random value (nonce) at a specific location in a trusted part of the webserver’s document root (at /.well-known/acme-challenge). This challenge requires that the Certificate Authority (eg. Let’s Encrypt) can access the web server over HTTP to validate the challenge. This is, usually, the simplest challenge to use and is the default for most ACME clients.
- DNS–01: This challenge requires the requestor to publish a similar given random value at a specific location within the DNS zone (_acme-challenge.<requested_name>).
Other methods are available and some are in development, but those above are the most prevalent methods currently in use.
Why use DNS–01?
In some situations, it’s not practical to use the HTTP–01 challenge such as:
- The service is not reachable from the public internet.
- The service runs on a cluster or load–balanced platform where reliably publishing the challenge file on all nodes is difficult.
- You need a certificate for a non–HTTP service (e.g., mail, VPN, SIP, MQTT) or a wildcard domain.
In these cases, DNS–01 provides an effective alternative: instead of hosting a token on a web server, the ACME client publishes a TXT record in the authoritative DNS zone. The Certificate Authority then queries DNS to verify control.
Most DNS platforms support authenticated programmatic updates (such a RFC 2136 or other proprietary APIs), often with fine–grained controls limiting which records may be modified. This allows organisations to tightly scope which ACME clients may request which
certificates.
When programmatic DNS updates are not available, most ACME clients support a manual DNS challenge mode. However, this introduces a human step into the process.
Drawbacks of manual method
Because the DNS record must be created manually for each issuance or renewal, this method cannot be used in a “set–and–forget” fashion. Every renewal cycle requires human intervention, defeating full automation.
Use of DNS–01 with Jisc PNS
Until Jisc’s Primary Nameserver Service is able to support programatic updates to zones, the use of DNS–01 challenge is only possible using the manual method.
In this workflow:
- The operator runs certbot (or another ACME client) with the --manual and DNS–01 options.
- The Certificate Authority issues a challenge nonce.
- The ACME client pauses and displays the TXT record that must be published.
- The operator manually adds the record to the DNS zone via PNS.
- Once published, the operator returns to the ACME client and continues the process.
Future
A new verification method is in development which will allow the use of DNS verification without a fresh nonce each renewal cycle.
The DNS–ACCOUNT–01 will allow any domain name to delegate its domain validation to more than one service through unique per ACME account DNS records effectively removing the real–time link between a request being made and a DNS update being published. Instead, a persistent authorisation will be present in the DNS for the requesting
server/service.
This request method is not yet generally available but is intended to improve this workflow.
Typical flow for manual certificate request using DNS–01 challenge
A typical flow of actions for the DNS–01 method when making manual updates to DNS:
- Register for an ACME account with the Certificate Authority
- Request a new certificate using the DNS–01 method
- ACME client performs initial handshake with Certificate Authority
- Certificate Authority provides nonce in response
- ACME client presents nonce to requesting operator
- Operator updates the relevant DNS zone to publish the supplied nonce in the given DNS recordset
- Pause to allow DNS propagation to complete (this will vary by deployment and configuration but is typically less than a minute)
- Operator allows the automatic process to continue
- Certificate Authority issues certificate and ACME client performs any other actions as normal
- Operator tidies up the DNS record from the recordset
Example request for new certificate
$ certbot certonly --manual -d testcert.example.ac.uk --preferred-challenges=dns
...
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name:
_acme-challenge.testcert.example.ac.uk.
with the following value:
cOVnVQwdMEAXpTjjZHnPL7AMQ0gDf78T3W7_exfO4W4
...
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
In a separate window, check the DNS record is available from the authoritative name
server(s):
$ dig +short ns example.ac.uk
ns0.example.ac.uk.
ns1.example.ac.uk.
...
$ dig +short txt _acme-challenge.testcert.example.ac.uk @ns0.example.ac.uk
"cOVnVQwdMEAXpTjjZHnPL7AMQ0gDf78T3W7_exfO4W4"
The nonce should appear in the results. If it doesn't, wait a moment and try again until it
does.
Return to the original certbot window:
# Press enter
Successfully received certificate. You should now remove the DNS TXT record.
Renewing the certificate
Repeat the above process using the same parameters and create/update the DNS record with the new nonce.
