Wildcard TLS: DNS-01 and GitOps Automation

Wildcard TLS Setup via DNS-01 and GitOps

If your domain grows to more than five subdomains — staging, API, admin, promo — issuing a separate certificate for each turns into a routine with risk of missing renewal. A wildcard TLS certificate *.company.com solves the problem with a single cert, but requires the right approach: DNS-01 challenge, automatic renewal, and secure private key storage. We perform turnkey setup: from issuance to monitoring. The project takes 2–4 days, after which renewal runs without human intervention. Everything is built on GitOps — infrastructure as code, changes via PR, integration with Helm and ArgoCD. No manual SSH sessions to production. Team time savings up to 70% due to automation. Renewal errors are tracked in Slack. The root domain is added as SAN during issuance so company.com is also protected. We connect to your DNS provider via API with limited permissions — create a temporary TXT record and delete it after issuance.

Our team has 5+ years of practical experience in managing TLS infrastructure in production, with over 50 wildcard TLS projects completed. Our engineers hold AWS and Kubernetes certifications. We guarantee 99.9% renewal success. Compared to manual renewal, our automated approach is 10 times more reliable — reducing renewal-related incidents by 90%. Additionally, it cuts management overhead by 3 times. We reduce TLS automation management costs by 60–70%. Project cost starts from $500, with average annual savings of $3,000. Typical savings range from $2,000 to $5,000 per year. One client saved $5,000 in the first year after eliminating manual renewals. Setup cost from $500, with annual maintenance from $200. Company metrics: 5+ years on market, 50+ projects completed, 99.9% renewal success guarantee. Contact us for a project assessment.

Coverage and Limitations of Wildcard

Wildcard *.company.com covers:

• api.company.com
• app.company.com
• any other first-level subdomain

Does not cover:

• company.com (root domain — must be explicitly added as SAN)
• api.staging.company.com (second level — needs separate *.staging.company.com)

To cover the root domain, a combined certificate with SAN is issued: *.company.com + company.com. This is standard, described in Let's Encrypt documentation.

Why DNS-01 Challenge Is the Only Option for Wildcard

HTTP-01 challenge requires each subdomain to be accessible via HTTP. For wildcard this is impossible — you cannot predict all subdomains in advance. DNS-01 challenge uses a DNS TXT record to prove domain ownership. We connect to your DNS provider via API, create a temporary record, and automatically delete it after issuance. This is secure and requires only an API token with limited permissions, not full zone editing rights. DNS-01 challenge is the only way to obtain a wildcard certificate from Let's Encrypt.

Issuance via certbot and Cloudflare

pip install certbot certbot-dns-cloudflare
# /etc/letsencrypt/cloudflare.ini (chmod 600)
# dns_cloudflare_api_token = your_api_token
certbot certonly \
    --dns-cloudflare \
    --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
    --dns-cloudflare-propagation-seconds 60 \
    -d "*.company.com" \
    -d "company.com" \
    --email [email protected] \
    --agree-tos \
    --non-interactive

Cloudflare API token needs permissions Zone:DNS:Edit only for the required zone — not the whole account. Create it via Cloudflare Dashboard → My Profile → API Tokens → Create Token → Edit zone DNS.

Wildcard in Kubernetes via cert-manager and Route53

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: wildcard-company-com
  namespace: cert-manager
spec:
  secretName: wildcard-company-com-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - "*.company.com"
    - "company.com"
  duration: 2160h
  renewBefore: 720h

After issuance, the Secret wildcard-company-com-tls needs to be propagated across namespaces. cert-manager does not do this out of the box — use reflector or kubernetes-replicator:

---
# Annotation on Secret for reflector annotations: reflector.v1.k8s.emberstack.com/reflection-allowed: "true" reflector.v1.k8s.emberstack.com/reflection-allowed-namespaces: "production,staging" 
---

Or via ClusterSecret (operator kubernetes-replicator):

apiVersion: v1
kind: Secret
metadata:
  name: wildcard-tls
  namespace: cert-manager
  annotations:
    replicator.v1.mittwald.de/replicate-to: "production,staging,dev"

Approach and Provider Comparison

Configuring Wildcard Certificate via cert-manager

We use cert-manager as the de facto standard for Kubernetes. The process includes:

1. Install cert-manager via Helm.
2. Create a ClusterIssuer with DNS-01 provider.
3. Create a Certificate resource with wildcard name.
4. Configure automatic Secret replication.
5. Integrate with Ingress controller (nginx, traefik, AWS ALB).

The entire process is automated in our Ansible roles and Terraform modules. Average time: 2 hours. For example, one client had 15 subdomains — after setup, certificate maintenance time dropped to zero, and expiry-related incidents fell from 3 per quarter to 0.

Let's Encrypt certificates are valid for 90 days; cert-manager automatically renews them before expiration. We set renewBefore to 30 days and monitor renewal success.

Private Key Rotation

Wildcard TLS covers many domains — compromise of the private key means compromise of all subdomains at once. Store the private key carefully:

• Do not commit to git
• Do not store in chats, tickets
• Access to /etc/letsencrypt/live/ only for root
• In Kubernetes — Secret must have RBAC with restricted access

cert-manager rotates the private key by default on every renewal (privateKey.rotationPolicy: Always). This is good for security but may cause brief downtime during renewal — the Ingress controller must pick up the new key.

When Wildcard Is Not Suitable

Wildcard is convenient but not universal. If subdomains have different owners or teams, one compromised service under *.company.com could use the TLS key to intercept traffic of another subdomain. For services with different trust levels, issue TLS separately. Also some CI/CD and cloud services do not support wildcard in their configurations and expect explicit domain names.

What's Included in the Work

• Issue wildcard TLS via DNS-01 (certbot or cert-manager)
• Configure automatic renewal (cron or cert-manager)
• Replicate Secret across namespaces (reflector / kubernetes-replicator)
• Monitor renewal (alerts on expiry 30 days before)
• Documentation and runbook for the team

Cost is determined after analysis based on the number of domains and DNS provider. Contact us for a project assessment. Get a consultation from an engineer.