Let’s Encrypt rate limits: why SaaS subdomains need a wildcard certificate

Let’s Encrypt is the reason TLS is a given today. Free, automated, supported everywhere. For SaaS vendors with one subdomain per customer, though, it has a property you only notice when it is too late: rate limits per registered domain.

The limit

Let’s Encrypt allows a limited number of new certificates per registered domain per week. kunde1.example.com, kunde2.example.com and kunde3.example.com all count against example.com. The exact number is in the Let’s Encrypt documentation and has changed over the years; the order of magnitude is a few dozen per week. On top of that come limits for failed validations, which a misconfigured ingress reaches quickly.

For a company website with five hosts, this is irrelevant. For a SaaS that creates one subdomain per customer, it is a ceiling on growth: the customer who crosses the limit gets no certificate, their onboarding stalls, and the error looks like a bug in the cluster.

Why HTTP-01 per host is the problem

The usual route with cert-manager is HTTP-01: cert-manager places a challenge under /.well-known/acme-challenge/ for each host, Let’s Encrypt fetches it, and the certificate arrives. One certificate per host, and each one counts against the limit. With ten new customers a day, the week is used up after five days.

There are three ways out, and only one of them scales.

Way out 1: Bundle certificates

Several hosts in one certificate, as Subject Alternative Names. This saves certificates, but every change to the list is a reissue that counts again. With new customers every day, it does not get you far.

Way out 2: A separate domain per customer

app.kunde.de instead of kunde.example.com. Every customer has their own registered domain, so the limit applies per customer. It works, but it shifts work to the customer: they have to set a record and wait for DNS to propagate. Right for enterprise customers, too much friction for self-service.

Way out 3: A wildcard certificate

*.example.com covers every subdomain with a single issuance. Customer 1 through customer 10,000 share one certificate that is renewed once every 90 days. No limit, no waiting during onboarding.

The catch: wildcards are only available via DNS-01. Instead of checking a path on the server, Let’s Encrypt checks a TXT record in the zone. For that, cert-manager needs a token from the DNS provider, and the certificate ends up as a Secret in exactly one namespace. With a namespace per customer, one more step is needed: the Secret has to be mirrored into every customer namespace, for example with Reflector.

What the setup looks like

1. A DNS zone with a provider that has an API, such as Cloudflare, and an API token scoped to that zone with only the permissions cert-manager recommends: “Zone – DNS – Edit” and “Zone – Zone – Read”.
2. A ClusterIssuer with a DNS-01 solver that references the token as a Secret.
3. A Certificate for *.example.com and example.com, whose Secret template carries the Reflector annotations
4. An Ingress or Gateway per customer that points to the mirrored Secret instead of one of its own.

Four objects you have to get right once. Clusterward turns them into a single entry in the certificate registry: base domain, token, done. The certificate is issued in the same step, mirrored into every namespace and monitored daily; see DNS & certificates.

Where HTTP-01 still fits

For everything that is not a customer subdomain: the marketing website, the admin interface, the API under a fixed host. Here, one certificate per host is right, because the list never changes. A service can mix both: a wildcard for *.kunden.example.com, Let’s Encrypt per host for api.example.com.

And behind Cloudflare?

If you route hosts through the Cloudflare proxy, you need no public certificate at the origin at all: TLS terminates at the edge. In that case, the right mode is to issue no certificate of your own – otherwise every customer counts against the limit again, without anyone ever seeing the certificate.

The rate limit is not a flaw in Let’s Encrypt. It is a sign that one certificate per customer is the wrong model.

How to spot the limit before it hits

The limit gives no advance warning. It shows up when issuance fails, and then the event on cert-manager’s Certificate object points to too many certificates already issued. Three signals that come earlier:

• The number of Certificate objects under a base domain grows with every customer. If you count them, you see when the week is getting tight.
• Failed validations pile up, usually because a host was created before DNS pointed to it. They count against a separate limit.
• Onboardings take longer because certificate issuance ends up in a queue.

A daily look at the Certificate objects, or a watcher that reports certificates without Ready status, is enough to see this coming in time.

The Let’s Encrypt staging environment

When building a new setup, point the issuer at the Let’s Encrypt staging environment first. It issues certificates that no browser trusts, but with very high limits. If you run through the process there once, until wildcard, Reflector and ingress fit together, you do not burn the production limit on failed attempts. Switching to the production environment afterwards is one line in the issuer.

What happens to the apex

*.example.com covers kunde.example.com, but not example.com itself and not www.kunde.example.com. A wildcard applies to exactly one level. The Certificate therefore needs both names, *.example.com and example.com, and if you hand out second-level subdomains, you need a second wildcard for *.kunde.example.com or a different naming scheme. Simplest option: one level, no exceptions. Clusterward issues managed wildcards exactly that way, with both names, so the bare domain can use the wildcard certificate too.

Conclusion

If you plan subdomains per customer, plan a wildcard certificate along with them. It is an hour of work at the start and saves you the week in which onboarding stands still because Let’s Encrypt makes you wait until Monday.

Planning certificates for many subdomains? Tell us what your customer domains look like. We will show you how the wildcard certificate and onboarding work together. Ask a question about certificates →

Sources and further reading

• Let’s Encrypt: Rate limits
• Let’s Encrypt: Challenge types
• Let’s Encrypt: Staging environment
• cert-manager: DNS01 with Cloudflare