Wildcard TLS on Autopilot: How Every Tenant Subdomain Gets a Trusted Cert in Under 90 Seconds

You push a repo. A minute later https://your-app.onbex.co loads with a green padlock. No ticket, no CSR, no "your certificate is provisioning" banner — just HTTPS, as if it had always been there.

That trick looks like magic from the tenant side. From the platform side it is a small, well-understood machine: one wildcard certificate per zone, issued by Let's Encrypt, driven by cert-manager's DNS-01 solver, renewed long before it expires. This post opens the machine up: the exact steps between "deploy finished" and "trusted cert served," what each step costs in seconds, and why the two obvious alternatives — a certificate per tenant, or HTTP-01 validation — collapse the moment a platform has more than a handful of tenants.

One wildcard, not a cert per tenant​

The naive design is seductive: every time a tenant deploys my-app, issue a certificate for my-app.onbex.co. It mirrors the mental model — one app, one cert — and HTTP-01 validation makes it nearly free to implement. It also has a hard ceiling, and the ceiling is lower than most teams expect.

Let's Encrypt limits issuance to 50 certificates per registered domain per rolling 7 days, enforced as a token bucket that refills roughly one certificate every 202 minutes (rate limits). Every *.onbex.co certificate draws from the same bucket, because the registered domain is onbex.co no matter how many subdomains sit under it. A quiet week of thirty deploys is fine. A busy launch day with forty preview environments plus a few retries is not — the 51st issuance fails with rateLimited, and new tenants get "HTTPS eventually" while the bucket refills over days.

A wildcard certificate sidesteps the bucket almost entirely. One certificate for *.onbex.co covers an unbounded number of tenant subdomains, so the platform issues one certificate per zone regardless of tenant count and renews that same certificate on a fixed schedule. Let's Encrypt explicitly designs its limits so that renewing an existing certificate almost never hits a rate limit — the steady state of a wildcard deployment is one renewal every couple of months against a bucket that refills continuously. The per-tenant design, by contrast, burns quota on every deploy and has no steady state at all: quota consumption grows linearly with platform growth, which is another way of saying it is a launch-day outage waiting for a launch day.

There is a second, harder reason the wildcard wins: only DNS-01 validation can issue wildcard certificates. HTTP-01 proves control of a single hostname by serving a token over port 80, which says nothing about the infinite set of names a wildcard covers. A certificate authority will not take that on faith. DNS-01 proves control of the zone itself by writing a TXT record the CA can look up — and zone control is exactly what a wildcard asserts. So the design space was never really a choice: wildcards require DNS-01, and multi-tenant scale requires wildcards.

The 90 seconds, receipted​

"Under 90 seconds" is a claim about a pipeline with six stages. Here is the pipeline for a fresh *.onbex.co certificate, with what each stage actually does and where the seconds go.

1. Certificate requested (0s). When the platform provisions the zone, it creates a cert-manager Certificate resource naming *.onbex.co (plus the apex onbex.co, which the wildcard does not cover). Nothing has touched the network yet; this is a declaration of intent stored in etcd.

2. Order and challenge created (~1–2s). cert-manager translates the Certificate into an ACME order with Let's Encrypt, which responds with a DNS-01 challenge: publish a token as a TXT record at _acme-challenge.onbex.co and the CA will come looking for it. You can watch this happen as Order and Challenge resources appear next to the Certificate.

3. TXT record published via DNS API (~2–5s). The DNS-01 solver calls the DNS provider's API — Route53, Cloudflare, Google Cloud DNS — and creates the _acme-challenge TXT record. This is the step that makes DNS-01 operationally different from HTTP-01: the credential that matters is a DNS API token, not inbound port 80. No solver pods, no ingress juggling, no requirement that the domain already route anywhere.

4. Propagation self-check (10–60s, the long pole). Before telling Let's Encrypt to validate, cert-manager queries the zone's authoritative nameservers itself until the TXT record shows up. This is the stage that owns the variance in the whole pipeline: Cloudflare and Route53 typically propagate in seconds, while slower providers or misconfigured delegation can stretch this into minutes. cert-manager polls rather than sleeps a fixed interval, so a fast provider pays only for what propagation actually costs — but no solver can validate faster than the DNS it writes to. Every "why is my cert stuck pending" story you have ever heard lives in this stage.

5. CA validation and issuance (~5–15s). Once the self-check passes, cert-manager asks Let's Encrypt to validate. The CA looks up the TXT record from multiple network vantage points — a defense against BGP-hijack attacks that means your record must be visible from everywhere, not just from your cluster — and, satisfied, signs the certificate. cert-manager then deletes the TXT record; challenge hygiene is automatic, so the zone never accumulates stale _acme-challenge entries.

