3 Security Risks That Should Make You Think Twice About Wildcard SSL Certificates

Wildcard SSL certificates offer genuine operational advantages: one certificate covers all subdomains, one renewal event, one certificate to install across multiple servers. For the right deployment, they are an efficient choice.

For the wrong deployment, they create specific, exploitable security risks that are different in kind from the risks of individual certificates. The US National Security Agency published an advisory in October 2021 specifically warning about wildcard certificate risks and the ALPACA attack technique. The agency recommended that NSS, DoD, and DIB administrators assess whether their wildcard certificate usage creates unmitigated risks that make their servers vulnerable.

This guide covers the three specific security risks in full: the ALPACA cross-protocol attack that exploits shared certificates across services, subdomain takeover attacks amplified by wildcard coverage, and the private key compromise blast radius that makes incident response significantly more difficult. For each risk, the preconditions are identified, the attack chain is described specifically, and the mitigations are listed.

Risk 1: The ALPACA Cross-Protocol Attack

ALPACA stands for Application Layer Protocols Allowing Cross-Protocol Attacks. It is a class of attack technique that exploits the combination of a wildcard TLS certificate and non-HTTPS services running on subdomains covered by that certificate. The NSA advisory on wildcard certificates cited ALPACA as the primary technical concern that motivated their guidance.

The preconditions for ALPACA

Three conditions must be present for ALPACA to be exploitable:

• A wildcard certificate (or multi-domain certificate) is used for both an HTTPS server and a non-HTTP TLS service on a different hostname within the same certificate’s scope
• An attacker can perform a man-in-the-middle position on the network or influence where the victim’s browser sends a request (via DNS manipulation, ARP poisoning, or network interception)
• The non-HTTPS server accepts the TLS connection, because the wildcard certificate is valid for the subdomain it is hosted on

The most common scenario involves an HTTPS server at www.example.com and a TLS-enabled FTP server, SMTP server, or other application protocol service at ftp.example.com or mail.example.com, all covered by *.example.com. Because the wildcard covers all these subdomains equally, the TLS connection is equally valid at all of them from a certificate perspective.

The attack chain

The attacker positions themselves to intercept or redirect the victim’s connection. When the victim’s browser attempts to connect to www.example.com, the attacker redirects the TCP connection to ftp.example.com (or another non-HTTPS service covered by the wildcard). The TLS handshake succeeds because the wildcard certificate is valid for both hostnames. The browser’s TLS stack sees a valid, trusted certificate and continues.

The browser then sends an HTTP request (including cookies for example.com, because the browser sees a valid HTTPS connection to what appears to be example.com) to what is actually an FTP server. The FTP server does not understand HTTP. It returns an FTP error response. Depending on the browser’s behavior and the server’s response, two exploitation paths exist.

Cookie exfiltration: The HTTP request the browser sent contained the victim’s session cookies for example.com in the request headers. If the FTP server’s error response is logged or accessible to the attacker, the cookies are captured. The attacker can use these cookies to authenticate as the victim without needing their password.

Cross-site scripting: In some configurations, the FTP server’s error response is reflected back through the connection in a way that the browser interprets as content from example.com. If the error message contains attacker-controlled content (from the HTTP request the FTP server didn’t understand), a stored XSS attack can execute in the victim’s browser in the context of example.com.

The NSA advisory noted that ‘while the conditions permitting this complicated technique to succeed are uncommon, ongoing research in this area is likely to identify additional configurations vulnerable to this type of malicious activity.’ ALPACA is not a simple opportunistic attack; it requires MitM capability or DNS influence. For enterprise environments and security-sensitive deployments, however, the attacker model includes nation-state and advanced persistent threat actors who have network access capabilities that make MitM viable.

Specific mitigations for ALPACA

• Use Application-Layer Protocol Negotiation (ALPN): TLS supports an extension called ALPN that allows the client and server to negotiate the application protocol during the TLS handshake. A server configured to only accept specific application protocols via ALPN will reject HTTP requests arriving at an FTP server because the protocol negotiation fails. Both the HTTPS server and the non-HTTPS service need ALPN configured.
• Do not use wildcard certificates across mixed-protocol services: If your FTP server, SMTP server, and HTTPS server are all on different subdomains and you use a wildcard, the attack surface exists. Use separate certificates for services that run different application protocols, even if this adds certificate management overhead.
• Restrict the scope of wildcard certificate use: The NSA advisory specifically recommends limiting wildcard certificates to environments where subdomains are closely controlled and serve the same service type. A wildcard covering only HTTPS web servers on subdomains is lower risk than one covering both HTTPS and non-HTTPS TLS services.
• Enable HTTPS-only with HSTS: HSTS (HTTP Strict Transport Security) with a preload policy ensures browsers only connect via HTTPS. This does not prevent the underlying ALPACA condition but reduces the browser-side opportunities for exploitation.

Risk 2: Subdomain Takeover Attacks Amplified by Wildcard Coverage

