Certificate provisioning

Certificate provisioning is the operational pipeline that takes "a customer just added their domain" and ends with "the edge can serve that domain over HTTPS." It looks simple in a single-domain demo and gets hard at multi-tenant scale.

The steps for one cert

1. Customer adds acme.com in your dashboard.
2. Your app verifies DNS (the CNAME points at your edge).
3. Your provisioning service generates a key pair.
4. It calls Let's Encrypt via ACME to request a cert.
5. Let's Encrypt issues a challenge (HTTP-01 or DNS-01).
6. Your service satisfies the challenge.
7. Let's Encrypt issues the cert.
8. Your service writes the cert to your edge's cert store.
9. Edge starts serving acme.com over HTTPS.

Step 1–3 are instant. Step 4–7 takes 5–30 seconds. Step 8 depends on your edge architecture (could be instant, could be 30 seconds for cert distribution).

Where it gets hard

Rate limits. Let's Encrypt caps you at 300 new orders per account per 3 hours. Above that, you queue.

Renewal at scale. Each cert is valid 90 days. If you have 10,000 certs, you need to renew ~110 per day. Forever. That's a real cron job.

Cert distribution latency. If your edge runs in 10 regions, every new cert has to reach all 10. If it doesn't, some users get an old / missing / wrong cert and the handshake fails.

Failed renewals. Customer changes their DNS, breaking your challenge. Your renewal fails. The cert expires. The customer's domain breaks. You need monitoring to catch this before users notice.

Cold-start latency. First request to a brand-new domain has to wait for the cert. That's a 5–30 second wait the user experiences. Solution: issue the cert as soon as DNS verification passes, not on first request.

What a custom-domain API does for you

All eight steps, plus renewal, plus monitoring, plus rate-limit management. You POST a hostname and the rest is somebody else's problem.