6. Secret written, ingress serves (~1–2s). The certificate and private key land in a Kubernetes Secret, the ingress controller picks up the rotation, and https://anything.onbex.co terminates TLS. Total wall-clock on a healthy provider: typically 30–60 seconds, comfortably inside the 90-second promise, with propagation as the only stage that can push it over.

Note what the tenant deploy path does not include: none of this runs per deploy. The wildcard already exists and already covers the new subdomain, so a tenant's first HTTPS request is served by a certificate that was issued weeks ago. "Under 90 seconds" describes provisioning the zone's automation, and every deploy after the first inherits it for free.

The one dependency you must get right​

If the pipeline above has a single point of failure, it is the DNS provider API. Everything else is Kubernetes-native and self-healing; the solver's ability to write TXT records is the one thing cert-manager cannot conjure on its own. Getting this dependency right is the difference between "HTTPS by default" and "HTTPS eventually." Concretely:

Least-privilege, zone-scoped credentials. The solver needs exactly one power: edit TXT records in the platform's zone. A Cloudflare API token scoped to Zone:DNS:Edit on onbex.co, or an IAM policy allowing route53:ChangeResourceRecordSets on the single hosted zone, is the whole credential. Operators who hand the solver a global API key get working certs and a lateral-movement path; scope it on day one, because the token lives in a Secret next to everything else.

A staging issuer for everything except production. Let's Encrypt allows only 5 failed validations per account per hostname per hour, and debugging a solver against production burns that budget fast. The standard layout is two issuers — staging for every test, production for the real zone — and a Certificate that points at staging until issuance succeeds end to end. Five minutes of setup saves an hour of staring at rateLimited errors.

Propagation tuning for your actual provider. cert-manager's defaults assume a reasonably fast provider. If your zone sits behind slow secondaries, the solver's propagation timeout needs to match reality, or challenges flap between "presented" and "failed" while the TXT record was fine all along. When a challenge sticks, kubectl describe challenge almost always points here — read the solver events before touching anything else.

A minimal production issuer shows how little configuration this actually takes:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: ops@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-key
    solvers:
      - dns01:
          route53:
            region: us-east-1

Swap the route53 block for cloudflare with an apiTokenSecretRef and the rest of the pipeline is identical — which is the point. The platform's TLS story is provider-agnostic except for this one stanza, and migrating DNS providers later means editing one solver, not redesigning issuance.

Renewal on autopilot, in an era of shrinking lifetimes​

Issuance is the exciting half; renewal is the half that pages you at 3 AM if it is missing. cert-manager's defaults encode a comfortable margin: a Certificate lasts 90 days and renewBefore defaults to 30 days, so renewal is attempted around day 60 with a full month of retry budget before expiry. A transient Let's Encrypt outage or a DNS API blip in week eight is a non-event — the controller just retries into a wide-open window.

That margin matters more every year, because certificate lifetimes are shrinking on an industry-wide schedule. Let's Encrypt is moving its default from 90 days to 45 days during 2026 and made 6-day short-lived certificates generally available in January 2026; the CA/Browser Forum's SC-081 ballot caps public TLS lifetimes at 200 days in March 2026, 100 days in 2027, and 47 days by March 2029. Each step down the ladder multiplies the cost of manual renewal and divides the cost of automation that already exists. A platform whose renewal path is "cert-manager reconciles a Certificate resource" absorbs the 45-day world by changing nothing; a platform whose renewal path involves a human, a calendar reminder, and a runbook absorbs it by hiring.

This is the deeper argument for the whole architecture: DNS-01 wildcard automation is not just the way to survive today's rate limits, it is the only posture that stays correct as lifetimes collapse. The renewal loop does not care whether the certificate lasts 90 days or 6 — it wakes up at two-thirds of whatever lifetime the CA grants and does the same TXT-record dance. Build it once, and the industry's roadmap becomes someone else's emergency.

The shape of the machine​

Zoom out and the design is almost boring, which is the highest compliment infrastructure can earn. One wildcard certificate per zone. One DNS-01 solver with a tightly scoped credential. One renewal loop with a 30-day retry window. No per-tenant issuance, no port-80 dance, no human in the path between git push and a trusted padlock.

The boringness is load-bearing. Every deploy-time tax a platform charges — a manual cert step, a provisioning delay, a quota that fails open into plaintext — compounds across tenants until "HTTPS by default" quietly becomes "HTTPS for most people, most of the time." The wildcard pipeline charges its cost once per zone and amortizes it across every tenant forever after. That is what autopilot means: not that certificates stopped expiring, but that expiry stopped being anyone's problem.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.