Dodging the Wall: How I Avoid Let’s Encrypt Rate Limits with SANs, Wildcards, and Calm ACME Automation

Ever had that moment when your deploy goes green, you sip your coffee, and then—bam—Let’s Encrypt says “too many requests” and your launch party turns into a rate-limit support group? I’ve been there. More times than I care to admit. The first time it happened to me was on a Friday evening (of course), with a marketing campaign scheduled for Monday. A bunch of micro-sites, each getting its own shiny certificate, and I thought, “What’s the worst that could happen?” Well, I met the rate-limit ceiling the hard way.

Here’s the thing: Let’s Encrypt is generous and reliable, but it does protect itself (and the internet) with guardrails. Those guardrails—the rate limits—look scary when you hit them, but they’re surprisingly manageable when you design around them. In this post, I’ll share the playbook I use these days: when to use SAN certificates versus a wildcard, what to watch out for with HTTP-01, DNS-01, and TLS-ALPN-01 challenges, and the small process tweaks that keep renewals smooth and drama-free. We’ll also talk about staging, slow-roll renewals, and the subtle art of not asking the CA 500 times a minute. By the end, you’ll have a calm workflow that scales without tripping the wires.

The Real Story Behind Let’s Encrypt Rate Limits

I like to think of Let’s Encrypt as a popular coffee shop. You can grab as many coffees as you want over time, but you can’t cut the line, and you can’t hog the barista with a hurricane of orders in a minute. Rate limits are those gentle “one at a time” rules that keep things fair. In practice, it means there are caps per registered domain, limits on duplicate certificates for the exact same set of hostnames, and some guardrails around failed authorizations and new orders within short windows. The exact numbers aren’t as important as the rhythm: you need to pace your requests, bundle smartly, and retry gracefully.

What does this feel like in the real world? Say you’re launching 30 microsites under example.com this week. If you request 30 separate certificates, each one unique and requested at the same time, you’ll get close to the weekly per-domain ceiling in one go. If your automation gets a little overzealous and retries on failures without backoff, you’ll add failed validations to the pile. And if you change your mind on SAN ordering and keep reissuing the exact same set, you’ll clip the duplicate cert limit too. You don’t need to memorize every number—just design as if you’re being polite to a busy neighbor. That mindset alone solves most rate-limit headaches.

If you want the official breakdown when planning a major rollout, the Let’s Encrypt rate-limits page is the canonical reference. I like to check it before large migrations or multi-tenant launches, then design the issuance and renewal pipeline accordingly.

SAN vs. Wildcard: The Strategy That Keeps You Under the Ceiling

Subject Alternative Name (SAN) certificates and wildcards are both great tools; the trick is using them at the right time. Let me paint a picture. A client once asked me to onboard a hundred partner subdomains in a single week. The initial instinct was to give each partner their own cert—nice and tidy. But the math said we’d nosedive into rate limits and spend the weekend babysitting retries. Instead, we issued a couple of well-structured SAN certificates, each covering a chunk of partners, and left headroom for late arrivals. The next iteration used a wildcard for the dynamic bits and SANs for the predictable, stable hostnames. Result: fewer certificates overall, fewer renewal events, and no alarms.

Think of a SAN certificate like a multi-stop transit ticket—it covers a list of hostnames in one go. It’s perfect when you have, say, app.example.com, api.example.com, and billing.example.com living stable lives. You issue once, renew on a cadence, and keep moving. Wildcards, on the other hand, are your “all subdomains welcome” pass. If your platform spawns customer-123.example.com every day, a wildcard like *.example.com is your sanity saver. The catch is that wildcards require DNS-01 validation, meaning you’ll need API access or a reliable process to publish TXT records quickly and accurately.

There are trade-offs. Large SAN certs become big to transport, and if you rotate them frequently, you’re shipping larger handshakes across every connection. Wildcards increase the blast radius if a key is ever compromised, because that one private key authenticates a whole universe of names. What’s worked well for me is splitting the world into domains of responsibility: a wildcard for ephemeral or user-generated subdomains, and smaller SAN certs for the backbone services that don’t change weekly. That balance keeps the certificate footprint small, renewals predictable, and rate limits far in the rearview mirror.

One pro tip: avoid turning SANs into junk drawers. If your automation reflexively adds new names to massive certs, you’ll end up reissuing busy certificates too often—and that churn compounds. Group names by lifecycle. Stable services together, fast-changing hostnames under a wildcard, and never mix the two without a good reason.

Understanding ACME Challenges Without the Headache

