CertKit
Abstract
You’ve used wildcard certificates for years. It made your life easier. Once a year you’d renew your wildcard certificate, and copy it around to all the servers. It was way too complicated and expensive to get a unique certificate for every system.
But now certificate lifetimes are shrinking to 47 days by 2029 and it’s not going to work anymore. You need to automate your certificates. Soon.
So here’s the question: if you’re automating certificate management, do you actually need a wildcard SSL certificate? Or is it solving a problem that no longer exists?
What is a wildcard certificate?
A wildcard certificate covers a domain and all its subdomains at one level. Buy a cert for *.example.com and it works for foo.example.com, bar.example.com, baz.example.com, and anything else you need.
In practice, nearly every wildcard certificate is issued as a multi-SAN cert that includes both *.example.com and the apex example.com domain. So when you buy a “wildcard,” you’re really getting a SAN certificate with a wildcard entry.
Note that wildcards don’t cover multiple levels. A cert for *.example.com won’t secure dev.api.example.com. That needs its own certificate or another wildcard at *.api.example.com.
What is a SAN certificate?
A SAN (Subject Alternative Name) certificate lists one or more specific domains. Unlike wildcards, these are explicit like app.example.com or api.example.net.
CAs sometimes call these “multi-domain” or “UCC” certificates. They’ll even let you mix completely different domains on one cert. Every domain must be listed at issuance. So if you want to add a new subdomain, you have to re-issue the whole certificate.
Certificate authorities love selling SAN certificates. They typically charge per domain, so a 10-domain SAN costs more than a single wildcard that covers unlimited subdomains. Keep that in mind when you hear CAs recommending SANs over wildcards.
Tradeoffs in wildcard vs SAN certificates
Here’s what to consider with a wildcard vs SAN certificate:
1. Flexibility and future subdomains
Wildcards cover subdomains you haven’t created yet. If you spin up subdomains for projects or customers, having a wildcard can make that faster and easier. With a SAN certificate, you have to issue a new cert for every domain you need. But, if you have certificate automation implemented, issuing a new certificate could just be a few clicks.
2. Key compromise and blast radius
A compromised private key is always concerning, but the scope of damage depends on what that key protects. Lose a single-domain certificate’s key and one service is exposed. Lose a wildcard key and every subdomain is vulnerable. And if you’re not using Perfect Forward Secrecy, attackers could decrypt previously captured traffic too.
The NSA warns that attackers with a wildcard private key can impersonate any subdomain covered by that certificate. They lay out a scenario where a compromised staging server, steal the key, use DNS poisoning or network access to redirect traffic intended for production systems. The NSA calls these “relatively uncommon conditions,”. If the attacker is in your network and changing DNS records, you’ve got bigger problems.
3. Certificate Transparency exposure
Every TLS certificate is logged publicly in Certificate Transparency logs. All of them. You can search for yours right now using our CTLog search tool. Anyone can watch these logs and see what domains you’re creating certificates for.
With single-domain certificates, your infrastructure is visible. Internal project names, customer subdomains, staging environments, or that new product you haven’t announced yet. Hanno Böck demonstrated at DEF CON 25 that attackers can find new WordPress installations within 30-60 minutes of certificate issuance by watching CT logs. He estimated he could have compromised around 4,000 WordPress sites in a month.
Wildcard certificates hide your subdomain names. The CT log shows *.example.com, not the 15 specific subdomains you’re actually running. Some organizations choose wildcards specifically for this obscurity. It’s not perfect security (subdomains can still be discovered through DNS enumeration), but it removes one easy reconnaissance vector.
4. Validation requirements
Wildcard certificates require DNS-01 validation. You have to create a TXT record to prove domain ownership. Single-domain certificates can use simpler HTTP-01 validation where you just drop a file on your web server.
This matters for automation. DNS validation requires API access to your DNS provider. HTTP validation just needs a running web server. If your DNS provider has a bad API (or no API), wildcards become painful.
Here’s one of the ways CertKit makes it easier. Rather than worrying about validation, you just create a CNAME record for _acme-challenge.example.com and point it at us. We handle all the validation from there, so you can get whatever certificates are right for you.
Multi-SAN certificates: the worst of both worlds
Multi-SAN certificates combine the downsides of both approaches.
You get the blast radius of a shared private key. Compromise one server, compromise every domain on that cert.
You get full Certificate Transparency exposure. Every domain is publicly listed.
You lose flexibility. Adding or removing domains requires reissuing the entire certificate. Want to sell off a side project that was on your main SAN cert? You can’t just remove it. Reissue everything.
And you get a unique problem called BygoneSSL. If any domain on your multi-SAN certificate changes ownership (you let it lapse, you sell it, the new owner wants it back), the new owner can request revocation of the entire certificate. Researchers analyzing this found CDN certificates with 700 domains on them. One bygone domain means one person can kill service for 699 other sites with a single revocation request.
There are a few vendor systems that require multi-SAN certificates (looking at you Microsoft Exchange), but you should probably avoid them unless you have to. Don’t choose this architecture voluntarily.
When wildcards still make sense
Even with full automation, wildcard certificates have legitimate uses.
CT log obscurity. If hiding your subdomain structure from public view matters to your threat model, wildcards are the only option. Maybe you’re working on an unannounced product. Maybe you have customer-specific subdomains you’d rather not advertise. Maybe you just don’t want to make reconnaissance easier for attackers.
Load balancers and reverse proxies. A wildcard on your edge proxy doesn’t meaningfully expand blast radius. If someone compromises that proxy, they already have access to traffic for all your subdomains. The NSA guidance specifically calls this out as an acceptable use case.
High-churn environments. If you’re constantly creating and destroying subdomains (dev environments, feature branches, customer sandboxes), wildcards mean one less thing to automate per deployment.
Vendor requirements. Some systems just want a wildcard. Don’t fight it.
Automation changes the question
The wildcard vs SAN debate is stuck in the past. It assumes certificates cost money and management is painful, so minimizing the number of certificates matters. One is easier than fifty. Less to track, less to renew, less to screw up.
But with 47-day lifetimes arriving in 2029, you need automation regardless. And once you’ve automated, issuing 50 single-domain certificates takes the same effort as one wildcard.
The question shifts from “what’s easiest to manage?” to “what fits my security model?”
For most organizations, that’s single-domain certificates per service. You get isolation (compromise one key, lose one service). Independent renewal cycles (one failure doesn’t cascade). Clear inventory of what’s running where.
Wildcards remain useful when CT log obscurity matters.
Multi-SAN certificates listing explicit domains should be avoided unless a vendor specifically requires them.
CertKit just added multi-SAN support for the cases where you need it. But our recommendation? Single-domain certs per service when you can. Wildcards when you need obscurity. Multi-SAN only when you have no choice.
CertKit automates certificate lifecycle management for teams who’d rather not think about certificates. Currently in beta.
Comments