Point a Cloudflare domain at Netlify, get HTTPS, and make local test certificates

The exact DNS records for a Netlify site on a Cloudflare domain, why the orange cloud breaks certificates, and how to make trusted HTTPS certificates for local development.

intermediateUpdated 2026-11-02

You bought example.com at Cloudflare and your site lives on Netlify. This connects the two and gets the padlock working. In the examples, your-site.netlify.app stands for your Netlify subdomain.

How the pieces fit

  • Registrar: where you bought the name (here, Cloudflare).
  • DNS: the records that say where the name points (also Cloudflare here).
  • Host: the server with your files (Netlify).
  • Certificate: proves the site is really yours and enables HTTPS. Netlify gets one automatically from Let’s Encrypt, but only once DNS points straight at Netlify.

1. Add the domain in Netlify

Go to Netlify → your project → Domain management → Add a domain, type example.com and choose to keep DNS where it is (external DNS). Netlify then shows the records it expects.

2. Create the records in Cloudflare

In Cloudflare → your domain → DNS → Records:

TypeNameTargetProxy status
CNAMEwwwyour-site.netlify.appDNS only (grey cloud)
CNAME@ (the bare domain)apex-loadbalancer.netlify.comDNS only

Here’s why these work:

  • The bare-domain record: the root of a domain (the apex) normally can’t be a CNAME. Netlify’s docs recommend an ALIAS, ANAME or flattened CNAME pointing to apex-loadbalancer.netlify.com. Cloudflare supports CNAME flattening at the apex, which is why the second row works.
  • The fallback: if you’d rather not use a CNAME there, Netlify’s fallback is an A record for @ pointing to 75.2.60.5. Netlify calls the CNAME/ALIAS option “more resilient”.
  • Netlify adds the other one: Netlify’s docs note that when you add www, it adds the bare domain as well, so set up both records.

Delete any old A, AAAA or CNAME records for @ and www that point elsewhere, such as a parked page.

3. Turn the orange cloud off

This is the step that trips most people up. Netlify’s troubleshooting docs say that if your site goes through another service such as Cloudflare’s proxy, “you need to disable that routing before we can provision the certificate”, because Netlify has to handle HTTPS itself. Netlify’s support guide recommends keeping Cloudflare for DNS but setting the records to DNS only.

Problems Netlify lists with leaving the proxy on:

  • Netlify can’t provision its own certificate, because it must handle the TLS connection itself.
  • Cloudflare may cache files longer than Netlify does, so new deploys and rollbacks don’t show up right away.
  • Netlify’s analytics only see Cloudflare’s servers as visitors, and split testing stops working.
  • Netlify’s support guide also says never to use a Cloudflare Origin Certificate on Netlify.

After you switch the records to DNS only, the support guide says Netlify keeps retrying the certificate for up to 3 days.

4. Wait, then check

DNS changes can take a while to spread, and Netlify’s docs say it may take a full day. Old records also have to expire from caches (their TTL) before Netlify can validate the new ones. Check from a terminal with dig, which Netlify’s troubleshooting page recommends and which is built into macOS and Linux:

dig +short www.example.com
dig +short example.com

When www returns your Netlify name and the bare domain returns Netlify addresses, go to Domain management → HTTPS → Verify DNS configuration. The Let’s Encrypt certificate usually follows soon after, and it renews automatically.

Bonus: HTTPS for local development

Browsers increasingly need HTTPS (for service workers, secure cookies, camera access), and that includes your own laptop. Two options:

mkcert (easiest, trusted with no warnings)

mkcert by Filippo Valsorda creates a private certificate authority on your computer and makes certificates your browsers trust:

brew install mkcert          # macOS (Firefox users also: brew install nss)
mkcert -install              # create and trust the local CA (once)
mkcert myapp.test localhost 127.0.0.1 ::1

On Windows, choco install mkcert or scoop bucket add extras then scoop install mkcert. You get myapp.test+3.pem and myapp.test+3-key.pem; point your dev server at them.

The README’s warning: the CA key rootCA-key.pem (in the folder mkcert -CAROOT shows) “gives complete power to intercept secure requests from your machine.” Never share it or commit it. To test on an iPhone, the README explains how to install rootCA.pem as a profile and then enable full trust for it.

OpenSSL self-signed (works anywhere, but browsers warn)

openssl req -x509 -newkey rsa:2048 -nodes -days 365 \
  -keyout key.pem -out cert.pem \
  -subj "/CN=myapp.test" -addext "subjectAltName=DNS:myapp.test"

Browsers flag self-signed certificates until you trust them manually. That’s fine for a lab device’s admin page, but it’s why mkcert is nicer. -addext needs OpenSSL 1.1.1 or newer.

More: Domains, DNS & Certificates.

Sources