Let’s talk challenges. There are three common ways to prove control with ACME: HTTP-01, DNS-01, and TLS-ALPN-01. Each one is like a different entrance to the building; you pick the door that best fits your architecture and security posture. A lot of teams default to HTTP-01 because it’s familiar—you drop a token under /.well-known/acme-challenge/ and call it a day. But if you’re behind a CDN, using aggressive caching, or wrangling multiple load balancers, that little file can vanish, be cached incorrectly, or quietly 404 behind a proxy that didn’t pass the right path through.

DNS-01, meanwhile, is the ace up your sleeve. It’s the only way to get a wildcard, and it’s incredibly reliable if you can automate your DNS. The downside? DNS propagation can make or break your timelines. I once watched a team wait 20 minutes for an TXT record to show up globally because their provider had high TTLs and slow edge propagation. The fix was simple: swap to an API-friendly DNS provider, reduce TTL during issuance windows, and validate against authoritative nameservers before asking Let’s Encrypt to check. Since then, DNS-01 has been smooth, even for large batches.

TLS-ALPN-01 is a neat option when you can terminate TLS on port 443 and control ALPN handling. It keeps everything at the TLS layer, which can be super tidy in tightly controlled environments or on single hosts with direct control of the listener. It’s less common than HTTP-01 and DNS-01 in the wild, but it’s a fantastic fit when you want a clean network path and you know your edge inside out.

If you want a quick refresher straight from the source, the Let’s Encrypt challenge types guide breaks down the options clearly. Pair that with your architecture map and you’ll know instantly which door to use.

The Staging Safety Net: Test Like You Mean It

If I could give one piece of advice to my past self, it would be this: use the staging environment like it’s your best friend. The staging CA pretends to be Let’s Encrypt but won’t hand out trusted certs. That’s perfect for making as many requests as you want while you get your automation, order flow, and DNS propagation nailed down. The magic is that you rehearse all the corner cases in staging—bad DNS, wrong webroot, firewall snags—without touching production rate limits.

I’ve watched entire production clusters get rebuilt in staging first: dozens of concurrent orders, jittered retries, health checks toggling traffic, and then a switch to production once everything looks clean. The shocking part is how many small issues you catch before they become public, like a single backend not serving the challenge path or a DNS zone that refuses to update under certain conditions. You’ll never avoid every surprise, but staging takes most of the sting away.

Bookmark the Let’s Encrypt staging docs if you manage multi-tenant or high-churn domains. Anytime I’m planning a particularly wide issuance—like migrating a large SAN set or introducing a wildcard rollout—I do a full dry run in staging with production-like settings. It’s the difference between a calm deploy and a “why is Ops on this call?” kind of night.

Designing an Issuance and Renewal Pipeline That Doesn’t Trip Rate Limits

This is where the rubber meets the road. You don’t just get certificates; you design a workflow that respects limits while being boringly reliable. Here’s the broad play I use, refined after watching a few fires burn out:

First, group hostnames by behavior. Stable core services (like api, billing, sso) get one or two SAN certs. Ephemeral or user-generated hostnames go under a wildcard. If you have multiple high-velocity subdomains across departments, consider separate wildcards: one for preprod or review apps, one for customer subdomains, and one for internal tooling. That way, if a single certificate misbehaves, you don’t stampede a massive renewal or expose too much if a key needs rotation.

Second, automate DNS-01 challenges when you can. It pays for itself quickly. If you don’t have DNS APIs on your current provider, either add a provider that does or delegate _acme-challenge to a zone you control. That little DNS alias trick lets a centralized system create TXT records without having to own the entire authoritative zone file. For teams already doing infrastructure as code, weaving ACME TXT creation into your flows is natural. If you want a walkthrough on gluing DNS automation to a broader delivery pipeline, I shared my calm approach in how I automate DNS and zero‑downtime deploys with Terraform and Cloudflare. It’s not required for ACME, but it’s the same muscle.

Third, implement jitter. Don’t let thousands of instances renew at the exact same moment, 30 days before expiry. Spread them out. Randomized timers, a renewal window instead of a renewal day, and a central controller that refuses to issue more than N orders per minute is usually enough. You’ll avoid self-inflicted bursts, which are the most common reason teams accidentally meet the rate-limit bouncer.

Fourth, build gentle backoff on failures. If a validation fails, don’t brute force the CA. Check your DNS health, pull a fresh query from authoritative servers, verify the HTTP path is actually reachable, and only then retry—slowly. You’ll keep your own logs clean and avoid blowing through the failed validation limits. I always log the exact ACME authorization URL and response for postmortems—it’s gold when you’re diagnosing an odd edge cache or a sneaky redirect that swallowed the challenge token.

Finally, keep your issuance identity consistent. Use a stable ACME account key per project or environment, not a new account per host. That stability makes your audit trails cleaner, and it avoids touching broader per-account limits in a weird, fragmented way. Remember: new accounts are rate-limited too. If you’re building new accounts on every deploy, you’re asking for trouble.

