# ACME dns-01 TXT computer

> Compute the TXT record for an ACME dns-01 challenge, from the token and account key.

- Tool: https://ronutz.com/en/tools/acme-dns01
- Family: Certificates & PKI

---

## What it does

Compute the exact TXT record you publish to pass an ACME dns-01 challenge. Paste the challenge token and your ACME account key, as a JWK or as its thumbprint, and it returns the `_acme-challenge` record name, the value to put in the TXT record, and the intermediate key authorization and thumbprint it was derived from. Everything runs in your browser using the native Web Crypto SHA-256; your key never leaves the page, and only its public members are used.

## Why dns-01 exists

ACME (RFC 8555) automates certificate issuance by challenging you to prove control of a domain. The dns-01 challenge does this through DNS: you publish a specific TXT record under the domain, and the CA looks it up. Unlike http-01, dns-01 needs no inbound connection to your server, so it works behind a firewall or load balancer, and it is the only challenge type that can validate a wildcard name.

## The computation

The record value is not arbitrary; the CA recomputes it from your account key, which is what ties the challenge to you. The chain is three steps. First, the SHA-256 thumbprint of your account public key is taken in the canonical form defined by RFC 7638, and base64url-encoded. Second, the key authorization is formed by joining the token and that thumbprint with a dot: `token.thumbprint`. Third, the TXT record value is the base64url of the SHA-256 digest of the key authorization. The record is published at `_acme-challenge.<domain>`; a wildcard such as `*.example.com` is validated under `_acme-challenge.example.com`.

## Only your public key is used

The RFC 7638 thumbprint is computed over just the required public members of the key: for an EC key the curve and the x and y coordinates, for an RSA key the modulus and exponent. Your private key is never needed to compute the record, so you should paste only the public JWK. If a full key is pasted, its private fields are ignored and never displayed.

## Using it

Enter the token from the challenge and your account key, and optionally the domain to see the full record name. Publish the returned value as a TXT record at `_acme-challenge.<domain>`, wait for it to propagate, then let your ACME client continue. The same token and key always produce the same value, so you can verify what your client is publishing against what this tool computes.

## Standards and references

- [RFC 8555 — Automatic Certificate Management Environment (ACME)](https://www.rfc-editor.org/rfc/rfc8555) - the ACME protocol; key authorization (§8.1) and dns-01 (§8.4)
- [RFC 7638 — JSON Web Key (JWK) Thumbprint](https://www.rfc-editor.org/rfc/rfc7638) - the SHA-256 JWK thumbprint and its canonical member ordering
- [RFC 4648 — The Base16, Base32, and Base64 Data Encodings](https://www.rfc-editor.org/rfc/rfc4648) - base64url (§5), the encoding used for the token, thumbprint, and TXT value

## Related reading

- [ACME on BIG-IP: from DevCentral scripts to a native client](https://ronutz.com/en/learn/bigip-acme-certificate-automation.md): How Let's Encrypt and other ACME certificate automation works on F5 BIG-IP: the native ACMEv2 client introduced in BIG-IP 21.1.0 (provisioning, renewal, and deployment for any ACMEv2 CA), the community dehydrated-based solutions that came before it, BIG-IQ's centralized Let's Encrypt CA management profile, and where the shared ACME concepts and rate limits fit.
- [ACME on FortiGate: a built-in client for the box's own certificate](https://ronutz.com/en/learn/fortigate-acme-certificate-automation.md): How FortiOS's native ACME support obtains and renews a Let's Encrypt certificate for the FortiGate itself: the public-IP and FQDN requirements, the single-name SAN constraint, the TLS-ALPN-01 and HTTP-01 challenges (and which FortiOS versions support them), the GUI and CLI configuration, and how this differs from BIG-IP's native client.
- [ACME: how certificates issue and renew themselves](https://ronutz.com/en/learn/acme-protocol.md): How the ACME protocol automates certificate issuance end to end: the account, the order, the three challenge types, the dns-01 record you publish, and the finalize-and-download step that produces the certificate.
- [Let's Encrypt: the free CA and its rate limits](https://ronutz.com/en/learn/lets-encrypt.md): What Let's Encrypt is, why its certificates are short-lived, and how its rate limits actually work: the per-registered-domain and per-account limits, the exact-set and authorization-failure limits, and why ARI renewals are exempt from all of them.
- [Public suffixes and the registered domain (eTLD+1)](https://ronutz.com/en/learn/public-suffix.md): What a public suffix (eTLD) and a registered domain (eTLD+1) are, why you cannot compute them by taking the last two labels, how the Public Suffix List algorithm resolves them, and where the boundary matters: certificate rate limits, cookies, and same-site.
