What is a Wildcard Certificate?
A wildcard certificate serves as a type of public key certificate (such as SSL/TLS) designed to protect all first-level subdomains under a singular domain name. This means that rather than acquiring a separate certificate for every subdomain, a single wildcard certificate can be employed to safeguard all these subdomains collectively.
As Nick Hunter, senior technical manager for Venafi, wrote in a recent blog post: “A wildcard certificate is a public key certificate used by all subdomains within a larger domain. Using a wildcard certificate on a publicly facing webserver, you can quickly secure unlimited subdomains that are all encrypted by the same certificate. Unfortunately, so can cybercriminals.”
So, for example, if you had a wildcard certificate for venafi.com you could possibly cover:
- www.venafi.com
- mobile.venafi.com
- shop.venafi.com
- cloud.venafi.com
At first glance, wildcard certificates seem like an efficient solution for rapidly implementing HTTPS across multiple subdomains. By purchasing a single certificate, you cover an unlimited number of subdomains, which can indeed be more cost-effective and simpler to expand. However, their management might not be as straightforward. The convenience they offer initially can quickly dissipate when challenges arise. For instance, should there be a need to upgrade your domain's wildcard certificate to a more secure EV (Extended Validation) certificate, you might encounter a complicated situation with numerous subdomains requiring updates. Yet, the most compelling argument against using wildcard certificates is their relative lack of security, which potentially makes them a gateway for phishing attacks.
Why are wildcard certificates important?
I could use one wildcard certificate, whether it was SSL or TLS, and use it to secure my website for all these subdomains. Without a wildcard certificate, I would need one certificate for each of these subdomains to secure them all. In the case above I would have to buy 4 individual certificates and each one would be set to secure each of the 4 subdomains.
With a wildcard certificate purchase, you can usually also cover your "naked domain." This would mean that I could add venafi.com in addition to the 4 subdomains that my wildcard certificate already covers and now cover a 5th subdomain without any additional cost.
How are wildcard certificates used?
Wildcard certificates are typically used to cover all domains with the same registered root making it simple to administer. However, the flexibility that comes with utilizing wildcard certificates also creates significant security risks since the same private key is used across multiple systems, thereby increasing the risk of compromise across the organization:
- Compromised web server—using a wildcard certificate on public-facing webservers increases the risk that cybercriminals will use the webserver to host malicious sites for phishing campaigns.
- Stolen private key—gaining access to a wildcard certificate’s private key provides attackers with the ability to impersonate any domain for the wildcard certificate.
- Fake certificates—cybercriminals can trick a CA into issuing a wildcard certificate for a fictitious company. Once a hacker has the fictitious company’s wildcard certificates, the attacker can create subdomains and establish phishing sites.
PKI: Are You Doing It Wrong?
The Benefits of Wildcard Certificates
The "low-hanging fruit" of using a single certificate to secure multiple domains is that it appears easier to manage, more affordable, and helpful for your website on the SEO (Search Engine Optimization) front.
It may seem easier to manage a wildcard certificate because you only have to worry about issuing and renewing one certificate for all your subdomains. (But we’ll talk more about the reality of wildcard certificate management later). If you are a bootstrapped company on a tight budget, you can secure 15 different subdomains with just one certificate.
The above-mentioned benefit also helps you save money. Since there is only one certificate to issue, manage, and renew—your overhead costs are significantly low in comparison to buying and managing multiple single domain certificates.
For most companies, buying one certificate for all their subdomains also comes down to the speed of deployment. For instance, most CAs issue a wildcard TLS/SSL certificate within a few hours from your purchase. Once you have the certificate, it doesn’t take more than a few minutes for you to install it to all your domains. Compare that with the process of buying extended validation (EV) certificates, which easily takes a few days because most CAs have a long and complicated verification process behind issuing EV certificates.
Another benefit is that whether you are using one or multiple TLS/SSL certificates, HTTPS will increase the chances of your website ranking on top of search engine pages. It’s old news but one that you must be aware of— Google counts SSL certificates as a lightweight ranking signal to encourage all businesses to encrypt their domains.
From a business perspective, this is a critical step towards maintaining your brand reputation. Not having an SSL certificate means search engines will show a warning message to the visitors when they enter your website from the search results page. It’s the quickest way to create a bad customer experience and lose customers’ trust in your brand.
Using just one security certificate across all subdomains not only saves you a ton of money but, also secures your domains and builds trust in your brand.
The Risks of Wildcard Certificates
To understand the risks associated with wildcard certificates, it's important to know their characteristics. Wildcard certificates function as public key certificates that apply to all subdomains under a broader domain umbrella. By implementing a wildcard certificate on a server accessible to the public, it becomes possible to efficiently encrypt an unlimited number of subdomains with a single certificate. However, this convenience also extends to cybercriminals, who can exploit the same certificate for malicious purposes.
Using a wildcard certificate is like locking your house's front door while leaving the other doors open. The rooms inside your house are secure, but only until someone breaches the main door—then every room is vulnerable. Once they have access to your rooms/domains, cybercriminals can easily launch phishing attacks because they have gained the insider privilege to create new subdomains from within your server.
There are several methods by which cybercriminals might exploit wildcard certificates:
Compromised web servers:
Employing a wildcard certificate on servers that face the public can heighten the likelihood of cybercriminals setting up fraudulent sites on those servers for phishing activities.
Wildcard certificates may help you secure your public domains at an encryption level, but the risks involved can cut deeper.
For example, if you are using a single wildcard cert to secure several domains, cybercriminals can use that to their advantage. A wildcard certificate is a single-point encryption parameter; if it fails, your entire security structure falls apart. Compromising your main encryption gate gives bad actors access to the private keys all your subdomains shared, which they can then use to break into those subdomains.
Let’s say a cybercriminal is able to bypass the wildcard certificate that www.amazon.com was using to secure its host domain and other subdomains.
Now they can create a number of spoofed URLs such as:
- www.amazan.com/sign-up
- www.amazon.com.login-user.info
- www.amazon.account.getbill-service.com/signin/
At a glance, all of these URLs look like legitimate Amazon sites. But if you look closely, they are fake clones of the Amazon URL.
You’re probably asking yourself, “Who would fall for something so simple? Surely anyone would recognize the illegitimate website.” But that’s not always true.
According to recent research from Venafi, attackers commonly outfit their phishing sites with lookalike domains that are differentiated by just a few characters or even homoglyphs designed to look like the legitimate domain. Most phishing sites also use long URLs to take advantage of the fact that a user is not likely to scroll through the entire URL.
Setting up a subdomain is exactly how cyber-criminals exploited a wildcard certificate security issue on the Malaysian Police portal in the summer of 2013 and used the portal for a phishing attack.
Stolen private keys:
Should cybercriminals obtain the private key associated with a wildcard certificate, they could masquerade as any subdomain safeguarded by that certificate.
Over the past five years, there has been a significant increase in malware aimed at hijacking keys and certificates, alongside the emergence of a bustling market for these stolen credentials. The activities of BlackTech, particularly their deployment of PLEAD and DRIGO to expropriate D-Link certificates for malware authentication, serve as further evidence of cybercriminals orchestrating sophisticated assaults to pilfer encryption assets from organizations. Similar to the breach of a web server, acquiring the private key of a wildcard certificate grants an intruder the power to mimic any domain covered by a wildcard certificate (*.example.com).
When cyber-criminals compromised DigiNotar back in 2011, the attackers were able to steal a Google wildcard certificate(*.google.com). Using the stolen wildcard certificate, an attacker would be able to set up a fake website for any Google service and then direct victims to the fake service by poisoning DNS services. Because the attacker is using a stolen wildcard certificate, the victim receives no warning when visiting the fake Google website.
In addition to compromising a certificate authority like DigiNotar, attackers can prey upon users with the help of digital certificates in other ways. Illustrating this fact is the March 2015 case of someone having obtained a privileged email account for Microsoft’s live.fi domain and abused that access to register a bogus SSL certificate, which bad actors could have leveraged to conduct phishing and/or man-in-the-middle (MitM) attacks. The security industry has also at times spotted vulnerabilities that could allow bad actors to spoof SSL servers via wildcard certificates.
Cybercriminals are also getting better at either stealing encryption keys from Certificate Authorities (CAs) such as Symantec, DigiCert, or GoDaddy or buying them from the Dark web marketplace.
Fake certificates:
By deceiving a Certificate Authority (CA) into issuing a wildcard certificate for a non-existent entity, cybercriminals could leverage these certificates to forge subdomains and launch phishing websites.
Digital attackers are specifically turning to Let’s Encrypt to obtain certificates for fictitious companies. They’re doing so as a matter of ease and cost. On the one hand, certificates obtainable from Let’s Encrypt are free, which lowers the costs of conducting phishing attacks. At the same time, Let’s Encrypt is automated, making it less difficult to obtain certificates in the first place.
Given the advantages explained above, it’s not surprising Venafi found that Let’s Encrypt accounted for 84 percent of the digital certificates issued to lookalike domains. The service issued 15,000 certificates containing the word “PayPal” between January 1, 2016 and March 6, 2017, for example. Of those issued certificates, 95 percent of them were used for phishing sites.
Simply put, you can’t rely too much on wildcards for encrypting your domains as they can open the backdoors for cybercriminals to launch phishing attacks.
Wildcard certificates can also cause outages
Managing wildcard certificates becomes especially challenging when a single certificate is being used across many websites or critical business infrastructure. Invariably, there is always a system that didn’t make the list, and when the original wildcard certificate expires the system that wasn't updated goes down.
Wildcard certificates are difficult to track. Although they are straightforward to deploy, managing a single wildcard SSL certificate across a vast network of servers, potentially numbering in the dozens or hundreds, presents its own set of challenges, particularly when it reaches its expiration simultaneously across all sites.
Walter Goulet, product manager for Venafi, explains: “When a wildcard certificate is deployed widely, there is an inability to schedule expiration rates around high traffic usage periods of business-critical infrastructure. As a result, when that wildcard certificate nears expiration, you need to coordinate renewal and installation on all systems that are using that certificate at the same time, or at least start the renewal and replacement process well before the certificate expires which reduces the effective lifetime of the wildcard certificate.
In healthcare, for example, organizations often have a no-touch policy on infrastructure that supports open enrollment for a period of two to three months. This concept also applies to retail organizations like Walmart and Target who have IT blackout periods around Black Friday and the holidays. Unfortunately, with wildcard certificates, when you have one certificate that is used to secure a large number of applications and services, management becomes a real nightmare and critical infrastructure may need to be maintained during no-touch periods putting your business at risk of disruption.”
So much for the idea of easier management! It seems convenient at first, but is not-so-great when the time comes to untangle the web at renewal.
Should cybercriminals penetrate your domain, they obtain the capability to generate as many subdomains as they desire, all secured using your wildcard certificate. What makes this situation dire is that these subdomains will seem legitimate since they're verified by your wildcard certificate. Such unauthorized subdomains provide a platform for cybercriminals to create harmful websites for use in phishing schemes.
How is this accomplished? Every subdomain created under the domain on a server equipped with a wildcard certificate will be secured by this same certificate. Take, for instance, a web server with a wildcard certificate for the domain https://example.com. Any individual with server access can establish a subdomain, like https://phishing.example.com, and secure it with the wildcard certificate.
To the unsuspecting visitor, the phishing site might not raise any alarms as their browser secures an HTTPS connection with the genuine wildcard certificate. The visible part of the URL, often displayed in green, signals to many users that the site is secure, without them scrutinizing the full URL to spot any discrepancies that might hint at the site's dubious nature.
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, 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 (which Venafi supports) 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.
- 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.
How to Replace Wildcard Certificates
If you aren’t sure what to replace your wildcard certificate with, we’ve got a few recommendations. There are two main types of certificates we recommend replacing your wildcard certificates with to improve security.
- First, the most secure thing to do is to have a single certificate associated with a domain since if that certificate is compromised, the resulting exposure will be limited to only one domain.
- The second option is to use a Subject Alternative Name (SANs) certificate for those customers that are using load balancers that are serving multiple websites from the same infrastructure. With a SANs certificate you can associate it with multiple sub-domains, e.g. mail.example.com, outlook.example.com, and firewall.example.com.
Epic Games’ Wildcard Certificate Outage: A Real-World Example
In April 2021, Epic Games, known for blockbuster titles such as Fortnite and Rocket League, faced a significant service disruption, rendering millions of players unable to access their accounts or play games. The root of this outage was an expired wildcard SSL certificate.
This particular certificate had been deployed across numerous production services within AWS, leading to its extensive impact. The downtime sparked considerable frustration among the gaming community, with many expressing their discontent on various social media platforms.
Here’s what happened:
Certificate Expiry: At midday UTC, an essential internal certificate reached its expiration. This lapse affected a wildcard certificate that was integral to the functioning of numerous backend services, leading to significant service interruptions in the popular Epic Games products Fortnite, Rocket League, Houseparty, Epic Online Services, and the Epic Games Store.
Incident Response: The incident management protocol was activated promptly. The expired certificate was discovered to be the source of the incident within 12 minutes and the team initiated the renewal process.
Remedial Action: By 12:37 PM UTC, a refreshed certificate had been issued and was being distributed across the necessary backend services over the ensuing 15 minutes. During remediation, there were 25 personnel directly engaged in the resolution of this problem, with additional support from the Player Support team, Community team, Engineering team, and Production team.
Aftermath: The swift renewal of the certificate allowed for the restoration of most services within an hour. Nonetheless, the initial downtime revealed several underlying IT framework vulnerabilities, leading to additional complications for the Epic Games Launcher and Epic Games Store. Post-certificate renewal, Epic Games Launcher crashed due to an unforeseen spike in requests, revealing limits in system scalability and resilience. After resolving the Epic Games Launcher outage and unblocking all clients, the Epic Games Store faced high demand, resulting in additional issues that the Epic team had to resolve to bring the store fully back online.
This event serves as a cautionary tale about the inherent risks associated with wildcard certificates. Since these certificates cover multiple subdomains under a single certification, their expiration can lead to broad service interruptions.
For organizations utilizing wildcard certificates, it's crucial to vigilantly monitor their expiry dates and ensure timely renewal to circumvent such issues. Epic Games' ordeal, which took approximately five and a half hours to rectify, was shared openly with the industry as an educational narrative, demonstrating their commitment to swiftly addressing and rectifying the problem.
Should you still use wildcard certificates?
Clearly, attackers are comfortable with using wildcard certificates for phishing email attacks and other attacks. Fortunately, security controls and solutions can help block an attack. By putting these defenses in place, you increase the effort that a malicious actor must take to compromise your network. Your goal is to make compromising your network so expensive that cyber-criminals would rather focus their attention on someone else. As the saying goes: When a lion chases you, you don’t need to be the fastest runner; you just have to be faster than the person behind you.
You can make your organization more costly to exploit by avoiding wildcard certificates. Although wildcard certificates make business operations simpler, they provide a tremendous opportunity to any cyber-criminal who compromises your web server or steals a wildcard certificate’s private key.
Prevent cybercriminals from exploiting the security of your wildcard certificate for nefarious activities. It's recommended to refrain from employing wildcard certificates on systems in production, particularly those accessible to the public. Opt for certificates specific to each subdomain, ensuring they are frequently updated. The risks associated with a compromised wildcard certificate can have grave consequences. However, by adopting non-wildcard certificates with a short validity period, you can substantially lessen the potential damage from a security breach.
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 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 pipeline.