Wildcard certificates are appealing to IT teams, but they are a sign of potential configuration management issues, and if compromised, they can introduce significantly more risk than regular SSL/TLS certificates. Unlike many configuration management issues,
however, wildcard certificates are trivially visible to external parties, thanks to certificate transparency logs, so they can also create reputational risks during third-party-risk assessments. This piece explains the dangers inherent in wildcard
certificates and offers recommendations for those who choose to use wildcard certificates.
What are Wildcard Certificates?
SSL/TLS certificates are used to secure network communications, and each has a subject field that denotes which hostnames it can be used to protect. Traditionally, the subject field contains a fully qualified domain name (FQDN) specifying a single server
name. By contrast, a wildcard certificate allows IT administrators to use a single certificate to secure communications for any server name in the domain. Wildcard certificates can also be extended to support multiple subdomains by using the subject
alternative name field, a configuration that significantly compounds the risk.
Organizations can obtain an SSL/TLS certificate either by working through a trusted certificate authority (CA) or by signing the certificate with its own CA (aka self-signing). It’s common for enterprises to use a mix of certificates issued from
trusted CAs and self-signed certs. Typically, self-signed certificates are only used for internal communications, while those issued from trusted CAs are used for external communications.
Trusted CAs often advocate against the use of wildcard certificates and charge more for them, but they are hardly unbiased in this. After all, they charge for every certificate issued, so if organizations need SSL/TLS certificates for 50 servers on a
domain, they can either pay the CA for 50 individual certificates or one wildcard certificate. However, this bias doesn’t mean the risks are unfounded.
Use of Wildcard Certificates
IT’s desire to use wildcard certificates for operations is very real. The motivation is understandable, because use of wildcard certificates is easier and IT teams are typically overworked and understaffed. Certificate management has also become
increasingly challenging with new standards limiting the maximum lifetime of a certificate signed by a trusted CA. This change means IT teams must rotate certificates more frequently. At the same time, ubiquitous encryption is further increasing the
burden on these IT teams by increasing the number of certificates being managed.
Use of wildcard certificates typically underscores issues with an organization’s certificate management. It may also be indicative of other systemic issues relating to security and configuration management. When wildcard certificates have multiple
subdomains wildcarded in the subject alternative name field, this risk increases dramatically.
Potential Risks of Wildcard Certificates
The first and most obvious risk of using a wildcard certificate is the increased impact of a compromise. If a certificate using the FQDN as the subject (e.g., www.infectedby.me) is compromised, the impact is limited to just that server. However, the compromise
of a wildcard certificate (e.g. *.infectedby.me) allows attackers to pose as any system in the infectedby.me domain.
This risk is especially significant when considering protocols besides HTTPS that are secured with certificates, for example, encrypted email traffic (specifically SMTPS). Suppose an attacker compromises a web server, potentially due to an unpatched content
management system. Either because of configuration management issues or because the underlying OS has unpatched local privilege escalation vulnerabilities, the attacker is able to steal the certificate. If the organization is using a wildcard certificate,
the attacker could use it to pose as the organization's SMTPS server in a man-in-the-middle attack.
Revoking a Wildcard Certificate
Security professionals frequently note that in the unlikely event a wildcard certificate is compromised, it can be revoked. Once the certificate is revoked, the browser (or other client) would learn of this through Online Certificate Status Protocol (OCSP)
or certificate revocation lists (CRL). However, as researcher Scott Helme noted, revocation as a security mechanism is effectively broken. We cannot count on revocation
servers being available at the time the stolen certificate is used (e.g., during an attack).
While this problem is not unique to wildcard certificates, using such a certificate increases the attack surface significantly.
Perfect forward secrecy (PFS) is also not a panacea. If it isn't in use, encrypted traffic captured through eavesdropping can be decrypted if the private key is compromised. Even when organizations say their servers support PFS, that doesn’t mean
all clients will use PFS. There still exists some risk that encrypted traffic captured today will be decrypted later.
Suppose a vulnerable web server is using a wildcard certificate. The attacker compromises the server due to a vulnerable library or framework, such as Struts. The attacker then privilege escalates and steals the wildcard certificate. If the same wildcard
certificate is also in use on other servers and services, such as an email server (this is common), the attacker could decrypt email traffic captured passively. The wildcard certificate doesn’t play into the initial attack, but it expands the
damage resulting from any successful intrusion.
Potential Reputational Risks Exist
Because wildcard certificates are publicly visible, they may create a reputation risk for organizations. In the wake of the SolarWinds compromise, more organizations than ever before
are performing third-party risk assessments. Even if the use of wildcard certificates has never been an issue for your organization before, expect more scrutiny as time passes.
Advice for Using Wildcard Certificates
While wildcard certificates aren’t themselves a security vulnerability, they can significantly increase the impact of a successful attack and should be used only as an exception – not as a standard operating procedure. To limit the issues,
organizations using wildcard certificates should consider:
- Limiting wildcard certificates to single domains and not use subject alternative names.
- Threat model the impacts from a compromise involving the proposed wildcard certificates, noting that OCSP, CRLs and PFS are all imperfect controls.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.