Subdomain takeover is a documented attack category where an attacker claims a subdomain that was previously pointing to an external service the organization no longer uses. When combined with a wildcard certificate, the impact extends from just occupying the subdomain to presenting what appears to be a fully legitimate, browser-trusted HTTPS site on that subdomain under your organization’s identity.

How subdomain takeover works

Organizations frequently create DNS entries pointing subdomains to cloud services: hosting platforms, CDN endpoints, SaaS applications, or other third-party services. When the organization stops using the service but forgets to remove the DNS entry, the subdomain continues resolving to the external service’s infrastructure. If the external service allows anyone to claim an unclaimed endpoint, an attacker can register the endpoint and receive traffic destined for your subdomain.

Without a wildcard certificate, this attack results in the attacker serving content on the subdomain but without a valid TLS certificate for your domain. Visitors would see an SSL error or an untrusted certificate warning. The attack is partially mitigated by the certificate trust requirement.

Why wildcard certificates amplify the risk

With a wildcard certificate installed on your main infrastructure, the attacker who takes over the subdomain does not receive your private key. However, the critical issue is different: browsers validate the TLS connection between the visitor and whatever server responds to the subdomain’s DNS record. If an attacker serves content at the subdomain and your wildcard certificate is being presented from your edge infrastructure (CDN, load balancer) that proxies all subdomains, the visitor gets a valid, trusted TLS session.

More precisely: if your CDN or reverse proxy automatically handles TLS termination for all subdomains using the wildcard certificate, and the subdomain has been taken over by routing the origin traffic to attacker-controlled servers, the CDN presents your valid wildcard certificate to visitors while forwarding their requests to the attacker’s content. The visitor sees a padlock, sees your domain, and has no technical signal that the content is not legitimate.

The result is a phishing site under your verified domain with valid HTTPS. Visitors cannot distinguish it from your legitimate subdomain. Password forms, payment pages, or other credential-harvesting attacks become highly effective because the TLS trust signals all appear correct.

Subdomain takeover combined with wildcard certificate coverage is considered one of the highest-severity web security vulnerabilities in bug bounty programs. Organizations including GitHub, HackerOne, Shopify, Uber, and many others have paid significant bounties for subdomain takeover findings. The combination of DNS misconfiguration and wildcard certificate creates a seamless impersonation opportunity that individual certificates would partially mitigate through the SSL error users would see without a valid cert for the taken-over subdomain.

Specific mitigations for subdomain takeover

• Audit all DNS records regularly: Maintain an inventory of every subdomain DNS record and verify that the service it points to is still active and under organizational control. Decommissioning a cloud service must include removing the DNS record.
• Remove DNS records before decommissioning services: The standard operational procedure should be: remove DNS record first, then decommission the service. The reverse order creates a window where the subdomain is unclaimed.
• Monitor subdomain DNS with Certificate Transparency: Certificate Transparency logs record every certificate issued for your domain. Services like crt.sh alert you when new certificates are issued for subdomains, which can indicate unexpected activity. While this does not directly catch wildcard-amplified takeovers (no new cert is issued), CT monitoring as a general subdomain awareness tool is valuable.
• Consider per-subdomain certificates for external-facing services with sensitive data: Subdomains that handle authentication, payment, or personal data are higher-value takeover targets. Individual certificates for these subdomains ensure that a takeover produces an SSL error rather than a seamlessly valid session.

Risk 3: Private Key Compromise Blast Radius

When a private key is compromised, the impact is determined by what the key protects. An individual certificate’s private key compromised: one domain. A wildcard certificate’s private key compromised: every subdomain of the domain, potentially dozens or hundreds of services.

How private key compromise happens

Private keys are compromised through server breaches (an attacker who gains root access can read the key file from disk), accidental exposure (keys committed to public repositories, included in container images, copied into application logs or environment variable dumps), insider threats, and in some cases through side-channel attacks on poorly protected key storage. The CA/B Forum requirement since June 2023 for hardware token or HSM storage of publicly trusted TLS private keys was specifically designed to reduce the most common server-breach key theft path.

Despite the HSM requirement for certificate issuance, keys can still end up on servers in deployable form after issuance. A wildcard private key installed on multiple web servers, a CDN origin certificate store, a load balancer, and a development server creates multiple potential access points for key theft. Each additional server where the key exists is an additional attack surface.

The scale difference between wildcard and individual certificate compromise

With individual certificates per subdomain, a private key compromise affects one subdomain. The incident response is surgical: revoke the specific certificate, issue a new certificate with a new key for that subdomain, deploy the new certificate to the server(s) that use it. Other subdomains are unaffected. The blast radius is contained.

With a wildcard certificate, the same key is typically deployed to every server handling any subdomain. Compromise of the key on any one of those servers means the attacker can impersonate any covered subdomain. The incident response is non-surgical: revoke the wildcard certificate (which immediately breaks all subdomains simultaneously), generate a new key pair, reissue the wildcard certificate with the new key, and deploy the new certificate to every server that uses it. This must happen across the entire infrastructure simultaneously. Any server that is not updated to the new certificate continues serving the old certificate, which is now revoked.

