Replacing Wildcard Certificates with Automated Single-Domain Issuance

The proliferation of microservices, edge computing, and cloud-native architectures has fundamentally changed how infrastructure teams handle DNS and TLS. A decade ago, an organization might have managed a few dozen subdomains. Today, dynamic CI/CD pipelines and ephemeral container environments mean a single engineering department might spin up and tear down hundreds of subdomains in a single week.

Historically, IT and security teams relied heavily on Wildcard certificates (*.example.com) to secure these assets. It was a convenient solution to a scaling problem: buy one certificate, deploy the same private key across every server, and only worry about a single expiration date.

However, the landscape of cryptographic security has shifted. Driven by the push for 90-day maximum certificate validity periods, the finalization of Post-Quantum Cryptography (PQC) standards, and the adoption of Zero Trust architectures, the convenience of Wildcard certificates has transformed into a massive security liability.

Organizations are now actively abandoning manual processes and shared keys in favor of automated, single-domain issuance. This shift requires fundamentally rethinking how subdomains are provisioned, secured, and monitored.

The Security Debt of Wildcard Certificates

While Wildcard certificates are cost-effective and easy to provision, they violate the core tenets of modern security frameworks.

The primary issue is the cryptographic blast radius. When you use a Wildcard certificate, the same private key must be distributed across multiple servers, load balancers, and ingress controllers. If a single vulnerable development server is compromised and the Wildcard private key is extracted, the attacker can impersonate any subdomain under that apex domain. They can intercept traffic to your production APIs, spoof your authentication portals, or launch devastating man-in-the-middle attacks.

Furthermore, Wildcard certificates complicate compliance. Under frameworks like PCI-DSS v4.0, which mandates strict management of cryptographic keys, using a Wildcard certificate across both in-scope payment processing subdomains and out-of-scope marketing subdomains can inadvertently drag your entire infrastructure into the scope of a PCI audit. NIST SP 1800-16 also explicitly warns against the risks of private key proliferation associated with Wildcards.

Finally, Wildcards do not cover multi-level subdomains. A certificate for *.example.com secures api.example.com, but it will trigger browser warnings for v1.api.example.com, forcing teams to manage overlapping Wildcards and compounding the key distribution problem.

Evaluating the Alternatives for Subdomain Security

As infrastructure teams phase out Wildcards, they must choose between two primary alternatives for securing subdomains.

Subject Alternative Name (SAN) / Multi-Domain Certificates

A SAN certificate allows you to secure a specific, known list of subdomains on a single certificate (e.g., mail.example.com, shop.example.com, portal.example.com).

The Verdict: SAN certificates successfully limit the blast radius compared to Wildcards, as the private key is only valid for the explicitly listed subdomains. They are highly effective for legacy load balancers or static environments. However, they are far too rigid for dynamic cloud environments. Adding or removing a single microservice requires generating a new Certificate Signing Request (CSR), re-issuing the certificate from the Certificate Authority (CA), and redeploying it. In a CI/CD environment where subdomains are created automatically, this friction is unacceptable.

Automated Single-Domain Certificates

The modern standard is to issue a unique, single-domain certificate for every individual subdomain.

The Verdict: This approach offers perfect cryptographic isolation. If the private key for test-api.example.com is compromised, your production environment remains secure. This aligns perfectly with Zero Trust principles. The obvious drawback is the sheer volume of certificates. Managing thousands of unique certificates with varying expiration dates is impossible without robust automation. This strategy relies entirely on the ACME protocol (RFC 8555) to remove human intervention from the lifecycle.

The Hidden Threat of Subdomain Takeovers

Moving to single-domain certificates solves the blast radius problem, but the sheer volume of subdomains introduces a different vulnerability: orphaned infrastructure and shadow IT.

Developers frequently spin up subdomains for testing—such as promo-staging.example.com—pointing a DNS CNAME record to a cloud resource like an AWS S3 bucket, a Heroku app, or a GitHub Pages site. When the project ends, the developer often deletes the cloud resource but forgets to remove the DNS record.

This creates a dangling DNS record, opening the door to a Subdomain Takeover. An attacker can scan for these dangling records, create a new resource on the target cloud provider (e.g., a new S3 bucket with the exact name the DNS is looking for), and effectively hijack the subdomain. Because the attacker now controls the resource the subdomain points to, they can use an automated CA like Let's Encrypt to generate a perfectly valid, trusted TLS certificate for your company's subdomain.

