Summary

  • DNS-01 proves that one ACME account holds its account key and can place the required digest at the validation name seen by the CA. A CNAME or NS delegation can give that narrow capability to a party that does not control the apex, application or business relationship.
  • Issuance authority, wildcard scope, CSR names, certificate storage, deployment, CT observation and revocation are separate states. Removing a TXT record—or a vendor login—does not retire all of them.

The offboarding that ended one layer too early

The company did several things correctly. It disabled the vendor's identity-provider account, deleted its CI secret and removed its role in the certificate store. Its asset register showed no active integration. Yet the parent zone still sent _acme-challenge.example to a validation zone the vendor controlled.

That delegation was not decorative. Let's Encrypt documents that its DNS-01 lookup can follow CNAME or NS delegation to another zone. A party holding the corresponding ACME account key could receive a fresh challenge, compute the required value and answer from the delegated surface. A wildcard order could then validate without access to the web servers.

This is a synthetic control failure, not a claim about a particular company or CA incident. Its value is architectural: removal from an application does not remove authority deliberately placed in DNS.

What the digest actually joins

RFC 8555 does not accept an arbitrary TXT password. The ACME server supplies a token containing at least 128 bits of entropy. The client combines that token with its ACME account key to form a key authorization, hashes it with SHA-256 and publishes the base64url digest at _acme-challenge.<identifier>.

Two predicates meet. The requester can sign as the ACME account, and it can make the expected DNS value visible at the chosen validation name. Change the account key or token and the digest changes. Copying an old TXT value into another order is not the same proof.

An ACME authorization records the server's decision that an account may represent an identifier. A valid authorization has an expiry. It can later expire, be deactivated or be revoked. The useful audit sentence is therefore not “the domain was validated.” It is: account A held authorization Z for identifier I, using challenge method M, from validation observation V until expiry E.

The challenge label may be the whole delegated power

DNS-01 was designed so certificate automation need not expose the web application. That separation is valuable. A tightly scoped service can update only the challenge namespace and copy the finished certificate toward its destination.

The same separation changes the ownership question. Control of _acme-challenge can be sufficient for issuance through a CA that follows that delegation, even when the controller cannot alter the apex A, MX or NS records. DNSSEC can authenticate the delegation and answer perfectly. It proves that the signed namespace made that choice; it cannot decide whether the vendor contract should still exist.

Record every CNAME and NS hop, the authoritative account behind the final zone, DNSSEC state, TTL and the answers seen from the CA's relevant vantage points. A screenshot of the parent control panel is not evidence of the path that ran.

Wildcard is a scope decision, not a star in the TXT name

For a wildcard order, RFC 8555 returns an authorization for the base domain without the *. prefix and marks it with wildcard: true. The challenge name can therefore look like a base-domain validation while the resulting certificate covers a wildcard identifier.

Operations must preserve that flag beside the order and CSR. Otherwise a review sees _acme-challenge.example and understates the certificate scope. Let's Encrypt documents DNS-01 as its route for wildcard certificates; that is its current behavior, not evidence that every ACME server implements every challenge or policy in the same way.

RFC 9444 adds an explicit optional model in which server policy may accept an ancestor-domain authorization for subdomain certificates. Support is not universal. The lesson is narrower: log the authorization identifier the server actually issued, not the name an observer assumes from the order.

The CSR closes one door, not every door

At finalization, RFC 8555 requires the CSR to contain the exact identifier set from the original order. An extra SAN cannot be smuggled into the CSR after validation. That is an important closure rule.

It does not say who should possess the certificate private key, where the certificate may be installed or which application role it may unlock. Nor does issuance prove deployment. Keep order, authorization, CSR, issuance, storage, installation and first observed handshake as distinct events with distinct owners.

CAA can narrow the issuance surface further. RFC 8657 defines optional accounturi and validationmethods parameters for issue and issuewild. They work only when the named CA recognizes them consistently, and they do not replace domain validation. The RFC also warns that CAA restrictions can be superseded when subdomain control is delegated. A policy record is not a substitute for deleting the delegation that grants the capability.

Cleanup is not revocation

Deleting the TXT record ends one answer. Removing a CNAME or NS delegation ends one route after caches converge. Deactivating an authorization or ACME account changes another state. None of those actions alone revokes a certificate already issued.

ACME defines a separate signed revocation request. The issuing account, an account authorized for every identifier in the certificate, or the certificate private key can provide revocation authority under the protocol. OCSP then exposes a separate good, revoked or unknown status surface. Incident response must name which of these events occurred and when clients could observe it.

Certificate Transparency supplies another independent signal. A log can make unexpected issuance visible and auditable, but an SCT is not ordinary certificate validation and log inclusion does not invalidate a certificate. Monitoring creates a trigger; a CA and relying parties still need an effective response.

Test the predicates one by one

Negative tests are more useful than a green renewal dashboard. Remove application access while leaving challenge delegation and ask whether a fresh order can still succeed. Rotate the ACME account key while publishing a digest derived from the old key. Put an extra SAN in the CSR. Validate a wildcard and exact name concurrently. Remove the authoritative delegation, then observe recursive caches before and after TTL expiry.

Finally, issue a certificate but do not deploy it; then delete the challenge record and confirm that the certificate's status has not magically changed. Each test should fail at the boundary it claims to protect.