Out now! Auto-renew TLS certificates with DCV Delegation

Taking the Manual Work Out of TLS Certificate Renewals

Every TLS certificate has an expiration date, and before a Certificate Authority (CA) will renew it, the domain owner must prove control over the domain. That proof is called Domain Control Validation (DCV). For Cloudflare customers who manage DNS externally, the industry’s tightening security rules have turned this validation into a recurring manual chore. Cloudflare’s new DCV Delegation feature moves that burden onto Cloudflare, enabling fully automatic certificate renewals for domains whose DNS lives elsewhere.

Certificate renewal already demands attention. As the recommended certificate lifetime shrinks—from 96 months before 2011 down to 13 months in 2020, with 90-day certificates now common from CAs like Let’s Encrypt and Google Trust Services—the DCV process repeats more often. Missing a renewal window can mean downtime or insecure connections, which carries revenue risk and extra work for operations teams. Cloudflare can already auto-renew certificates for domains where it is the authoritative DNS provider, since it can simply add the required records itself. But for customers with external DNS, every renewal previously required fetching and placing a new validation token by hand.

Why DCV Is Getting Harder

DCV requires a domain owner to place a token—either an HTTP file served from a specific endpoint or a DNS TXT record—to prove they control the domain. The CA verifies the token and issues the certificate. To close security holes, the Certificate Authority/Browser Forum (CA/B Forum) has imposed stricter rules that complicate this flow.

• Shorter certificate lifetimes. Reducing certificate validity limits the window in which a compromised certificate or private key can be abused. But it also means more frequent renewals. CAs are also increasingly requiring unique validation tokens for each renewal, so those tokens can’t simply be reused from the previous cycle.
• Wildcards require DNS-based validation. Since May 2021, any certificate covering a wildcard (such as *.example.com) must be validated via DNS TXT records, not HTTP. HTTP validation only proves ownership of a hostname, whereas a wildcard covers the entire subdomain namespace; DNS validation is stronger. This change forces domain owners to add TXT records at their DNS provider for every wildcard renewal.

These practices improve security posture, but they land squarely on administrators who manage multiple domains externally. Every 90 days, someone must fetch tokens and update DNS records for each domain—a schedule that becomes difficult to sustain across more than a handful of domains.

Externally Hosted DNS Hit a Friction Point

Cloudflare has long handled DCV automatically for zones using its authoritative DNS, including the switch to TXT-based validation for wildcards. For customers with “partial” zones—where DNS is hosted elsewhere but traffic still runs through Cloudflare—the wildcard rule meant a manual token fetch and placement every renewal cycle. Cloudflare’s deprecation of DigiCert as a CA also moved these certificates to a standard 90-day lifetime, making the manual work recur quarterly.

The same problem affected SaaS providers using Cloudflare’s SSL for SaaS product, which can issue wildcard certificates for their customers’ custom hostnames. Those providers previously had to retrieve TXT tokens, pass them to their customers, and wait for the tokens to be placed—every 90 days, for every custom hostname.

How DCV Delegation Works

DCV Delegation lets external DNS managers point an acme-challenge CNAME record at Cloudflare. After this one-time placement, Cloudflare can automatically set the DCV tokens on each renewal, with no manual intervention at renewal time.

The CNAME record follows this syntax:

_acme-challenge._<domain.TLD>_ CNAME _<domain.TLD>_._<UUID>_.dcv.cloudflare.com

For a domain like example.com, the record looks like this:

_acme-challenge.example.com CNAME example.com._<UUID>_.dcv.cloudflare.com

Cloudflare then places the required TXT records at the target under dcv.cloudflare.com to complete issuance. As long as the partial zone or custom hostname stays Active on Cloudflare, the DCV tokens are refreshed automatically on every renewal—provided the CNAME record remains in place.

Administrators with partial zones or SSL for SaaS custom hostnames can find enablement instructions in the Cloudflare dashboard and in the documentation for Delegated DCV.

Record Details and Current Limits

The UUID in the CNAME target is unique per configuration. Each partial zone gets its own UUID that applies to all DCV delegation records beneath it. Each SaaS zone also has one UUID used by all custom hostnames within that zone. If a domain is moved to another Cloudflare account, the UUID changes, and the corresponding CNAME records must be updated.

Customers already using Cloudflare as their authoritative DNS provider do not need DCV Delegation. Cloudflare continues to add the required DCV tokens directly on their behalf.

Currently, DCV Delegation supports only one provider. Pointing the CNAME record at Cloudflare reserves the acme-challenge endpoint for Cloudflare’s tokens, preventing you or another CDN from placing tokens at the same location. If you need multiple providers to issue certificates for the same hostname—or you’re issuing separate certificates for an origin server—DCV Delegation is not yet an option. An RFC draft is in progress that would let each certificate-issuing provider use its own distinct “acme-challenge” endpoint, based on the ACME account used for issuance. Once standardized and supported by CAs and CDNs, multi-provider delegation would become possible.