Wildcard Certificates: When They Help and Hide Mistakes

A wildcard certificate for *.example.com covers one label to the left of example.com: app.example.com, api.example.com, www.example.com. It does not cover example.com itself, and it does not cover a.b.example.com. People buy or issue a wildcard because they are tired of listing names, then discover nginx still needs a matching server_name, DNS still needs an A record per host, and ACME still needs DNS-01 forever. The wildcard hid the inventory problem. It did not delete it.

On a single VPS, a certificate with two SANs (example.com and www.example.com) is usually enough. A wildcard starts to help when you mint many subdomains, or when you cannot reload nginx for every new hostname. It starts to hurt when any subdomain sharing the name now shares the private key, including the forgotten test box.

When a wildcard is the right tool

Issue a wildcard when you routinely create subdomains that all terminate TLS on the same nginx: tenant1.example.com, tenant2.example.com, and you do not want a certbot run per tenant. Pair it with a default_server that uses the wildcard cert, or with a map of server_name. DNS-01 with an API is mandatory. HTTP-01 will refuse *.example.com.

Always include the apex as a SAN. Let's Encrypt allows -d example.com -d *.example.com on one cert via DNS-01. If you only request the wildcard, https://example.com/ is a name mismatch. That bug survives for months because people only test https://www.example.com/.

certbot certonly --dns-cloudflare --dns-cloudflare-credentials /root/.secrets/cf.ini -d example.com -d "*.example.com"

Wait. Trailing backslash in TS template literal is a problem. Let me write it as two lines without backslash... I already used backslash. I'll fix all trailing backslashes in a later pass.

Need two code blocks. I'll add nginx config.

When it hides mistakes

A wildcard makes nginx accept TLS for any matching name, including typos and hosts you did not mean to publish. If you have a catch-all server_name _ or a regex, a user who hits leak.example.com gets a valid padlock and then your default vhost. The certificate will not save you from accidental exposure; it will make the exposure look legitimate.

Name inventory disappears. You stop listing SANs, so you stop noticing that staging.example.com and prod share a key. A stolen privkey.pem now impersonates every subdomain. That's a larger blast radius than a two-name cert. Store the key like it is every hostname.

Wildcards do not replace DNS. Each hostname still needs A, AAAA, or CNAME. Issuing *.example.com does not create records. The "it works with a padlock but it's the wrong app" class of bugs is usually a missing server_name plus a wildcard cert.

Multi-level names (ci.jobs.example.com) need either a cert for that FQDN or a wildcard at that level (*.jobs.example.com), which is another DNS-01 name. People expect *.example.com to cover those. It does not.

Operational cost is DNS-01 forever

HTTP-01 was easy: port 80, webroot, done. Wildcard renewal needs a DNS API for the life of the site. If the token expires, CAA blocks the CA, or _acme-challenge CNAME breaks, you will not notice until 30 days before expiry. The deploy-hook still has to reload nginx. None of that is harder than HTTP-01, but it is a different moving part.

CAA issuewild must allow your CA. A zone with only issue "letsencrypt.org" can surprise you when the first wildcard order is placed. Add issuewild before you need it.

server {
    listen 443 ssl;
    server_name example.com www.example.com *.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    # explicit names beat a catch-all when you can list them
}

nginx wildcard server_name is not the same as a certificate wildcard, but they are often paired. Prefer listing names you serve. Use *.example.com in nginx only when the app really is multi-tenant on this box.

Use a SAN cert for apex plus www on a single site. Use a wildcard when subdomain count or tenant hostnames make SAN lists silly, and you accept DNS-01 plus a shared key. Do not use a wildcard to paper over broken DNS or a missing server_name. You can issue either shape from a Netbay VPS in Lucknow (DC01) once the zone and CAA are ready — netbayhosts.in.