The first time I hit a Let's Encrypt rate limit it cost me forty-five minutes on a Saturday. I was migrating a client's multi-tenant platform, each tenant on its own subdomain, each subdomain needing its own cert, and the issue-5-certs-per-week-per-root-domain limit kicked in somewhere around tenant twelve. Certbot reported the error politely. The seven tenants at the back of the queue got nothing.
I switched those tenants to ZeroSSL that afternoon. Same ACME protocol, same certbot (just a different directory URL), same 90-day cert lifetime, different CA. The issuance went through, the platform shipped, nobody noticed. That's the ZeroSSL story in one paragraph: when Let's Encrypt's operational boundaries hit yours, there's a free, ACME-compatible alternative that often doesn't.
What ZeroSSL actually is
ZeroSSL runs a publicly-trusted certificate authority (cross-signed, recognized by browsers and mobile OSes without any manual trust) that supports two ways to get certs:
-
Automatic issuance via ACME, the same protocol Let's Encrypt pioneered (RFC 8555). Any ACME client works: certbot, acme.sh, Caddy, Traefik, cert-manager in Kubernetes, even the little Python scripts people write themselves. You point at ZeroSSL's ACME directory URL instead of Let's Encrypt's and the rest is identical.
-
Manual / dashboard issuance via the ZeroSSL UI, upload a CSR, get a cert. Useful for one-off certificates on machines that don't run an ACME client (some embedded devices, legacy appliances, specific enterprise appliances that only accept manually-installed certs).
The free tier issues 90-day certs (same as Let's Encrypt) with no cap on total certificates per account. Their rate limits are looser than Let's Encrypt's, specifically on per-account issuance velocity and per-domain reissuance, which is the bit that matters for the use cases below.
Case 1 — Rate-limit fallback
Let's Encrypt enforces a "50 certificates per registered domain per 7 days" limit as the primary constraint for most operators. If you're running a multi-tenant SaaS where each tenant gets {slug}.yourapp.com, and you onboard 80 customers in one week, you hit the ceiling. Let's Encrypt publishes the limits publicly and they're a reasonable protection against abuse, but they don't care about your launch schedule.
The standard mitigation is to split issuance across multiple apex domains (yourapp.com, yourapp.io, yourapp.net) so you get 50 per week per apex. That works if you have them. If you don't, or if you do and still hit the limit, ZeroSSL is a drop-in fallback.
The Caddy pattern for automatic failover:
{
# Try ZeroSSL first for new issuances, fall back to Let's Encrypt
# if ZeroSSL is down or rate-limited. Caddy rotates automatically.
acme_ca https://acme.zerossl.com/v2/DV90
acme_ca_root https://letsencrypt.org/certs/isrgrootx1.pem
email admin@yourapp.com
}
Certbot is more explicit, you register a separate account for ZeroSSL because their ACME endpoint requires EAB (External Account Binding) credentials:
certbot register --server https://acme.zerossl.com/v2/DV90 \
--eab-kid YOUR_KID --eab-hmac-key YOUR_HMAC \
--email admin@yourapp.com
certbot certonly --server https://acme.zerossl.com/v2/DV90 \
-d tenant-123.yourapp.com
EAB credentials come from your ZeroSSL account dashboard. They're free to generate, but the setup is one extra step compared to Let's Encrypt's anonymous registration. Once configured, the rest is identical.
Case 2 — Wildcard certs without a compliant DNS-01 provider
Wildcard certs (*.example.com) require DNS-01 validation on every major CA, Let's Encrypt included. DNS-01 means your ACME client needs API access to your DNS provider so it can create a TXT record at _acme-challenge.example.com, wait for propagation, and then the CA checks that record to prove you control the domain.
For Cloudflare, Route53, Google Cloud DNS, DigitalOcean, and the other big providers, this is trivial, the ACME clients have native plugins and the DNS API is well-behaved. For smaller registrars (some country-TLD registrars, some legacy hosting providers, some corporate DNS setups behind a VPN) there's either no API or the API is too slow for LE's challenge timeout.
ZeroSSL supports the same DNS-01 flow as Let's Encrypt but has slightly more patient timing, it'll retry verification for longer before giving up. That makes it the practical choice for domains whose DNS provider takes 2-5 minutes to publish a new TXT record instead of the 15-30 seconds Let's Encrypt expects. When I've hit this, it was on a client whose domain was with a regional registrar that updated DNS at minute boundaries; Let's Encrypt timed out about 40% of the time, ZeroSSL succeeded about 95% of the time.
Case 3 — IoT fleets with individual device certs
This is the one where ZeroSSL earns its keep. Say you have 2,000 ESP32 devices deployed at customer sites, each running a small HTTPS server for a local admin UI, each on a unique DNS name under a domain you control. Each device needs a cert. Each cert needs to renew every 60-90 days. The renewal needs to work unattended for years.
Let's Encrypt will issue those certs, but the rate limit (50 per domain per week) caps your initial rollout speed at 50 devices per week per apex, a 40-week rollout minimum for 2,000 devices. ZeroSSL's limits make the same rollout doable in about three weeks.
The bigger win is the ops story. ZeroSSL lets you generate an EAB credential per environment, so each fleet of devices authenticates as itself. If one device is compromised and you revoke its credentials, the other 1,999 keep renewing. Let's Encrypt's ACME-v2 accounts are all-or-nothing; compromise one cert's account key and you have to rotate every device.
The cert-manager snippet for a Kubernetes-deployed IoT device registry:
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: zerossl-iot
spec:
acme:
server: https://acme.zerossl.com/v2/DV90
email: iot-ops@example.com
externalAccountBinding:
keyID: YOUR_EAB_KID_FROM_DASHBOARD
keySecretRef:
name: zerossl-eab-secret
key: hmac
privateKeySecretRef:
name: zerossl-account-key
solvers:
- dns01:
cloudflare:
apiTokenSecretRef:
name: cloudflare-api-token
key: token
Stored alongside your existing letsencrypt-staging and letsencrypt-prod ClusterIssuers. Devices specify issuerRef: zerossl-iot on their Certificate resource; the cluster handles the rest.
Where ZeroSSL falls short
Three honest caveats.
EAB setup adds a step. You can't use ZeroSSL as a true anonymous drop-in for Let's Encrypt, the EAB credentials are required. For a one-off cert on a single server, Let's Encrypt remains easier. ZeroSSL's advantage kicks in at scale, where the one-time EAB setup amortizes.
The free tier has a revocation-free-quota limit. If you need to revoke a cert (suspected key compromise, domain transfer, etc.) you can revoke it on the free tier but only a few per month; bulk revocations require a paid plan. In practice most operators never hit this, Let's Encrypt also charges for support on bulk operations, but it's worth noting if your threat model assumes frequent revocations.
Root cert age. Let's Encrypt's ISRG Root X1 has been in every modern browser and mobile OS for years. ZeroSSL's cross-signed chain is also widely trusted but is worth testing on any unusually old clients (pre-2020 Android TVs, Windows 7 machines that haven't run updates, certain industrial control systems). For a normal web deployment in 2026, both are fine; for exotic embedded fleets, test first.
How to pick
Default to Let's Encrypt. It's anonymous, infinitely scalable for most operators, and has a decade of operational maturity. When a specific constraint, rate limits on bulk issuance, a slow DNS provider, an IoT fleet that needs a different ops posture, makes Let's Encrypt painful, ZeroSSL is the first alternative I'd try. It speaks the same protocol, interoperates with every ACME client, and costs nothing for most use cases.
Running both in parallel with automatic failover (the Caddy pattern above) is the best-of-both approach: Let's Encrypt for most issuance, ZeroSSL as the bucket brigade when the LE bucket is empty.
Related reading
- Caddy, The Reverse Proxy That Handles Its Own Certificates
- Hosting & Indexing Health Checks: Fix GSC Errors Fast
- Security Headers as a Trust Signal
If you're building a self-hosted stack where cert ops is one piece among many, the $100 Network walks through the full owned-infrastructure picture: The $100 Network.
Fact-check notes and sources
- ZeroSSL ACME endpoint and EAB requirement: zerossl.com/documentation/acme/ (accessed 2026-04-20)
- Let's Encrypt rate limits (50 certs per registered domain per week): letsencrypt.org/docs/rate-limits/
- ACME protocol specification (RFC 8555): datatracker.ietf.org/doc/html/rfc8555
- External Account Binding (EAB) specification (RFC 8555, §7.3.4): datatracker.ietf.org/doc/html/rfc8555#section-7.3.4
- Caddy multi-CA
acme_caconfiguration: caddyserver.com/docs/caddyfile/options#acme-ca - cert-manager ACME issuer with EAB: cert-manager.io/docs/configuration/acme/#external-account-bindings
