We often get asked about wildcard certificates. You know, those certificates with that little asterisk in them (*.mydomain.com).
Sometimes it is a simple question like, “Can our PKI issue wildcard certs?” More often, though, the question is more along the lines of, “what’s the risk?”
There are plenty of good articles on this topic from various sources, but nothing that sums up my thoughts precisely – so here you go:
Wildcard certificates are convenient
At its core, using a wildcard cert is entirely a matter of convenience. Sure, you can argue about a single wildcard cert being less expensive than the cost of obtaining a uniqe certificate for every server, but if you have need to stand up tens or hundreds of internet-facing servers, and your certificate budget is your stumbling block then you likely have bigger issues.
But should you use a wildcard certificate?
To help answer the question, "Should we use a wildcard certificate," ask yourself these three questions:
- Do you have well documented private key storage policies and procedures?
- Is that information known, understood, and properly followed at all times?
- Do you have regular audits on those policies and procedures – with documented findings and corrections? (And no, once every 10 years, doesn’t count as regular).
If the answer to any of these is not an unconditional, “yes”, then the answer is a resounding “no”.
Wildcard certificate risks
- In an ordinary certificate, if the private key is compromised, then only the connections to the individual servers listed in the certificate could be compromised. If the private key for a wildcard certificate is ever compromised, it could compromise the secure connections to all the servers which fall under the domains listed in the certificate. That means a one key may be the single risk vector for possibly hundreds of servers! And this is the problem, how do you effectively and securely handle that key across so many servers (and likely different teams)? The likelihood of a key compromise quickly becomes exponential! Now consider what happens when that compromised key is used on another server (which only needs to have (any) name in the wildcard domain). An end-user (victim) would be totally unaware of a rogue server.
- Multi-domain certificates are often updated to add or remove websites. Each time a change is made, the certificate must be reissued and replaced on all websites it protects. These changes can be risky and result in downtime for your websites.
- You multiply the scope of any potential issues with the certificate. A problem like a key is compromised or certificate expiration, now affects every site using the certificate rather than just one single site.
Where wildcard certificates (may) make sense
In practice, you should almost never need wildcard certificates. It’s nice that the option exists, but unless you’re automatically generating (hundreds of) subdomains for users, a wildcard certificate is an unnecessary and insecure option.
Even if you can justify using wildcard certs, each service should have its own certificate. If you have a lot of servers representing the same service (web farm), then it may be acceptable to use a wildcard certificate – so long as that those servers aren't also representing other services.
Mitigation considerations
If you do use a wildcard certificate, consider the following:
- Each certificate should only be used for one server, or one homogeneous cluster of servers. Different services on different servers should have their own, usually non-wildcard certificates.
- A compromised certificate key can lead to serious repercussions. In general, the way to mitigate the potential impact of certificate key compromise is by using short-lived, non-wildcard certificates.
Note: If you choose to ignore the "non-wildcard" part of that second bullet, don't ignore the other bit of advice about using short-lived certs as a risk-mitigation control.
Final thoughts
- If you think you will somehow get around the issue of using a wildcard certificate by putting tens or hundreds of entries in the Subject Alternative Name (SAN) extension, think again!
- First, the only time you should have multiple SAN entries is if the certificate is for a homogeneous cluster of servers (a server pool all dedicated to the same service).
- Second, the risks outlined above apply to cert with a laundry list of servers their SAN list, just like they apply to "multi-domain" certificates. They all have the same risks as a wildcard certificate.
- In this age of aggressive legal liability do you think you can effectively argue that “convenience” trumped risk when explaining your decision to your boss (or affected customers)?
- Finally, a mature certificate lifecycle management system really helps to kick the legs out from under the argument that wildcard certificates are “more convenient”. A well designed system could (automatically) manage the certificates on all of those servers with minimal effort.