Using one TLS/SSL certificate with a single CN and a grab-bag of unrelated SANs (Subject Alternative Names) and then reusing it across many different servers is basically “certificate sprawl in reverse”: it looks convenient, but it concentrates risk, muddies identity, and turns a simple compromise into an all-you-can-eat incident. Certificates are supposed to make a clear, auditable statement of which host you’re talking to; stuffing unrelated names into one cert and deploying it everywhere blurs that boundary, makes revocation/rotation painful, and invites accidental (or malicious) cross-use that undermines the whole point of TLS.

Why not to do this (CN + tons of unrelated SANs reused across servers):

• Huge blast radius: If the private key leaks from any one server, an attacker can impersonate every hostname in that cert.

• Revocation/rotation becomes a fire drill: One hostname needs a change? Now you’re reissuing and redeploying the cert everywhere, often urgently, often imperfectly.

• Breaks least privilege: Servers get the ability to present identities they should never represent (prod vs dev, internal vs external, different apps/teams).

• Harder incident response and forensics: When the same key/cert is everywhere, you lose clean attribution and containment options.

• Encourages sloppy key handling: Copying the same private key around increases exposure (more disks, more backups, more config repos, more humans).

• Operational fragility: One expired cert or botched deployment can take down many services at once.

• Policy/compliance headaches: Auditors and security standards generally expect separation by system, environment, or trust boundary; this design fights that expectation.

• Name bloat leaks information: A SAN list can reveal internal hostnames/services to anyone who sees the cert chain, which is great… for attackers doing recon.

• Not actually a wildcard: You don’t get wildcard flexibility; you get a brittle roster that constantly needs updates and still doesn’t scale cleanly.