---
title: "Cloudflare Error 1014: The Cert Issued. The Page Didn't Load."
canonical: https://dxdev.com/blog/cloudflare-error-1014-live-test-rewrote-architecture/
datePublished: 2026-06-01
---
One flag. `proxied=False` flipped to `proxied=True` on one DNS record. That is the entire diff that closed the ticket. Getting to that one flag took the better part of an afternoon, two wrong root causes, and a live test domain nobody wanted to risk breaking.

Here's the setup that flag lived in. The production app runs Cloudflare for SaaS. Customer domains are custom hostnames inside a single primary zone, each pointed at a custom origin via `custom_origin_server = cf-origin.<your-zone>`, which resolves to a dedicated fallback IP. A `*.<your-zone>` Origin CA cert covers `SNI=cf-origin`, so the edge can reach the origin and present a valid cert. The open question that day was whether a customer could put their apex, not just `www`, on Cloudflare through ALIAS or CNAME flattening.

To test it, I moved a test domain onto a second Cloudflare account, a different account from the primary zone, and grey-CNAMEd the apex to the SaaS fallback hostname. Cloudflare provisioned a cert. The cert issued. I called it done and moved on.

I never loaded the page. When I finally did: `Error 1014, CNAME Cross-User Banned.`

## Theory one, thrown out fast

A cert issuing through Cloudflare for SaaS proves exactly one thing, that DNS ownership validation passed. It says nothing about whether a request to that hostname returns a page. That gap between "the cert exists" and "the page serves" is the whole reason this ticket ate an afternoon instead of ten minutes.

## Theory two, the one that almost worked

The second theory is the one worth sitting with, because it sounded better than the first and was still wrong. 1014 is named "CNAME Cross-User Banned." I had grey-CNAMEd across two different Cloudflare accounts, so I reasoned the ban was a permanent, structural property of cross-account CNAMEs. Test method invalid, throw it out, retest with a registrar that supports true ALIAS instead. That story cited the exact error name and reached a tidy conclusion about methodology. It also would have killed a test that had nothing wrong with it.

A side-by-side diff cracked it.

I had two domains in nearly identical configurations behaving differently, so I stopped guessing and put them side by side. Domain A, a customer not on Cloudflare, had the identical grey `cf-origin` custom-origin record. Its hostname status was **active**, with a warning attached: `The custom origin hostname you specified is a gray clouded DNS record. Please update the record to be proxied.` Domain B, the CF-on-CF customer, had the same grey `cf-origin` record, but its hostname stayed stuck: `The custom origin hostname you specified does not exist on Cloudflare as a DNS record (A, AAAA or CNAME) ... in your zone: <your-zone>.`

Same `custom_origin_server` value. Same record. One account tolerated it as a warning. The other treated it as if the record didn't exist. The account boundary was never the variable. The cloud color was.

The fix was the one-flag flip: `cf-origin` from DNS-only to proxied. The app commit that closed it out reads:

```
96557835f1 cf-origin must be PROXIED, not DNS-only
(CF for SaaS requires proxied custom origin; cross-account/CF-on-CF
customers fail validation on grey; verified 2026-06-01)
```

Re-validating the domain moved it off the stuck state to `active_redeploying`. `www` lagged behind, its own grey CNAME hadn't propagated yet, and once it caught up both records served through Cloudflare. Domain A had never broken in the first place.

Here's the part that made the afternoon worth it. Two of our own locked docs, the architecture doc and the origin-server reference doc, both said `cf-origin` was supposed to be DNS-only. That was the documented design, wrong since before this ticket existed. It survived every prior test because every prior test ran against non-CF customers, and grey tolerates that path with nothing worse than a warning nobody reads. The correction landed in both docs the same afternoon, alongside the plan-of-record for the wider Cloudflare migration this ticket sits inside.

The test domain is still live, left in place on purpose as a reference case. I still don't have a general answer for how many other "documented but never actually re-verified against the edge case" settings are sitting in that same architecture doc, correct on paper, untested against the one customer type that would break them.