Practical Pitfalls I See All the Time (And How to Dodge Them)

Let me save you some 2 a.m. messages. These are the patterns that sneak up on folks and how I sidestep them now:

CDNs and HTTP-01: A classic. You place the token at /.well-known/acme-challenge/, but your CDN either caches a 404, strips the path, or terminates TLS and forwards incorrectly. If you must use HTTP-01 behind a CDN, explicitly allow and bypass caching for the challenge path, verify with curl from multiple locations, and consider a temporary bypass rule during issuance. Or skip the drama and move to DNS-01 for that zone.

Slow DNS providers with DNS-01: Not all DNS APIs are equals. Some have slow propagation to the authoritative nameservers or require awkward delays before a TXT appears. In my experience, a quick sanity loop—create TXT, poll authoritative NS for presence, then finalize—solves nearly all flakiness. Lower TTLs during issuance windows help too, though TTL doesn’t control the authoritative presence; it just helps resolvers pick up changes faster after propagation completes.

Massive SAN certificates: Yes, they’re efficient on the rate-limit side, but make them too big and you’re pushing more bytes per handshake. That’s not a crisis, but on high-traffic sites you’ll feel it. I like to keep SANs tidy and split them by function. It also makes operational rotations simpler when a name is retired or a microservice changes ownership.

Wildcards and the blast radius: If a wildcard private key leaks, every subdomain covered by it is exposed. That’s why I rarely use one wildcard for everything under the sun. A wildcard for ephemeral users, another for internal tooling, and SANs for core customer-facing services strikes a nice balance. Encrypt the private keys at rest, limit access with strict permissions, and rotate on schedule. If you’re already using dual certificate types for compatibility, you’ll know this dance—renewals, reloads, and monitoring in a clean choreography.

Duplicate certificate limit traps: Reissuing the same exact set of SANs five times in a week will bite you. If you truly need to rotate rapidly (for a key compromise or config mistake), changing the SAN set even slightly avoids the duplicate set limit. Use that judiciously—don’t game the CA for no reason—but in an emergency, adding a temporary name can keep you moving while you clean up properly.

Validation path conflicts: Apps sometimes claim /.well-known/ for their own purposes, or a framework rewrites everything to a front controller that never serves the challenge. When in doubt, serve from a dedicated static folder with a higher priority location block, or use TLS-ALPN-01 or DNS-01 to bypass the app layer entirely.

Monitoring, Key Management, and Renewal Hygiene

Certificates aren’t fire-and-forget. The quiet wins come from a few habits that make renewals invisible and failures rare. I watch three things: expiration, issuance volume, and validation error patterns. For expiration, a simple alert at 21 days out and another at 7 days forces me to see if automation is keeping up. If it isn’t, I like to fix it early and then renew a test domain to prove the pipeline is really working, not just theoretically working.

Issuance volume is a great early warning for bad deploys. If you normally renew 5–10 certs a day and suddenly see 200, something changed—maybe a script now reissues on every container restart, or a SAN edit triggers frequent reorders. Quietly fixing that saves you from a rate-limit avalanche a week later.

On the key side, keep it simple and safe. Use strong keys, protect them at rest, and rotate on a reasonable cadence. If you serve both ECDSA and RSA for compatibility, make sure your web server prefers ECDSA where supported to keep handshakes fast. When you’re scheduling renewals, treat them like any other deploy: canary first, monitor, then roll out gradually. The fewer surprises in your certificate path, the less likely you’ll end up begging the CA for exceptions.

ACME at Scale: Concurrency Without Chaos

When you scale, even polite systems can get noisy. I’ve seen teams accidentally flood Let’s Encrypt with thousands of near-simultaneous orders from autoscaling pools. It wasn’t malicious—just a deploy that restarted everything at once. The antidotes are simple: a rate limiter at your orchestrator level, a shared “renewal coordinator” that owns the ACME flow, and a small queue with observable states. If an instance needs a cert, it asks the coordinator; the coordinator validates DNS or HTTP, finalizes the order, stores the key and cert safely, and then signals the instance to reload.

In clusters, that pattern avoids N instances each doing the same validation and hammering rate limits. It also centralizes error handling. If a TXT record fails to appear, you debug in one place. If there’s a CDN rule hiding the challenge token, you tweak it once. And if you want to switch challenge types (say, move from HTTP-01 to DNS-01), you do it in one controller, not across hundreds of nodes.

If you can’t centralize completely, consider a lease mechanism. Only one node can “own” issuance for a domain at a time; the rest back off. That alone eliminates a category of incidental spikes and makes your issuance stats line up nicely with expected behavior.

