4 Questions to Ask Before Using Wildcard Certificates

If you do an Internet search for wildcard certificates, you’ll find a Wikipedia definition that reads: “a wildcard certificate is a public key certificate which can be used with multiple subdomains of a domain.” If you are new to the world of SSL/TLS certificates, you’ll think that wildcard certificates may be the answer to all your problems. Unfortunately, that’s not true in 99 percent of cases. Before you add a wildcard certificate to your shopping cart or expand your usage of them, here’s a realistic perspective regarding some of the challenges and opportunities regarding wildcard certificates.

First, let’s discuss an ongoing management issue that is often glossed over. By definition, the value of wildcard certificates is that they can be deployed on many systems across subdomains. With that benefit, however, the line of ownership between the system and the wildcard certificate starts to blur. Who’s responsible for replacing the certificate on a specific system? That can be challenging to understand. Let me explain.

Generally, organizations have a Domain Name System (DNS) naming convention for internal or external certificates so the DNS name in a certificate can often help organizations figure out which person or team is responsible for maintaining the infrastructure where the named certificate is being used. But with wildcard certificates, organizations must keep track of ownership at the system level which is much harder to do.

So, what’s the cost of this ownership problem? Organizations often experience application outages when wildcard certificates expire because they don’t know all of the systems where the wildcard certificates are installed. And, a compromised wildcard certificate can pose a huge security risk, not to mention a fire drill for many parts of the organization.

However, wildcard certificates do offer certain benefits to your PKI, but you should be very specific about what you plan to accomplish by using them. When you are considering using wildcard certificates, there are four questions you should answer:

1. Do you understand the security risks? Do you have a plan for how to limit your use of wildcard certificates to a specific purpose? Do you have controls in place to prevent wildcard certificates from being used as a stop-gap for emergency projects? Limiting your use of wildcard certificates will help you better control their security. 
2. Are you just trying to save time? Are you looking at wildcard certificates because you are finding it too difficult to install or too time consuming to get certificates? If that’s the case, then you can use certificate management solutions to make that process easier and faster for non-wildcard certificates. You’ll end up with a more secure implementation that is just as easy to deploy and much easier to manage. 
3. Are you trying to be more efficient? Do you have a large number of sites hosted on a small amount of external infrastructure? If so, do you have excellent controls in place to make sure the wildcard certificate is not copied and distributed to other systems? Or, perhaps, the management overhead of named certificates is too large for your business and you do not use DevOps orchestration or configuration management solutions to get certificates to your changing infrastructure. In this case, wildcard certificates may provide an acceptable solution, if you have controls in place to prevent unintentional sprawl. 
4. Are you only trying to save money? If so, you need to weigh the security risks against the cost savings. You may save money on the initial implementation but spend even more later when an unknown wildcard certificate expires and causes an outage. Plus, it’s likely to take dozens of staff hours to untangle a complex web of wildcard certificates that has been allowed to grow organically.

For fair balance, there are a few limited circumstances where wildcard certificates can have a valid use case. One ideal use case, for example, is when you have a lot of internal-facing ephemeral infrastructure that needs to communicate with itself. In this case, wildcard certificates can potentially be useful because they can speed up the time to bring that infrastructure into service; however, you will still need to implement security controls to protect your wildcard certificates. Yet, even this use case can be addressed by implementing certificate issuance processes into your DevOps CI/CD pipeline.

To solve the underlying issues that might motivate you to use wildcard certificates, you need to implement automation. Automation is the future for certificates. And, the more intelligence you build into the process, the less value a wildcard certificate offers. To minimize the hidden costs of wildcard certificate management, start by discovering all your certificates to understand your wildcard certificate exposure. Once informed, you can determine next steps with an informed, data-driven mindset regarding the scope of the problem.