Hackers famously exploited this exact vulnerability against Epic Games, bypassing Cross-Origin Resource Sharing (CORS) policies to steal authentication tokens and compromise millions of user accounts.

To prevent this, organizations must decouple certificate issuance from manual ticketing systems and implement continuous discovery.

Automating Issuance with Kubernetes and ACME

To successfully adopt a single-domain strategy, automation must be baked into the infrastructure layer. In cloud-native environments, cert-manager has become the standard tool for automating certificate lifecycles within Kubernetes.

When a developer deploys a new service and defines an Ingress route, cert-manager automatically detects the new subdomain, communicates with an ACME-compliant CA, completes the domain validation challenge, and injects the resulting certificate into the Ingress controller (like NGINX or Traefik).

HTTP-01 vs. DNS-01 Challenges

The ACME protocol verifies domain ownership using challenges. While the HTTP-01 challenge is common for public-facing websites, the DNS-01 challenge is vastly superior for comprehensive subdomain management.

DNS-01 proves control over a domain by requiring you to provision a specific TXT record. Because it relies on DNS rather than HTTP routing, you can use DNS-01 to issue certificates for internal, private-network subdomains (e.g., internal-db.dev.example.com) without ever exposing them to the public internet.

Here is an example of how to configure a ClusterIssuer in Kubernetes using cert-manager, Let's Encrypt, and AWS Route53 for automated DNS-01 challenges:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-production-dns
spec:
  acme:
    # The ACME server URL
    server: https://acme-v02.api.letsencrypt.org/directory
    # Email address used for ACME registration
    email: security@example.com
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-production-account-key
    # Enable the DNS-01 challenge provider
    solvers:
    - dns01:
        route53:
          region: us-east-1
          hostedZoneID: Z1234567890ABCDEF
          accessKeyID: AKIAIOSFODNN7EXAMPLE
          secretAccessKeySecretRef:
            name: route53-credentials
            key: secret-access-key

With this configuration, any new Ingress resource requesting a certificate will trigger cert-manager to automatically create the necessary Route53 TXT record, obtain the certificate, and delete the TXT record afterward—all in seconds, with zero human involvement.

Comparing Subdomain Management Tooling

Implementing this automation requires selecting the right tooling for your environment. The landscape is generally divided into three categories:

1. Cloud-Native & DevOps Tools: Tools like cert-manager and HashiCorp Vault (which acts as an excellent internal PKI and ACME server) are ideal for Kubernetes-heavy environments. Smallstep's Step-CA is another powerful option for running an internal ACME CA to secure service-to-service communication (mTLS) with extremely short-lived certificates.
2. Cloud Provider Solutions: AWS Certificate Manager (ACM), Azure Key Vault, and Cloudflare SSL/TLS provide seamless, out-of-the-box subdomain automation, provided you are locked into their respective ecosystems. Cloudflare, in particular, excels at edge termination and automated single-domain issuance for distributed web assets.
3. Enterprise CLM Platforms: For large enterprises dealing with complex compliance requirements, multiple public and private CAs, and a mix of on-premise and cloud infrastructure, platforms like Venafi or Keyfactor offer governance and policy enforcement that open-source tools often lack.

Securing the Certificate Supply Chain

Automation solves the issuance and renewal problem, but you still need visibility and governance to ensure rogue certificates aren't being issued for your subdomains.

Implementing CAA Records

Certificate Authority Authorization (CAA) is a DNS record that dictates exactly which CAs are permitted to issue certificates for your domain and its subdomains. If an attacker manages to hijack a subdomain via a dangling CNAME, a strict CAA record can block them from obtaining a certificate from their preferred automated CA.

A standard CAA configuration in a BIND zone file looks like this:

example.com.    IN  CAA 0 issue "letsencrypt.org"
example.com.    IN  CAA 0 issue "digicert.com"
example.com.    IN  CAA 0 issuewild ";"

In this example, only Let's Encrypt and DigiCert are allowed to issue single-domain certificates. The issuewild ";" directive explicitly forbids any CA from issuing a Wildcard certificate