DNS Craftsmanship: Little Details, Big Stability

DNS can be the hero or the villain of your ACME story. A few habits changed my life here. First, validate TXT presence against authoritative nameservers, not just recursive resolvers. If the auth NS can’t see it yet, Let’s Encrypt can’t either. That one check eliminates guesswork around propagation. Second, batch updates thoughtfully. If your DNS provider serializes changes, firing 300 TXT records at once can stall; it’s better to push in small waves and poll for completion between them.

Third, use low TTL during issuance windows. You don’t need 1-minute TTLs forever, but during a migration or a big onboarding event, short TTLs on the _acme-challenge records and relevant hosts make life easier. And fourth, document your ACME-specific DNS policies. I’ve walked into teams where a security policy blocked TXT creation at the subdomain level by default—nobody realized until ACME tried to write.

One more trick: dedicate a subzone for challenges, like _acme-challenge.example.com delegated to acme.example.net, where you run dynamic automation. It’s tidy, secure, and lets you keep the primary zone clean. When you outgrow a DNS provider, this pattern makes the escape hatch simple; you just repoint the NS records for the subzone.

When to Refactor Your Certificate Layout

There’s a moment every platform reaches where the original certificate layout stops making sense. Maybe your SAN bundles grew too big, or your wildcard covers too many sensitive areas, or you started seeing renewal storms during peak traffic. My rule of thumb: if you’re touching the same certificate more than once a month, it’s too busy. Split it by function. Let the stable names sit quietly on a bi‑monthly renewal cadence while the noisy parts of your system use a wildcard with short, predictable rotations.

I also refactor when a team’s responsibilities change. If a new group owns a critical subdomain, I don’t want their deploys entangled with a dozen unrelated SAN names. Give them a neat certificate scoped to their world, with clear monitoring and alerting. It sounds like paperwork, but it’s operational freedom. And yes, every time I split a cert intentionally, I check how it affects rate limits over a week; the goal is to keep total issuance below the ceiling with a comfortable buffer.

A Quick Word on Security: Keys, Access, and Recovery

While we’re optimizing for rate limits, we can’t ignore security. Limit who can read private keys, log every certificate issuance event, and keep a secure backup of the most recent known‑good certificate and key for rollback. If you ever suspect a key compromise, having a defined emergency issuance path matters: switch to staging to validate the flow, then rotate in production with a minimal SAN set to avoid hitting duplicate limits. Once the world is stable, come back and do the tidy version.

For compatibility, many teams serve both ECDSA and RSA. ECDSA is lighter and faster on modern clients; RSA is the safety net for legacy endpoints. If you go this route, test your server configuration so that modern clients pick ECDSA preferentially. Pairing performance with good security hygiene makes your system feel effortless from the outside.

Putting It All Together: A Calm, Repeatable Checklist

Let me distill the pattern I end up using over and over:

Start in staging. Wire your ACME client, pick the right challenge (DNS-01 for wildcards or tricky edges; HTTP-01 or TLS-ALPN-01 if you control the path), and prove your pipeline works under stress. Group names by lifecycle. SANs for durable hostnames, wildcards for fast‑moving or user‑generated subdomains, and never let one certificate become a single point of periodic chaos. Add jitter and a coordinator to avoid concurrency storms. Validate DNS against authoritative NS, not just your local resolver.

When renewing, aim for early and quiet. If a renewal fails, pause, diagnose, and retry with backoff; don’t power through and trigger the CA’s defenses. Keep an eye on issuance volume and error types; both are early warnings for a subtle bug. And once everything hums, don’t forget to document the calm path so the next engineer doesn’t reinvent the fire drill.

Wrap‑Up: The Friendly Path Past the Limits

I’ll be honest: the first time I ran into Let’s Encrypt rate limits, I felt like I’d tripped a secret laser grid. In reality, it was my automation asking for too much, too fast, without a plan. Since then, moving to a SAN‑plus‑wildcard strategy, embracing DNS‑01 where it makes sense, and rehearsing in staging changed everything. Now renewals feel like weather—always happening in the background, rarely worth a conversation.

If you’re standing at the starting line, here’s your nudge: map your domains by behavior, pick a sensible challenge per zone, and add just enough coordination that you never feel compelled to panic‑retry. When in doubt, read the official docs for rate limits and challenge types, and do a full staging rehearsal of any big certificate change. With a little forethought, you can keep certificates fresh without ever seeing the rate-limit wall again. Hope this helped! And if you want to go deeper on the surrounding tooling, my walkthrough on DNS automation and zero‑downtime deploys is a lovely companion to everything we covered here. See you in the next post.