Serve Unlimited Subdomains From One Cloudflare Origin Certificate

Every time you launch a new subdomain, there is a small tax most teams pay without thinking about it: minting a certificate, wiring up renewal, making sure the auto-renew does not silently fail and take the site down some Tuesday three months later. Multiply that across a portfolio of sites, blog subdomains, app subdomains, client microsites, and you have a recurring chore that exists purely to keep TLS valid. There is a way to make that tax close to zero, and it comes from a property of Cloudflare Origin certificates that is easy to overlook.

The trick is that one certificate, with a wildcard in its list of names, can cover an unlimited number of subdomains, and Cloudflare lets you make that certificate valid for up to 15 years. Set it up once and every future subdomain goes live with valid TLS without minting or renewing anything. Here is how it works and how to wire it into nginx.

The two layers of Cloudflare TLS

First, a clarification that trips people up, because there are two separate certificates in a Cloudflare-proxied setup and they do different jobs.

The connection from the visitor's browser to Cloudflare's edge is secured by Cloudflare's edge certificate, which Cloudflare manages for you. That is the cert the public sees, and the handshake behind it is where TLS 1.3 zero round trip resumption and the replay risk it hides comes into play. The connection from Cloudflare's edge back to your server, the origin, is a separate hop, and securing it is what the Origin certificate is for. The Origin certificate is issued by Cloudflare's own private certificate authority and is trusted only by Cloudflare's systems, not by public browsers, because it never needs to be: only Cloudflare ever talks to your origin directly.

This is the layer we are optimizing. The edge cert is handled. The origin cert is the one you install on your server, and it is the one you can make cover everything at once.

One wildcard SAN cert covers an unlimited set of subdomains

A certificate has a list of names it is valid for, called Subject Alternative Names. A Cloudflare Origin certificate can carry up to 200 SANs, and crucially, one of those entries can be a wildcard.

A wildcard entry like *.example.com matches any single-level subdomain: app.example.com, blog.example.com, dashboard.example.com, anything at that level, all covered by the one entry. Put both the wildcard and the apex on the certificate, *.example.com and example.com, and you have a single certificate that is valid for the root domain and every subdomain under it. The number of subdomains it covers is effectively unlimited, because the wildcard does not enumerate them; it matches the pattern.

One thing to know about wildcards: a single wildcard covers exactly one level. *.example.com matches app.example.com but not app.staging.example.com, which is two levels deep. If you have multi-level subdomains, you add a second wildcard for that level, *.staging.example.com, on the same certificate. Cloudflare lets multiple wildcards coexist on one cert, so even a multi-level setup is still a single certificate covering everything, just with one wildcard entry per level you use.

The 15-year validity that ends the renewal chore

The other half of the win is the lifetime. Public certificate authorities issue short-lived certs, increasingly capped at around 90 days, specifically because they have to be renewed often, which is why everyone runs automated renewal and worries about it breaking. Cloudflare Origin certificates are different, because they are only trusted by Cloudflare and the security model does not depend on short rotation. You can generate one valid for anywhere from 7 days to 15 years.

Choose a long validity for an origin cert and the renewal chore essentially disappears for the life of the infrastructure. There is no auto-renew to misconfigure, no expiry to monitor, no 3am page when a renewal hook silently failed. The cert you install today is still valid years from now, and so is every subdomain it covers.

There is one operational catch worth flagging clearly: when you generate the cert, Cloudflare shows you the private key exactly once, on the creation screen, and you cannot retrieve it afterward. So save the private key somewhere secure the moment you create it, because if you plan to reuse the same cert across several servers or keep it for the future, that one-time view is your only chance to capture the key. Lose it and you have to generate a new cert.

Installing it on nginx

Origin certs are standard PEM files, which is exactly what OpenSSL-based servers like nginx expect, so installation is ordinary. You take the signed certificate and the private key Cloudflare gave you, write them to files on the server, and point nginx at them in the server block:

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

    ssl_certificate     /etc/ssl/cloudflare/example.com.pem;
    ssl_certificate_key /etc/ssl/cloudflare/example.com.key;

    # ... your app config
}

The same certificate path and key path get referenced by every vhost for every subdomain on this domain, because the one cert is valid for all of them. Those server blocks are also where you enforce edge protections like Nginx rate limit zones for brute force and POST floods, so the same one-time setup hardens every subdomain at once. When you stand up a new subdomain, you do not generate anything. You add a server block pointing at the same cert and key, reload nginx, and the subdomain has valid origin TLS immediately. The certificate was already valid for it the moment it matched the wildcard. If your subdomains split along the marketing-versus-transactional line, splitting transactional and marketing mail across subdomains the right way covers the deliverability reasons to draw that boundary deliberately.

This is what turns launching a subdomain from a TLS chore into a config change. The wildcard SAN means the cert already covers the new name; the long validity means there is nothing to renew; and the shared file path means every vhost just references the same two files. This is exactly the pattern we run across the portfolio of sites we host and operate, and it is part of why disciplined server administration and a deliberate networking setup make new launches fast: the infrastructure was set up once so that adding the next thing is nearly free.

A small but real DNS detail

One piece sits outside nginx. For a new subdomain to actually serve traffic through Cloudflare, it needs a DNS record. In the Cloudflare dashboard for the zone, add a record for the new subdomain pointing at your server's IP, proxied through Cloudflare so it gets the edge cert and the proxy benefits, including the HTTP/3 and QUIC transport that kills head-of-line blocking on the browser-to-edge hop. How long that record lingers in resolver caches is a deliberate choice, which is the subject of setting DNS TTLs so failover is instant without hammering resolvers. That record, plus the nginx server block referencing the shared cert, is the entire setup for a new subdomain. No certificate work at any step. If you would rather not expose the origin at all, exposing an internal app publicly without opening a single port is the tunnel-based alternative.

The wildcard cert covers the TLS, the DNS record routes the traffic, and the nginx block serves the app. Three small steps, none of them involving minting or renewing a certificate, and the new subdomain is live with valid TLS end to end.

Set it up once, launch forever

The shape of this is a one-time setup that pays off indefinitely. You generate a single Cloudflare Origin certificate with a wildcard SAN covering your apex and your subdomains, set it to a long validity, save the private key carefully on creation, and install it on nginx with a shared file path. From then on, every new subdomain is a DNS record and an nginx server block, both pointing at infrastructure that already exists. The certificate never needs touching, because it was valid for the new name before the name existed.

That is the difference between TLS being a recurring tax on every launch and TLS being something you handled once, years ago, for everything. For a studio or a team that spins up subdomains regularly, the wildcard origin cert is one of those quiet setup decisions that keeps paying off every single time you launch the next thing without thinking about certificates at all.