CA Bundle for Cloudflare: Origin Certificates and the Chain Explained

The CA bundle for Cloudflare is the root certificate that signs Cloudflare origin certificates, and you need it only when something must verify that certificate, because visitors never see it and the Cloudflare proxy already trusts it.

Most confusion comes from mixing three different certificates that all get called the CA bundle. Separate them and the setup is short.

Table of contents

• Three certificates people confuse
• Generating and installing the origin certificate
• Where the CA bundle itself comes in
• Verifying the chain from the command line
• Common errors and what they mean
• Renewals, expiry and when to use a public certificate
• Authenticated origin pulls: proving the request came from the proxy
• How this fits the rest of the stack
• FAQ

Three certificates people confuse

When you proxy a site through Cloudflare there are three distinct certificates in play, and posts that blur them cause real outages.

The first is the edge certificate. It is what visitors’ browsers see. Cloudflare issues and renews it automatically, you do not install it anywhere, and it has nothing to do with your origin.

The second is the origin certificate that your own server presents to Cloudflare. It encrypts the leg between Cloudflare’s network and your host. You can use a certificate from a public authority, or you can generate a Cloudflare origin certificate in the dashboard.

The third is the CA bundle, meaning the chain of authority certificates that vouch for the origin certificate. For a Cloudflare origin certificate, the relevant piece is Cloudflare’s origin CA root.

The key fact from the documentation is that origin CA certificates are trusted only by Cloudflare’s proxy. A browser connecting directly to your origin would reject one. That is intended, and it is why they are suitable only when your origin receives traffic exclusively from proxied records.

So when someone asks for a CA bundle, ask what is trying to verify what. If nothing on your side validates the chain, you do not need it.

Generating and installing the origin certificate

In the dashboard, open the SSL/TLS section for the zone, choose origin server, and create a certificate. You pick the hostnames to cover, a key type, and a validity period. Cloudflare returns two blocks of text: the certificate and the private key. The private key is shown once, so copy it immediately and store it securely.

Save them on your server, with the key readable only by root:

sudo mkdir -p /etc/ssl/cloudflare
sudo nano /etc/ssl/cloudflare/origin.pem   # paste certificate
sudo nano /etc/ssl/cloudflare/origin.key   # paste private key
sudo chmod 600 /etc/ssl/cloudflare/origin.key

Then point your web server at them. For Nginx:

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/cloudflare/origin.pem;
    ssl_certificate_key /etc/ssl/cloudflare/origin.key;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

Reload with sudo nginx -t && sudo systemctl reload nginx. Finally, set the SSL/TLS mode to Full (strict) so Cloudflare verifies the origin certificate rather than accepting anything. Without that step you have encryption in name only.

Where the CA bundle itself comes in

You need the root certificate in a few specific cases. One is Authenticated Origin Pulls and similar setups, where the origin verifies that requests come from Cloudflare. Another is when software on your server connects to something presenting a Cloudflare origin certificate and must verify it. A third is when a hosting panel asks for a CA bundle field next to the certificate.

Cloudflare publishes its origin CA root certificates on the origin CA documentation page, in formats such as PEM for RSA and ECC. Download the one matching your key type. Community answers also point out a trap: the ECC PEM file is not accepted by some control panels that run Apache, so on those panels use the RSA variant.

When a panel asks for a CA bundle and you want the full chain in one file, concatenate in order, leaf first and root last:

cat origin.pem cloudflare-origin-root.pem > fullchain.pem

Many servers, including Nginx, expect the leaf certificate plus any intermediates in the file given to ssl_certificate. Putting only the leaf there works for Cloudflare’s proxy, since it already trusts the root, but a strict client checking the chain may complain. If a panel supplies a separate bundle field, paste the root there and keep the leaf in the certificate field.

Verifying the chain from the command line

Do not guess whether the setup works. Test it. The openssl client shows exactly what your origin presents:

openssl s_client -connect ORIGIN_IP:443 -servername example.com -showcerts </dev/null

Look at the certificate chain at the top of the output, and the verification line at the bottom. With a Cloudflare origin certificate, expect a verify error if you run this without telling openssl about the root. That is normal, because your system does not trust the origin CA. Supply the root to prove the chain is correct:

openssl s_client -connect ORIGIN_IP:443 -servername example.com \
  -CAfile cloudflare-origin-root.pem </dev/null

Now the verify return code should be zero. This test uses the origin directly, bypassing the proxy, so run it from a machine allowed to reach the origin address.

