RedirectIQ

How We Eliminated SSL Certificate Expiry Using Cloudflare DCV Delegation

·4 min read

If you're building a SaaS product on Cloudflare for SaaS, there's a good chance you're shipping certificates that will silently expire in 90 days. Not because of anything you did wrong — because the default SSL validation method works exactly as documented. It just wasn't designed for hands-off renewals.

We hit this ourselves at RedirectIQ. We dug into Cloudflare's certificate management docs and found a feature called DCV delegation that most implementations skip entirely. Here's how it works and how we implemented it.

---

The default TXT method and why it breaks

When you provision a custom hostname via Cloudflare for SaaS, the default SSL validation method is TXT. Cloudflare issues your customer an _acme-challenge TXT record they need to place in their DNS:

_acme-challenge.theirdomain.com  TXT  "abc123rotating..."

This works fine for initial issuance. The problem is the TXT value rotates on every renewal cycle — approximately every 90 days. When Cloudflare goes to renew the cert, it generates a new challenge value. If the customer's DNS still has the old TXT value, validation fails. The cert expires. Their redirects stop working over HTTPS.

There's no automatic retry, no graceful fallback, no early warning by default. It just breaks.

The customer experience: they added one DNS record, everything worked, then 90 days later their site started throwing SSL errors. From their perspective, nothing changed — and that's exactly the problem.

---

What DCV delegation does

Cloudflare's DCV delegation feature flips this model. Instead of a TXT record with a rotating value, the customer adds a permanent CNAME at _acme-challenge:

_acme-challenge.theirdomain.com  CNAME  theirdomain.com.{uuid}.dcv.cloudflare.com

That CNAME target is controlled by Cloudflare. When renewal time comes, Cloudflare places a new TXT value at the dcv.cloudflare.com subdomain on its own — no customer DNS update required. The CNAME stays in place permanently and Cloudflare resolves the challenge through it on every renewal cycle.

From Cloudflare's own docs:

> *"DCV Delegation requires your customers to place a one-time record at their authoritative DNS that allows Cloudflare to auto-renew all future certificate orders, so that there is no manual intervention from you or your customers at the time of the renewal."*

One record. Set once. Renews forever.

---

How to implement it

The dcv_delegation_records field is returned in the Cloudflare custom hostnames API response — both on initial creation (POST) and on status reads (GET). It's not used by default; you have to read it and surface it to customers instead of the TXT validation_records.

On provisioning (POST /zones/{zone_id}/custom_hostnames):

{
  "ssl": {
    "dcv_delegation_records": [
      {
        "cname": "_acme-challenge.theirdomain.com",
        "cname_target": "theirdomain.com.47f63d913f6fd74b.dcv.cloudflare.com"
      }
    ]
  }
}

Note: the fields are cname and cname_target — not cname_from/cname_to as some third-party examples show. We learned this the hard way by reading a wrong field name from an API response that returned null and wondering why nothing was working.

What to tell customers:

Give them the CNAME record instead of the TXT record. For Cloudflare DNS users specifically, remind them the record must be DNS only (grey cloud) — proxying it breaks the delegation chain.

For existing active hostnames:

Cloudflare only returns dcv_delegation_records when the hostname is in pending_validation state, not while the cert is active. So for customers with already-active certs, you won't be able to backfill the delegation CNAME until their cert comes up for renewal (~30 days before expiry) and the hostname re-enters the pending state.

---

What we shipped in RedirectIQ

All new domains added to RedirectIQ now use DCV delegation by default. The DNS Setup section shows the permanent CNAME instead of the rotating TXT:

  • One-time setup, three DNS records total: ownership TXT, DCV delegation CNAME, traffic CNAME
  • Existing active domains see an in-app notice with the CNAME record as soon as Cloudflare makes it available during their next renewal cycle
  • Domains where Cloudflare has already auto-upgraded to HTTP validation (another mechanism for proxied domains) show no SSL record at all — CF handles it entirely

The result: once set up, no customer should ever see an SSL error due to a failed renewal.

---

Why most implementations miss this

DCV delegation is buried in Cloudflare's certificate management docs under a sub-page for custom hostnames. The default provisioning examples use validation_records (the rotating TXT), which works fine for demos and initial testing. Most implementations never revisit it.

The cost of not revisiting it is quiet: everything looks fine until 90 days after launch, at which point customer certs start expiring and support tickets start arriving.

If you're building on Cloudflare for SaaS, read the DCV delegation docs and ship it before your first customer cert renews.