Securing Subdomains at Scale Without Wildcard Certificates

Managing SSL/TLS certificates for subdomains has fundamentally shifted from a periodic administrative chore into a critical pillar of Zero Trust Architecture. With the explosion of microservices, cloud-native deployments, and edge computing, modern organizations are routinely managing thousands of active subdomains.

Simultaneously, the cryptographic landscape is shrinking the margin for error. Google’s "Moving Forward, Together" initiative has set the stage for reducing the maximum validity of public TLS certificates from 398 days to just 90 days. While this is not yet a strict CA/B Forum baseline requirement, the industry is operating on the assumption that 90-day lifespans will become mandatory by the end of 2025.

When certificates expire every 90 days, manual subdomain certificate management becomes mathematically impossible at scale. This reality, combined with the deprecation of wildcard certificates in high-security environments, is forcing DevOps and SecOps teams to architect entirely new, fully automated Certificate Lifecycle Management (CLM) strategies.

The Security Liability of Wildcard Certificates

Historically, organizations relied on a single wildcard certificate (e.g., *.example.com) to secure all subdomains. You generated one private key, paid for one certificate, and deployed it across dozens of load balancers, reverse proxies, and edge servers.

Today, security frameworks and compliance mandates—including PCI DSS v4.0 and the EU's NIS2 Directive—strongly discourage wildcard certificates due to their massive blast radius.

The Blast Radius Problem

When you use a wildcard certificate, the corresponding private key must be distributed to every server hosting a subdomain. If a single edge server or internal microservice is compromised and the private key is exfiltrated, the attacker can impersonate any subdomain under your primary domain. They can host trusted, encrypted phishing sites, intercept traffic via man-in-the-middle (MITM) attacks, or bypass mutual TLS (mTLS) authentication boundaries.

Subdomain Takeovers via Dangling DNS

Wildcard certificates become particularly toxic when combined with "dangling DNS." In a typical cloud environment, a developer might spin up an AWS S3 bucket or an Azure App Service, point a subdomain (like promo.example.com) to it, and later delete the cloud resource when the project ends.

If they forget to delete the corresponding DNS CNAME record, the DNS is left "dangling." An attacker can scan for this, claim the abandoned cloud resource name in AWS or Azure, and effectively take over the subdomain. Epic Games suffered a high-profile vulnerability exactly like this when hackers found an abandoned AWS CloudFront distribution linked to an active Epic Games subdomain.

If a wildcard certificate is in play, or if the domain lacks strict issuance controls, the attacker can easily serve a valid, trusted TLS certificate on their hijacked subdomain, making phishing pages indistinguishable from legitimate company infrastructure.

The Multi-Domain (SAN) Bottleneck

An alternative to wildcards is grouping multiple subdomains into a single Subject Alternative Name (SAN) certificate. However, this creates operational friction. If you group 50 subdomains onto one SAN certificate and later decommission a single microservice, you must revoke and reissue the entire certificate for the remaining 49 subdomains.

The modern best practice is the Principle of Least Privilege for Certificates: Issue specific, single-domain certificates for specific subdomains (e.g., app1.example.com), each with a unique private key, fully automated via the ACME protocol.

Locking Down Issuance with CAA Records

Before automating issuance, you must secure your DNS perimeter. A Certificate Authority Authorization (CAA) record is a DNS-level security control that dictates exactly which Certificate Authorities (CAs) are permitted to issue certificates for a domain and its subdomains.

If an attacker compromises a subdomain or attempts to provision a rogue certificate via a free CA, the CA will check the CAA record. If the CA is not explicitly listed, the issuance request is rejected.

To restrict issuance exclusively to Let's Encrypt, you would configure the following DNS records:

; Restrict standard certificate issuance to Let's Encrypt
example.com.    IN  CAA 0 issue "letsencrypt.org"

; Restrict wildcard issuance (if strictly necessary for legacy systems)
example.com.    IN  CAA 0 issuewild "letsencrypt.org"

; Specify an email for CAs to report policy violations
example.com.    IN  CAA 0 iodef "mailto:security@example.com"

By default, a CAA record on the root domain cascades down to all subdomains. You can also override this by placing specific CAA records on specific subdomains if different business units use different CAs.

Automating Subdomains with ACME and DNS-01 Challenges

The Automated Certificate Management Environment (ACME) protocol is the gold standard for automating certificate issuance and renewal. When an ACME client requests a certificate, the CA must validate that the client actually controls the requested subdomain.

CAs typically offer two primary challenge types: HTTP-01 and DNS-01.

Why HTTP-01 Fails for Internal Subdomains

The HTTP-01 challenge requires the CA to make an HTTP request over the public internet to port 80 of the subdomain being validated. While this works for public-facing websites, Zero Trust architectures dictate that internal subdomains (e.g., database-primary.internal.corp) must also be secured with valid TLS certificates. Because these internal subdomains are not exposed to the internet, a public CA cannot reach them to complete an HTTP-01 challenge.

The Power of DNS-01

The DNS-01 challenge solves this by proving control at the DNS layer rather than the HTTP layer. The ACME client requests a certificate, and the CA provides a unique token. The ACME client then uses the DNS provider's API to create a temporary TXT record at _acme-challenge.<subdomain>. The CA queries the public DNS for this TXT record, verifies the token, and issues the certificate.

Because the CA only needs to query public DNS, you can use DNS-01 to issue certificates for internal, private-IP subdomains without exposing them to the internet.

Here is an example of automating a subdomain certificate using Certbot and the AWS Route53 DNS plugin:

# Install Certbot and the Route53 DNS plugin
apt-get install certbot python3-certbot-dns-route53

# Ensure AWS credentials are in place (usually via IAM roles in production)
export AWS_ACCESS_KEY_ID="your_access_key"
export AWS_SECRET_ACCESS_KEY="your_secret_key"

# Request a certificate for a specific subdomain using DNS-01
certbot certonly \
  --dns-route53 \
  --non-interactive \
  --agree-tos \
  --email admin@example.com \
  -d api.internal.example.com

Cloud-Native Implementation: cert-manager for Kubernetes

In containerized environments, subdomains are typically tied to Ingress controllers. cert-manager is the CNCF-backed standard for automatically provisioning and injecting TLS certificates into Kubernetes clusters.

To implement the single-domain automated strategy in Kubernetes, you first define a ClusterIssuer configured for DNS-01 challenges.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-production-dns
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: security@example.com
    privateKeySecretRef:
      name: letsencrypt-production-dns-account-key
    solvers:
    - dns01:
        route53:
          region: us-east-1
          # In production, use IRSA (IAM Roles for Service Accounts) 
          # instead of hardcoding access keys

Next, instead of attaching a massive wildcard certificate to your Ingress, you define a specific Certificate resource for the individual microservice's subdomain: