To issue TLS certificates on demand for wildcard-DNS subdomains such as sslip.io, Temps issues each certificate lazily at the first TLS handshake instead of provisioning every hostname up front. Because the Temps operator does not control the sslip.io DNS zone, it cannot complete DNS-01 for a wildcard certificate. Pingora's certificate_callback finds no certificate, fails the first handshake quickly, and starts a Let's Encrypt HTTP-01 order in the background. A later connection succeeds after the certificate is available.
TL;DR: On the first TLS handshake for an eligible hostname, Pingora's certificate_callback finds no cert, fails the handshake fast, and starts a background Let's Encrypt HTTP-01 order; the retry succeeds. The guards are what make it safe: a zone gate, in-flight dedup so a flood of connections to one new host fires exactly one issuance, a concurrency semaphore, an hourly cap, exponential backoff, and a 120-second issuance timeout. The hard scoping rule: issue only for stable hostnames, never ephemeral per-deployment ones, or every deploy churns certs and trips rate limits.
Why Can't You Use a Wildcard Certificate for sslip.io Subdomains?
The clean way to do multi-tenant HTTPS is a wildcard certificate. You prove control of example.com once via a DNS-01 challenge (drop a TXT record at _acme-challenge.example.com) and Let's Encrypt hands you a *.example.com cert that covers every subdomain you'll ever create. One cert, infinite hostnames, zero per-tenant work.
