Wildcard Certificates for Homelabs: When DNS Challenge Beats Per-Service HTTPS

Disclosure: This article does not use affiliate links.

Documentation basis: This guide is grounded in Let's Encrypt challenge documentation, Caddy TLS and automatic HTTPS documentation, the Nginx Proxy Manager guide, and the existing HomelabAddiction reverse-proxy and HTTPS setup pages. No first-hand benchmark or same-day side-by-side lab test is claimed here.

If you only run one or two public hostnames, individual certificates are usually simpler. Wildcard certificates start to make sense when one reverse proxy fronts many subdomains and you want new services to come online without repeating certificate issuance for each hostname.

This page helps a homelab operator decide when a wildcard certificate is worth the extra DNS challenge setup, then shows the practical Caddy and Nginx Proxy Manager paths that the broader HTTPS article on HomelabAddiction does not cover in depth.

Key takeaways

• Wildcard certificates need DNS-01 validation. HTTP-01 cannot issue them.
• A wildcard certificate is most useful when one reverse proxy fronts many subdomains such as grafana.example.com, immich.example.com, and vaultwarden.example.com.
• If your services stay internal-only, wildcard plus split-horizon DNS can be cleaner than exposing every hostname through port-forwarding.
• Caddy is the cleaner path when you want file-based configuration and versioned changes.
• Nginx Proxy Manager is easier when you want a UI and your DNS provider is supported in the certificate screen.
• A wildcard cert is not a free pass. You still need scoped DNS API credentials, renewal checks, and a restore plan.

When a wildcard certificate is the right move

Use a wildcard certificate when most of these are true:

• you already use one reverse proxy as the front door
• you expect to add more than a couple of subdomains over time
• you want one certificate strategy for many apps
• you can automate DNS TXT record changes through your DNS provider
• you want internal and remote users to keep the same hostnames

Typical examples:

• jellyfin.example.com
• grafana.example.com
• prowlarr.example.com
• immich.example.com
• paperless.example.com

The main payoff is operational. Once the wildcard certificate is in place, adding another service often becomes a routing change and a DNS entry instead of a fresh certificate workflow.

When it is overkill

A wildcard certificate is usually unnecessary when:

• you only have one or two HTTPS services
• your DNS provider has no usable API
• you do not want DNS credentials anywhere near the proxy host
• you are happy with one certificate per hostname
• your setup is fully local and tls internal in Caddy would already solve the browser-warning problem

If that sounds closer to your situation, start with the broader Homelab HTTPS Setup: Certificates, DNS, and Local Access guide instead of adding more moving parts too early.

Why DNS challenge changes the decision

A wildcard certificate works because the certificate authority validates DNS control, not a file on port 80.

That matters for homelabs because it unlocks two useful patterns:

1. you can issue *.example.com for many subdomains
2. you can keep the individual services off the public internet and still automate certificate renewal

The tradeoff is that your proxy, or another system acting on its behalf, needs permission to create _acme-challenge TXT records. That makes secret handling part of the HTTPS design, not an afterthought.

Quick decision table

Caddy path: best when you want config-as-code

Caddy is the cleaner wildcard path when you want your HTTPS behavior to live in a file you can back up and diff.

What changes compared with normal Caddy HTTPS

For normal public hostnames, Caddy can often obtain certificates automatically with no extra work. Wildcard certificates are different. You need a DNS provider module and a DNS API token.

A practical pattern looks like this:

*.home.example.com {
    tls {
        dns cloudflare {env.CLOUDFLARE_API_TOKEN}
    }

    @grafana host grafana.home.example.com
    handle @grafana {
        reverse_proxy grafana:3000
    }

    @immich host immich.home.example.com
    handle @immich {
        reverse_proxy immich-server:2283
    }
}

The operational advantage is simple: once the wildcard certificate exists, adding paperless.home.example.com is mainly another host matcher and reverse-proxy target.

Two Caddy details that matter

• The standard Caddy image does not automatically give you every DNS provider plugin. If your provider needs a plugin, build or use a Caddy image that includes it.
• If your internal clients resolve these names through Pi-hole, AdGuard Home, Unbound, or another local resolver, keep that local DNS design consistent or renewals can fail for reasons that look like certificate bugs but are really DNS path problems.

