Free Wildcard HTTPS with neo caddy dns

Why wildcards need a different validation method

app.example.com gets a certificate the normal way: Let's Encrypt asks Caddy to prove control of the domain over HTTP, and Caddy answers automatically. *.example.com can't be validated that way — there's no single HTTP endpoint that proves control of every possible subdomain. Let's Encrypt requires DNS-01 for wildcards: proving control by creating a specific DNS TXT record.

Setting it up

neo caddy dns example.com --provider cloudflare --app my-app

You'll need a Cloudflare API token scoped to DNS edit permissions for the zone. Neo configures Caddy's ACME automation to solve DNS-01 challenges against that provider — after this one-time setup, Caddy requests and renews the wildcard certificate itself.

Using the wildcard

domain: "*.tenants.example.com"

Every subdomain under it — acme.tenants.example.com, globex.tenants.example.com — is covered by the one certificate, with no per-tenant DNS or SSL step.

On-demand TLS as an alternative

For a SaaS with dynamic, unpredictable tenant subdomains where you'd rather not pre-register each one:

neo caddy ondemand tenants.example.com --app my-app

Caddy issues a certificate the first time a given subdomain is actually requested, rather than covering all of them with one wildcard cert up front — useful when tenants can pick their own subdomain and you don't want DNS-01 provider credentials on the server at all.

Supported providers

Cloudflare today. neo caddy dns example.com --provider cloudflare is explicit about which provider — passing an unsupported one fails immediately with the list of what's available, rather than a confusing downstream ACME error.