Skip to content

ACME and Automated Issuance

Stub — being built out

This is a stub page. The spine — what a cert is, why validation exists, HTTP-01 vs DNS-01 — lives on Who Said You Could Trust That?. This page expands the mechanics: how certs get issued and renewed without a human in the loop. Outline below; prose coming.

The main page answers which thing do you control — the box or the zone? This page answers how does the robot orchestrate the proof, the issuance, and the renewal — forever, without you?

What this page will cover

  • The ACME protocol, end to end — account registration, order, challenge, validation, finalize, download. What each step is actually proving, and where it can stall.
  • The challenge dance in practice — what your ACME client (Certbot, acme.sh, Caddy's internal one, CertiNext, cert-manager) is doing on your behalf, and what it needs permission to do (write a file vs. write a DNS record).
  • Renewal is the whole point — certs are short-lived on purpose. A 90-day cert renewed automatically is more secure than a 2-year cert renewed by a human who'll forget. What breaks when renewal silently fails, and how to alarm on it before the expiry, not after.
  • Wildcards and DNS-01 — why wildcards require DNS-01, what programmatic DNS access costs you in attack surface (that API token can rewrite your zone), and how to scope it.

The part you're actually building toward

Issuing on the fly for user-selected subdomains

This is the pattern behind a platform that hands each user their-name.example.com and provisions TLS automatically — and it's exactly the shape of an ACME-on-demand setup like CertiNext fronting a Kubernetes ingress.

The page will walk the real decision tree:

  • Wildcard cert (*.example.com, one DNS-01 issuance) vs. per-name issuance (one cert per user subdomain, issued on demand). The tradeoff is blast radius vs. operational chatter: one wildcard key everywhere, or many short-lived keys you have to orchestrate.
  • In Kubernetes specifically — how cert-manager (or the platform's equivalent) maps Ingress/Certificate resources to ACME orders, where the DNS-01 solver credentials live, and how to keep that solver token from becoming the softest target in the cluster.
  • Rate limits and the "thundering herd" — what happens when 500 user subdomains all want issuance in the same five minutes, and why staging environments exist.
  • Failure modes that only show at scale — partial chains served to clients, renewal storms, a DNS provider that rate-limits you, and the difference between "the cert exists" and "the cert is being served correctly."

This is the page to read before wiring ACME into a multi-tenant ingress. Get the trust model from the main page first; the mechanics here only make sense once the why is solid.