Delegated DCV with a CNAME

What Domain Control Validation is

Before any certificate authority issues a certificate, it must confirm that the requester actually controls the domain. That check is Domain Control Validation (DCV). Traditional ACME validation does this with a challenge you have to satisfy at issuance time — an HTTP file served from the site, or a _acme-challenge TXT record placed in DNS — and it repeats that dance on every renewal.

That’s the part that breaks in practice: a renewal comes due, the challenge can’t be satisfied (the file’s gone, the record was cleaned up, nobody remembered), and the certificate lapses.

Why a single delegated CNAME

AutoCertify uses delegated DCV instead. Rather than answer a fresh challenge each time, you delegate the answer once: you add a CNAME that points _acme-challenge.<domain> at a Cloudflare DCV target. From then on, the validation record lives on Cloudflare’s side of that pointer.

• Add it once. The CNAME is static — it never changes between renewals, so you set it a single time.
• Every renewal self-validates. Because the challenge is answered behind the delegated target, AutoCertify re-validates and re-issues with zero further DNS changes from you.
• No expiry surprises. Contrast this with repeated HTTP or DNS challenges, where any renewal can fail if the challenge isn’t satisfiable at that moment.

The record you add

AutoCertify generates the exact record when you create the domain (and you can re-fetch it any time from GET /v1/domains/:domainId/delegation-record). It looks like this:

Type    CNAME
Name    _acme-challenge.shop.example.com
Value   shop.example.com.a1b2c3d4.dcv.cloudflare.com
TTL     300

• Name / host — _acme-challenge.<your domain>. Some registrars want the full name; others want just the _acme-challenge label relative to the zone. Match whichever form your provider expects.
• Value / target — the Cloudflare DCV hostname (…dcv.cloudflare.com). Paste it exactly, with no trailing edits.
• Type — always CNAME.

Check it before you verify

DNS is a cache; a new record isn’t visible everywhere the instant you save it. Before calling verify, confirm the record resolves from your own machine:

# Confirm the delegation record resolves to the Cloudflare DCV target.
dig +short CNAME _acme-challenge.shop.example.com
# → shop.example.com.a1b2c3d4.dcv.cloudflare.com

# Windows / no dig:
nslookup -type=CNAME _acme-challenge.shop.example.com

When the lookup returns the Cloudflare DCV target, ask AutoCertify to verify. A successful check auto-triggers issuance:

curl -X POST https://api.autocertify.net/v1/domains/dom_8Qp3v1c7/verify-delegation \
  -H "Authorization: Bearer $AUTOCERTIFY_TOKEN"

TTL guidance

Set a low TTL of 300 seconds (five minutes). A short TTL means that if you ever do need to adjust the record, the change propagates quickly — and it costs you nothing, because the record is static and never actually changes after setup. Avoid very long TTLs (a day or more); they only slow down the first successful check.

Apex vs subdomain

Delegated DCV works the same for an apex domain (example.com) and for any subdomain (shop.example.com, app.example.com). In both cases the record you add is _acme-challenge.<that exact hostname> — for the apex that’s _acme-challenge.example.com. Securing several hostnames? Add one delegation CNAME per hostname; there’s no shared or wildcard shortcut.

Common registrars

The record is a plain CNAME, so it works at every DNS provider. A few notes on where to put it:

• GoDaddy, Namecheap, Squarespace / Google Domains, Wix — open the domain’s DNS / records screen, add a new CNAME, paste the host and value, set TTL to 300 (or the lowest option offered).
• Cloudflare — add the CNAME with the proxy turned off (grey cloud, “DNS only”). A proxied _acme-challenge record won’t resolve to the delegated target.
• Not sure who runs your DNS? Create a verification link and send it to your web person or host — they add the one record without touching your account.

Troubleshooting

Record not detected

Re-run the dig / nslookup check above. If it returns nothing, the record isn’t saved correctly — the most common causes are an extra copy of your domain in the host (e.g. _acme-challenge.shop.example.com.shop.example.com because the provider appends the zone automatically), a typo in the target, or the record saved as the wrong type. Fix it, wait for the TTL, and call verify again.

Propagation delay

A brand-new record can take a few minutes to become visible, occasionally longer on slow providers. verify-delegation is safe to call repeatedly — it simply reports pending until the record resolves, then flips to verified and starts issuance.

CNAME flattening & conflicts

Some providers “flatten” a CNAME at the apex into an address record. That’s fine for your website’s root, but the _acme-challenge record must stay a real CNAME to the DCV target — don’t let it be flattened or replaced. Also make sure no existing _acme-challenge record (from a previous SSL tool) is left behind conflicting with the new one; remove the stale entry.

Wildcards are not supported

AutoCertify issues per-hostname certificates and does not support wildcards. Requesting one (wildcard: true) returns 400 wildcard_not_supported. To cover several subdomains, add a domain and delegation CNAME for each hostname.