To begin, a wildcard certificate is a public key certificate (like SSL/TLS) that can be used to secure all first-level subdomains of single domain name. In other words, instead of purchasing a distinct certificate for each of your subdomains, you could use a single wildcard certificate to secure all these subdomains.
On the surface, wildcard certificates appear to be a great way to quickly and easily deploy HTTPS quickly and easily across subdomains. You buy one certificate and you’re good to go for unlimited subdomains. Indeed, wildcard certificates are cheaper and easier to extend. But they are not necessarily easier to manage. And when things go wrong the initial convenience may evaporate quickly. For example, if you ever need to replace your domain wildcard with a more secure EV certificate, you could face a mess of subdomains to find and fix. But the most pressing reason to avoid wildcards is that they are simply less secure and can open the door to phishing attacks.
But perhaps the most pressing reason to avoid wildcards is that without proper security, control, and monitoring, wildcard certificates can be misused by cybercriminals to exploit the trust organizations have in them. In that sense, wildcard certificates are simply less secure and can open the door to phishing attacks. Thus, wildcard certificates can create significant security risks since the same private key is used across multiple systems, thereby increasing the risk of compromise across your organization.
What are the risks of using wildcard certificates?
To fully comprehend why they are less secure than you'd think, you must first understand a bit about the nature of wildcard certificates. A wildcard certificate is a public key certificate used by all subdomains within a larger domain. Using a wildcard certificate on a publicly facing web server, you can quickly secure unlimited subdomains that are all encrypted by the same certificate. Unfortunately, so can cybercriminals.
Here are some of the ways that cybercriminals can misuse wildcard certificates:
- Compromised web server. If you are using a wildcard certificate on public-facing web servers, it may increase the risk of cybercriminals using that web server to host malicious sites for phishing campaigns.
- Stolen private key. If cybercriminals gain access to a wildcard certificate’s private key, they may be able to impersonate any domain for protected by that wildcard certificate.
- Fake certificates. If cybercriminals trick a CA into issuing a wildcard certificate for a fictitious company, they can then use those wildcard certificates to create subdomains and establish phishing sites.
What makes wildcard compromises so serious?
If cybercriminals infiltrate your domain, they can gain privileges that allow them to create unlimited domains—all encrypted by your wildcard certificate. Even worse, these subdomains will appear to be valid because they are authenticated by your wildcard certificate. These illegitimate subdomains allow cybercriminals to host malicious websites that they can then use in phishing campaigns.
How does this work? Any subdomain created for the domain on a web server that uses a wildcard certificate will use the same certificate. For example, a webserver with a wildcard certificate is hosting the domain https://example.com. Anyone with access to the webserver can set up a subdomain, https://phishing.example.com, on the webserver using the wildcard certificate.
Visitors to the phishing site are not likely to realize that they are on the phishing site because their browsers establish an HTTPS connection using the legitimate wildcard certificate. All these visitors often see is the green highlighted part of the URL which signals a valid site. Most visitors are not likely to scroll through the entire URL to discover the part of the URL which would arouse suspicion about its validity.
What do you need to know before using a wildcard certificate?
Wildcard certificates do offer certain benefits, but you should make sure that you are using them consciously and strategically. It helps to be very specific about what you plan to accomplish by using them. As outlined in a previous blog, here are the factors you should consider before you make your choice:
- 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. - 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 so, that may be a symptom that you’re not using the right solution to manage your machine identities. With proper levels of visibility, intelligence and automation, you can avoid wildcard certificates altogether and still end up with a more secure implementation that is just as easy to deploy and much easier to manage. - 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, you should have excellent controls in place to make sure the wildcard certificate is not copied and distributed to other systems. - 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.
Conclusion
The bottom line is that no one wants their organization’s name associated with a phishing attack. It tarnishes your reputation as well as the reliability of your brand. So, you need to make it as hard as possible for cybercriminals to infiltrate your domains and manipulate your encryption. Yes, there is an increased burden issuing and maintaining a server or application-specific certificate but with the right certificate management platform, you can both reduce risk and increase awareness through automation and intelligence.
So, it just makes sense to avoid using wildcard certificates on production systems. Instead, you should use subdomain-specific certificates that are rotated often. A compromised wildcard certificate can lead to serious repercussions. But you can avoid (or at least significantly mitigate) the potential impact of an attack by using short-lived, non-wildcard certificates.
Do you use any wildcard certificates on your domains?
(This post has been updated. It was originally published on May 7, 2021.)
Related blogs