Also check the certificate dates and subject names. A certificate that does not list the exact hostname you serve will fail strict verification. And test through the real hostname in a browser last, once Full (strict) is on.

Common errors and what they mean

Most failures fall into a short list.

• 521 or 525 errors after switching to Full (strict). The origin certificate is missing, expired, does not cover the hostname, or the server is not listening on 443.
• Browser shows an untrusted certificate when hitting the origin directly. Expected with an origin CA certificate. Use the proxied hostname.
• A panel rejects the certificate. Check the key type matches the panel’s support, and use the RSA variant for Apache panels that cannot read ECC.
• Redirect loops. The SSL mode is Flexible while the origin forces HTTPS. Move to Full (strict) with a valid origin certificate.
• Chain errors in non-browser clients. The client does not know the origin CA. Give it the root bundle, or use a publicly trusted certificate on the origin.

When something fails, work outward from the origin: can the server serve a valid certificate for the hostname, does it chain correctly to the root, and does the proxy mode match. Most problems are one of those three.

The post on Cloudflare TLS termination covers the modes in more depth.

Renewals, expiry and when to use a public certificate

Origin certificates can be issued for long periods, up to fifteen years, which is both convenient and a trap. Nobody remembers a certificate that lasts fifteen years until it expires on a weekend. Put the expiry date in a calendar or a monitor on the day you create it.

The tradeoff against a public certificate is flexibility. A publicly trusted origin certificate, issued by an authority that automates renewal, works whether or not traffic is proxied, so you can switch the proxy off for debugging without breaking TLS. An origin CA certificate ties you to staying proxied.

If your hosting already issues and renews certificates for you, you may not need either. A RunxBuild static site or service with a custom domain gets certificates handled for you, as described in the custom domains docs. Putting a proxy in front is then an optional layer, and whichever way you go the same rules apply: encrypt the whole path and verify the origin.

Authenticated origin pulls: proving the request came from the proxy

A certificate on the origin protects traffic in transit, but it does not stop someone from connecting to your origin address directly and bypassing the proxy. If the origin IP leaks through old DNS records, email headers or a certificate search, attackers can skip every rule you set at the edge.

Two controls close that gap. The first is a firewall rule on the origin that accepts connections on 80 and 443 only from the proxy’s published address ranges. Those ranges change occasionally, so automate the update rather than pasting a list once.

The second is authenticated origin pulls, where the proxy presents a client certificate and your server rejects connections without it. This is where you actually use a CA file on the origin:

ssl_client_certificate /etc/ssl/cloudflare/authenticated_origin_pull_ca.pem;
ssl_verify_client on;

Test it by requesting the origin directly: the connection should be refused, while the proxied hostname keeps working. Do both controls if the site matters. They are cheap, and they turn the proxy from a convenience into a boundary.

How this fits the rest of the stack

Certificates are free to issue and expensive to forget, so the real cost is operational. If you are weighing where your origin should run before you wire up proxies and chains, line the options up in the RunxBuild hosting calculator. When you want certificates and domains handled for you, the RunxBuild dashboard is where a site is created and a custom domain attached.

Useful related references:

• Elementor Hosting: What an Elementor Site Needs From Any WordPress Host, and When the Bundle Makes Sense
• Cloudflare Postgres: Why Hyperdrive, Not a Managed Database
• Cloudflare Logpush: What It Ships, What It Costs, and What It Misses
• Services on RunxBuild

FAQ

What is the CA bundle for Cloudflare?

It is the root certificate that signs Cloudflare origin CA certificates. You need it when something on your side must verify an origin certificate, not for ordinary visitors, whose browsers see Cloudflare’s edge certificate instead.

Where do I download the Cloudflare origin CA root?

From Cloudflare’s origin CA documentation page, which links the root certificates in PEM format for RSA and ECC. Choose the one that matches your origin certificate’s key type.

Do I need a CA bundle for Nginx?

Not for Cloudflare’s proxy, which already trusts its own origin CA. You need only the origin certificate and key, and Full (strict) mode on the zone. Add the root only if a client must verify the chain.

Why does my browser distrust the origin certificate?

Cloudflare origin certificates are trusted only by Cloudflare’s proxy. Browsers connecting directly to the origin will reject them, which is intended. Visit the proxied hostname instead.

What happens when an origin certificate expires?

With Full (strict) mode, Cloudflare returns a 525 or similar error until you install a new certificate. Track the expiry date from the day you create it.