Replacing Wildcard Certificates with Automated Subdomain Issuance

Managing SSL/TLS certificates used to be a predictable, annual IT chore. You bought a certificate, installed it on a web server, and set a calendar reminder to renew it next year. Today, the explosion of microservices, cloud-native architectures, and edge computing means organizations are managing hundreds or thousands of subdomains.

Compounding this scale is the impending shift in certificate lifespans. Google’s "Moving Forward, Together" initiative proposes reducing the maximum validity of public TLS certificates from 398 days to just 90 days. While the CA/B Forum is still finalizing the exact timeline, enterprise engineering teams are already treating this as a baseline reality. Furthermore, with NIST finalizing the first set of Post-Quantum Cryptography (PQC) algorithms like ML-KEM in August 2024, organizations are facing a massive upcoming cryptographic migration.

You cannot manually swap out RSA/ECC certificates for quantum-resistant ones across thousands of endpoints every 90 days. Manual subdomain certificate management is now mathematically impossible at scale.

This shift requires a fundamental change in how we provision, secure, and monitor subdomain identities. The industry consensus is clear: it is time to deprecate the wildcard certificate and move to automated, single-domain issuance.

The Security Liability of Wildcard Certificates

For years, the wildcard certificate (*.example.com) was the default strategy for scaling HTTPS. It offered infinite scalability for first-level subdomains, low initial cost, and easy provisioning. However, in modern distributed systems, wildcards introduce unacceptable security risks.

The Blast Radius Problem

When you use a wildcard certificate, you must distribute its corresponding private key to every server, load balancer, and container that hosts a subdomain. This inherently violates the Principle of Least Privilege.

If an attacker compromises a low-priority development server hosting test.example.com, they don't just gain access to that server. They steal the private key that also secures api.example.com, billing.example.com, and auth.example.com. Sharing a private key across dozens of environments—often via insecure CI/CD variables, shared drives, or email—exponentially increases the risk of key theft and maximizes the blast radius of a single breach.

This isn't just a theoretical vulnerability. Epic Games famously suffered a massive, prolonged outage because a single wildcard certificate expired. Because the certificate was manually deployed across hundreds of backend microservices, identifying and updating every instance took hours, resulting in significant global downtime.

Subdomain Takeovers

Bug bounty platforms like HackerOne are filled with reports of subdomain takeovers at major corporations. This occurs when a DNS record points to a de-provisioned cloud resource, such as a deleted AWS S3 bucket, an Azure Web App, or a GitHub Pages site.

If an attacker registers that abandoned resource on the cloud provider, they take control of the subdomain. If your organization relies on a permissive wildcard certificate, the attacker instantly gains a valid, trusted HTTPS connection for the hijacked subdomain. This creates a perfect, highly convincing vector for phishing and session hijacking, as the browser will display a trusted padlock for legitimate-service.yourcompany.com.

Why SAN Certificates Fall Short in DevOps

Multi-Domain or Subject Alternative Name (SAN) certificates allow you to secure multiple specific subdomains (e.g., app.example.com and api.example.com) on a single certificate.

While SAN certificates solve the wildcard blast radius problem by explicitly defining which subdomains are covered, they introduce severe operational bottlenecks. Every time a development team spins up a new microservice or deprecates an old one, the central IT or security team must generate a new Certificate Signing Request (CSR), reissue the certificate, and redeploy it to all associated endpoints.

In a dynamic DevOps environment where infrastructure is ephemeral, this friction slows down deployments and encourages developers to bypass security controls by spinning up "shadow IT" subdomains with self-signed certificates.

The Modern Standard: Individual Automated Certificates

Security frameworks like Zero Trust Architecture (ZTA) and compliance mandates like PCI-DSS v4.0 explicitly require strict management of cryptographic keys and unique identities for every microservice. The modern standard is to provision an individual, automated certificate for every single subdomain.

A compromised key for dev.example.com should have zero impact on prod.example.com. To achieve this without burying your operations team in manual work, you must rely on the Automated Certificate Management Environment (ACME) protocol, originally defined in RFC 8555.

Automating Issuance in Kubernetes with cert-manager

In containerized environments, subdomains are typically routed through Ingress controllers. Using cert-manager, the absolute standard for Kubernetes certificate automation, allows developers to provision subdomain certificates seamlessly.

Instead of manually requesting a certificate, a developer simply adds an annotation to their Ingress resource. cert-manager intercepts this, communicates with an ACME provider like Let's Encrypt, completes the domain validation challenge, provisions the certificate, and stores it as a Kubernetes Secret.

Here is a practical example of how simple this looks in practice. First, you define a ClusterIssuer:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: security@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    solvers:
    - http01:
        ingress:
          class: nginx

Then, the developer defines their Ingress for a new subdomain:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - api.example.com
    secretName: api-example-com-tls
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

With this configuration, the entire lifecycle of the api.example.com certificate—including the upcoming 90-day renewals—is handled entirely by the cluster.

Securing Internal Subdomains with DNS-01 Challenges

The HTTP-01 challenge used in the example above requires the CA to reach your server over the public internet to verify domain ownership. But what about internal subdomains like internal-db.corp.example.com that should never be exposed publicly?

For internal subdomains, you must use the ACME DNS-01 challenge. Instead of placing a file on a web server, the ACME client proves control of the domain by provisioning a specific DNS TXT record (e.g., _acme-challenge.internal-db.corp.example.com).

To automate this, your certificate management tool needs API access to your DNS provider (such as AWS Route53, Cloudflare, or Google Cloud DNS).

Critical Security Note: When automating DNS-01 challenges, you must strictly scope the API credentials. If you grant cert-manager full write access to your entire DNS zone, a compromised cluster could result in a total DNS hijack. Always use granular IAM policies that restrict the API token to modifying only TXT records, and ideally only records prefixed with _acme-challenge.

Enforcing Certificate Authority Authorization (CAA)

As you decentralize certificate issuance to automated tools and development teams, you need guardrails to prevent attackers from using rogue CAs to issue certificates for hijacked subdomains.

A Certificate Authority Authorization (CAA) record is a DNS record that specifies exactly which CAs are permitted to issue certificates for your domain and its subdomains. If an attacker attempts to get a certificate from a CA not listed in your CAA records, the CA will refuse the request.

Implementing CAA is a quick, high-impact security win. A standard DNS zone file configuration looks like this:

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issue "amazon.com"
example.com.  IN  CAA  0 iodef "mailto:security@example.com"

In this example, only Let's Encrypt and Amazon Trust Services are allowed to issue certificates for example.com and all its subdomains. The iodef tag ensures that if any other CA receives a request for your domain, they will immediately email your security team about the policy violation.

The Automation Blind Spot: Why Independent Monitoring is Mandatory

Shifting to automated, single-domain certificates solves the blast radius problem and handles the 90-day lifespan mandate. However, automation introduces a new risk: silent failures.

In 2023, Starlink suffered a global outage due to an expired ground-station certificate. While not a public subdomain issue, it perfectly highlights the modern reality of infrastructure: when you automate thousands of certificates, manual tracking guarantees eventual failure, but unmonitored automation is equally dangerous.

ACME clients can crash. Cloud provider API tokens used for DNS-01 challenges can expire. Web