For an organization with tens of servers using a wildcard certificate, a key compromise event is a significant coordinated incident requiring immediate action across all of them. The operational blast radius of the response is proportional to how broadly the wildcard key was deployed.

The additional risk of accidental exposure

The wildcard private key’s breadth makes its accidental exposure more consequential. Development teams who need the certificate for local testing often request a copy of the wildcard key. Build systems that need to terminate TLS may receive the key. Backup systems may archive it. Each of these is an additional place where the key could be inadvertently committed to a repository, included in a container image, or exposed in a log.

Individual certificates for development and staging environments eliminate this risk: the production wildcard key never needs to leave production infrastructure. Development uses its own certificate (possibly from a local CA like mkcert). Staging uses a separate certificate. Only production servers hold the production key.

Specific mitigations for key compromise risk

• Limit wildcard key deployment scope: Install the wildcard private key only on servers that genuinely need it. If only three web servers serve public subdomains, do not install the wildcard key on the mail server, the internal admin panel, or the development environment.
• Use separate certificates for development and staging: Development environments should use locally-trusted certificates from mkcert or an internal CA, not copies of the production wildcard. This keeps the production key in production and prevents accidental exposure paths.
• Store private keys in HSM or hardware token: Hardware security modules make key extraction significantly harder. The CA/B Forum mandate for HSM storage applies to the issuance process; ongoing server deployment should also use HSM-backed key storage where possible.
• Maintain a wildcard key deployment inventory: Know exactly where the wildcard private key is installed. When a compromise occurs, this inventory determines the scope of the response. Without it, incident responders cannot confirm that all exposures have been addressed.
• Consider Certificate Transparency monitoring for unauthorized reissuance: If an attacker obtains your wildcard private key and requests a new wildcard certificate from any CA, CT logs record it. CT monitoring tools that alert on new certificate issuance for your domain can provide early warning of a key being used by unauthorized parties.

The Three Risks in Context: When Wildcard Is Still the Right Choice

The three risks described here are real and documented. They are also context-dependent. A wildcard certificate is not inherently insecure; it is specifically risky in specific deployment patterns.

An organization running three production web servers for three subdomains with no non-HTTPS TLS services, a well-maintained DNS inventory, and a wildcard key limited to those three servers faces manageable versions of all three risks. An organization with dozens of cloud services, mixed-protocol TLS across subdomains, and a wildcard key copied to every server that ever needed TLS faces all three risks at significant severity.

The decision whether to use a wildcard certificate should be an explicit risk assessment based on your actual deployment rather than a default choice made for cost convenience.

Frequently Asked Questions

What is the ALPACA attack and how does it use wildcard certificates?

ALPACA (Application Layer Protocols Allowing Cross-Protocol Attacks) exploits the combination of a wildcard TLS certificate and non-HTTPS services on subdomains covered by that certificate. An attacker who can redirect network traffic sends the victim’s browser to a non-HTTP service (like an FTP or SMTP server) on a subdomain covered by the wildcard. The TLS handshake succeeds because the wildcard certificate is valid for that subdomain. The browser then sends an HTTP request including session cookies to what is actually an FTP server. The session cookies may be captured by the attacker, or the FTP server’s error response may create a cross-site scripting vector in the victim’s browser.

What is subdomain takeover and why is it worse with a wildcard certificate?

Subdomain takeover occurs when an organization creates a DNS record pointing a subdomain to an external service, then stops using that service without removing the DNS record. An attacker who registers the now-unclaimed service endpoint can receive traffic for that subdomain. With an individual certificate, visitors see an SSL error because the attacker does not have a valid certificate for the domain. With a wildcard certificate and a CDN that presents the wildcard for all subdomains, visitors may see a valid HTTPS connection to the attacker’s content, because the CDN presents the legitimate wildcard certificate while forwarding traffic to the taken-over origin. This creates a high-credibility phishing scenario under the organization’s own verified domain.

Is it safe to use a wildcard SSL certificate?

It depends on the deployment. Wildcard certificates are safe in deployments where: they are used only for HTTPS services on all covered subdomains, the set of subdomains is small and actively maintained, the private key is deployed only to the servers that genuinely need it, and DNS records are kept current with decommissioning procedures. The specific risks arise when wildcard certificates span mixed-protocol TLS services (ALPACA), when subdomain DNS is not tightly maintained (takeover), or when the key is broadly distributed (blast radius). Assessing your deployment against these three risk patterns is more useful than a blanket recommendation.

What did the NSA say about wildcard certificates?

In October 2021, the NSA published a Cybersecurity Information Sheet titled ‘Avoid Dangers of Wildcard TLS Certificates and the ALPACA Technique.’ The agency specifically warned that a malicious actor who gains control of a wildcard certificate’s private key can impersonate any site within the certificate’s scope. The NSA also warned that using wildcard or multi-domain certificates across both HTTPS and non-HTTPS TLS services creates exploitable vulnerabilities through the ALPACA technique. The agency recommended that NSS, DoD, and DIB administrators assess their wildcard certificate usage, consider deploying individual certificates to isolate and limit compromise potential, and ensure that ALPN is enforced on all TLS-enabled services.