¶ºÒõ¹Ý

We work with many customers who must secure hundreds to thousands to tens of thousands of domains and subdomains. With the sheer scale of what you have to secure, it can feel like an immense weight to manage efficiently, especially as the threat landscape is increasing. The attack surface is increasing as trends like remote work have accelerated digital transformation, and now it’s not just a website that you have to secure but every digital interaction. Somehow you must balance security and efficiency across your entire certificate inventory without tipping the scale too far in either direction. You’re looking for the goldilocks solution that is just right for both making it easy to manage at scale and providing top-notch security so that your customers can continue to trust you.

Wildcard TLS certificates are an excellent example of an efficient solution that can quickly become insecure if not managed just right. On one hand, wildcards can be a simple way to secure theoretically up to unlimited subdomains. On the other hand, the more wildcards are reused, the more of a security threat they can become. That’s why we’re seeing many enterprises ban the use of wildcard certificates altogether, because if implemented incorrectly, wildcards are not secure.

In fact, the . The NSA warned that wildcard certificates are especially vulnerable to the , which exploits TLS servers using compatible certificates. Thus, understanding the risks of wildcard certificates is critical to improving your organization’s risk management. This post will dive into why wildcard certificates can be unsecure and options for balancing both efficiency and security in your certificate landscape.

What is a wildcard TLS/SSL certificate?

´¡â€¯ is a single certificate with an asterisk (*) in the domain name field that allows one certificate to secure a domain and multiple subdomains. Admins can theoretically secure infinite subdomains with a single wildcard certificate. Thus, can allow you to be more productive in how you purchase and distribute. However, just because you can secure hundreds or thousands of subdomains with a wildcard certificate, doesn’t mean you should.

What are the security risks of wildcard certificates?

While initially convenient to implement, wildcard certificates can be difficult to find and fix if anything goes wrong, which it may, given that cybercriminals can target and exploit wildcards. Unfortunately, making it easier for you to secure subdomains also makes it easier for attackers to compromise not only your main domain, but every subdomain using the same wildcard certificate.

In fact, the way that some admins use wildcards today resembles certificate pinning, a practice which we recommend avoiding. For instance, companies could use a single wildcard certificate in a thousand different places across various servers, including with external parties, because even though it is efficient, it is also highly insecure. If even one server is breached, then every domain using that certificate becomes vulnerable and the more agents you have handling your subdomains, the more you will need to share your private key, which introduces high risks. We’ve already covered why private keys should not be shared in a previous post, but the worst-case scenario is if hackers gain access to the private key of a wildcard certificate, they could use it to create any subdomain, secure it with the same wildcard certificate and impersonate your legitimate brand for phishing campaigns. The that stolen private keys of wildcard certificates can also be in water hole, advertising or man-in-the-middle attacks, damaging your reputation. Thus, although wildcard certificates seem efficient upfront, the security risks if an organization doesn’t adequality control and monitor the wildcard certificate defeat the efficiency that wildcard certificates are trying to solve in the first place.

Compromise of a secured application through ALPACA exploitation (Source: )

Automation is the ultimate solution to balance security and efficiency because it can be implemented in a secure way without overwhelming staff. Automation accomplishes efficiency over your certificate inventory even more effectively than wildcard certificate can. Forget the headache of excel spreadsheets; modern PKI solutions automate certificate request, renewal, validation, alerts, revocation and much more so that you can simplify certificate lifecycle management, save time and reduce risks. That’s why nine out of ten enterprises are already moving towards PKI automation.

¶ºÒõ¹Ý CertCentral^® has multiple ways to set up automation, including ACME, automation tools and APIs. For basic automation in any business type, CertCentral can manage multiple ACME clients from its UI that will run on Windows and Linux servers. For unlimited flexibility and customization, APIs can directly integrate CertCentral with your system or platform of choice. Finally, for scalable and managed automation features, ¶ºÒõ¹Ý has a suite of enterprise automation tools that seamlessly integrate with other OEM solutions, such as largely deployed Load Balancers, F5, Amazon AWS, Citrix and more. Learn how to prepare to automate PKI certificates and workflows in a recent blog.

When to buy a wildcard certificate

You can still if you need to secure several sub domains, and can do so internally and securely. Wildcard certificates do offer cost savings and fast implementation. However, before purchasing a wildcard certificate, you should understand the security risks and implement controls and monitoring to ensure that your wildcard certificate cannot be exploited. For instance, you should limit the usage of wildcard certificates and ensure that private keys are stored and protected using best practices. Furthermore, if needed ¶ºÒõ¹Ý can help to better secure your wildcard use with specific techniques. For instance, we’ve helped several of our customers utilize a separate certificate signing request (CSR) for each wildcard they issue. This will create a duplicate certificate using a different CSR for each issuance, even though it is the same wildcard, which can provide more separation and thus more security.

You may also want to consider a multi-domain or Subject Alternative Name (SAN) certificate as a more secure option. Similar to a wildcard, a SAN certificate allows the certificate to cover multiple URLs but restricts it to a specific list of URLs. However, automation is likely the better long-term solution to balance both security and efficiency across your certificate inventory.

Get the 2022 TLS Best Practices Guide

Download our TLS Best Practices Guide, 2022 Edition to learn more about how you can simplify certificate management and enable automation while ensuring security over your entire certificate inventory.