By Yair Knijn · June 25, 2025

One wildcard cert, forty hosts, one private key. The director who thought that was simpler.

A platform director opens a certificate inventory with eighty rows and decides the inventory itself is the problem. The fix looks obvious: buy one *.corp.example.com wildcard, push it everywhere, watch the count drop from eighty to one. Fewer renewals, fewer expiry alerts, fewer rows to babysit. The plan rests on one belief, that the count was ever the hard part.

It wasn't. The hard part is what a single private key now controls, and where the copies of it have spread.

Why the count looks like the enemy

Wildcards win on the one metric people reach for first: number of certificates. A single cert covers api., app., auth., and whatever subdomain someone spins up next quarter without filing a ticket. That last bit is what sells it, because it deletes the issuance step for any new host. No CSR, no validation, just copy the existing key and cert onto the box.

Optimizing for a shorter spreadsheet means optimizing the wrong number. Eighty certificates is a workflow, and a workflow you can automate. One key trusted by forty hosts is a structural exposure you can't automate away after the fact.

Shared key, shared fate

A wildcard's private key has to live on every host that terminates TLS for those names. Forty hosts, forty copies of one key, on forty filesystems, backed up to forty other places, readable by whatever process or operator can reach each box. Break into the weakest one, the forgotten staging node or a contractor's jump host, and the attacker holds a key that authenticates as your entire namespace. Cross-subdomain cookie theft, CSRF, phishing on names that genuinely chain to your CA, all of it opens up from a single foothold.

There is a nastier edge, documented as BygoneSSL. When one name on a shared certificate changes hands, the new owner can request revocation and pull down every other host on that certificate. A domain you let lapse can kill service for the rest. You don't fully control who shares the key, or what they do with it.

The night the wildcard leaks

Run the incident. The key gets out. The correct response is revoke and re-key, and revocation here is all-or-nothing. Revoking the wildcard invalidates app., auth., and the other thirty-eight names at once. You cannot revoke for one host and spare the rest, because there is exactly one certificate and one key. What follows looks like this:

• Generate a fresh key and issue a replacement, fast, under pressure.
• Redistribute it to every host that held the old one, including the ones nobody documented.
• Reload every terminating service in an order that doesn't black-hole production.
• Confirm no stale copy of the revoked key is still serving anywhere.

Miss one host on the redistribution step and that host is down, or serving a cert that's already revoked. The architecture sold as "simpler" just converted a contained single-host incident into an estate-wide outage with a clock on it.

Per-host certs make the count irrelevant

The honest answer to "too many certificates" is not one giant key. It is taking the human out of issuance so the count stops mattering. Each host gets its own key that never leaves the machine, and its own short-lived certificate renewed automatically over ACME. Forty keys, forty certs, each on its own cadence with HTTP-01 or DNS-01. A single compromise is now a single revocation, scoped to one name, and re-key is one box reloading itself. Short lifetimes shrink the window, and revocation rarely has to fire because expiry already handled it.

Automate Certificates issues and rotates a discrete certificate per host inside your Environment, keeps each private key on the machine that uses it, and holds the blast radius to one host. See how the per-host model is wired in features, then weigh it against the wildcard you were about to commit to.