If you are still comparing reverse proxies at a higher level, the parent cluster page is Caddy vs Traefik vs Nginx Proxy Manager.

Nginx Proxy Manager path: best when you want a UI

Nginx Proxy Manager is easier for readers who want to keep certificate management in a dashboard.

The rough flow is:

1. deploy Nginx Proxy Manager with ports 80, 81, and 443
2. go to SSL Certificates
3. add a certificate for *.example.com
4. choose Let's Encrypt
5. enable DNS challenge
6. select your DNS provider and add a scoped API token
7. assign that certificate to the proxy hosts that should use it

The big advantage is approachability. The cost is that more of the state lives behind the UI, so restores depend more on keeping the Nginx Proxy Manager data and Let's Encrypt directories safe.

If you are still on the first setup step, use the existing How to Set Up Nginx Proxy Manager on Docker guide first, then come back to wildcard certificates when the basic proxy already works.

Local DNS still matters after the certificate is issued

A wildcard certificate solves trust. It does not solve name resolution.

For a smooth homelab setup, local clients should still resolve the app hostnames to the reverse proxy's LAN IP. That usually means split-horizon DNS or local overrides in Pi-hole, AdGuard Home, Unbound, or another resolver.

A useful mental model is:

• DNS decides where immich.example.com points
• the wildcard certificate makes the browser trust that name
• the reverse proxy decides which backend service answers for that name

When one of those layers is wrong, the symptoms can look similar. That is why wildcard-certificate guides fail when they treat DNS, TLS, and proxy routing as one vague problem.

Secret scope and restore discipline

Wildcard certificates reduce certificate sprawl, but they increase the value of the DNS API credential that manages renewals.

Protect that token like an infrastructure secret:

• scope it to DNS record changes only
• limit it to the required zone if your provider supports that
• do not hard-code it into Compose files committed to Git
• document where it is stored so restore day is not guesswork

Your restore checklist should include:

• reverse proxy config backup
• certificate storage backup
• DNS credential source and scope
• local DNS overrides or split-horizon rules
• one test hostname used after restore to confirm renewal still works

This is where Caddy usually ages better than UI-driven stacks: the path from backup to rebuild is more obvious. Nginx Proxy Manager can still be fine, but only if you treat its state as important data instead of as a disposable helper container.

Common failure modes

1. Choosing wildcard before the basic proxy works

If the reverse proxy itself is not already routing one service cleanly, wildcard certificates add more surface area before the fundamentals are stable.

2. Using a DNS provider without reliable API support

No DNS automation usually means no safe unattended wildcard renewal.

3. Forgetting local DNS overrides

The certificate can be valid while local clients still hairpin out to the WAN path or fail to resolve the expected hostname.

4. Over-scoping the DNS API token

The cleaner pattern is the narrowest token that can edit only the required records.

5. Treating wildcard as a security feature by itself

A wildcard certificate gives broader certificate coverage. It does not replace access control, network segmentation, patching, or sane exposure choices.

Best fit by operating style

Choose wildcard certificates when your homelab behaves like a growing platform with many stable subdomains.

Choose per-service certificates when your setup is small and you want the least moving parts.

Choose Caddy tls internal or another internal PKI path when the whole goal is trusted HTTPS for local-only names and you do not need public certificate trust for a real domain.

FAQ

Are wildcard certificates better than one certificate per hostname?

Not always. They are better when you expect many subdomains and want less repeated certificate management. They are worse when your setup is small or your DNS automation is weak.

Can a wildcard certificate work for internal-only homelab services?

Yes, if you use a real domain and DNS-01 validation, then point local DNS to the reverse proxy internally. If you use a private-only suffix instead, an internal TLS approach may be cleaner.

Is Caddy or Nginx Proxy Manager better for wildcard certificates?

Caddy is usually better when you want text config, version control, and easier recovery. Nginx Proxy Manager is easier when you want a GUI and supported DNS challenge options in the certificate screen.

Does a wildcard certificate remove the need for local DNS?

No. The certificate proves trust for the hostname. Local DNS still decides where that hostname resolves on your LAN.

What should you read next?

Start with the broader HTTPS guide if your first reverse-proxy hostname is not live yet. If your proxy already works and you are deciding which reverse-proxy model fits your lab long term, read the main reverse-proxy comparison.