Let’s Encrypt Rate-Limits: Warum SaaS-Subdomains ein Wildcard-Zertifikat brauchen
Fünfzig Zertifikate pro Domain und Woche klingen nach viel. Bis der fünfzigste Kunde im Onboarding hängen bleibt und das Zertifikat erst nächste Woche kommt.
Let’s Encrypt ist der Grund, warum TLS heute selbstverständlich ist. Kostenlos, automatisiert, überall unterstützt. Für SaaS-Anbieter mit einer Subdomain pro Kunde hat es aber eine Eigenschaft, die man erst bemerkt, wenn es zu spät ist: Rate-Limits pro registrierter Domain.
Das Limit
Let’s Encrypt erlaubt eine begrenzte Zahl neuer Zertifikate pro registrierter Domain und Woche. kunde1.example.com, kunde2.example.com und kunde3.example.com zählen alle auf example.com. Die genaue Zahl steht in der Dokumentation von Let’s Encrypt und hat sich über die Jahre geändert; die Größenordnung liegt bei einigen Dutzend pro Woche. Dazu kommen Limits für fehlgeschlagene Validierungen, die bei einem falsch konfigurierten Ingress schnell erreicht sind.
Für eine Firmenwebsite mit fünf Hosts ist das irrelevant. Für eine SaaS, die pro Kunde eine Subdomain anlegt, ist es ein Wachstumsdeckel: Der Kunde, der das Limit überschreitet, bekommt kein Zertifikat, sein Onboarding wartet, und der Fehler sieht aus wie ein Bug im Cluster.
Warum HTTP-01 pro Host das Problem ist
Der übliche Weg mit cert-manager ist HTTP-01: cert-manager legt pro Host eine Challenge unter /.well-known/acme-challenge/ ab, Let’s Encrypt ruft sie ab, das Zertifikat kommt. Ein Zertifikat pro Host, jedes zählt auf das Limit. Bei zehn neuen Kunden am Tag ist die Woche nach fünf Tagen vorbei.
Es gibt drei Auswege, und nur einer skaliert.
Ausweg 1: Zertifikate bündeln
Mehrere Hosts in einem Zertifikat, als Subject Alternative Names. Spart Zertifikate, aber jede Änderung der Liste ist eine Neuausstellung, die wieder zählt. Bei täglich neuen Kunden bringt das wenig.
Ausweg 2: Eine eigene Domain pro Kunde
app.kunde.de statt kunde.example.com. Jeder Kunde hat seine eigene registrierte Domain, das Limit greift pro Kunde. Funktioniert, verlagert aber Arbeit zum Kunden: Er muss einen Record setzen und warten, bis DNS propagiert. Für Enterprise-Kunden richtig, für Self-Service zu viel Reibung.
Ausweg 3: Ein Wildcard-Zertifikat
*.example.com deckt alle Subdomains mit einer einzigen Ausstellung ab. Kunde 1 bis Kunde 10.000 teilen sich ein Zertifikat, das alle 90 Tage einmal erneuert wird. Kein Limit, kein Warten im Onboarding.
Der Haken: Wildcards gibt es nur per DNS-01. Let’s Encrypt prüft nicht einen Pfad auf dem Server, sondern einen TXT-Record in der Zone. cert-manager braucht dafür ein Token des DNS-Anbieters, und das Zertifikat landet als Secret in genau einer Namespace. Für Namespace pro Kunde braucht es deshalb noch einen Schritt: Das Secret muss in jede Kunden-Namespace gespiegelt werden, etwa mit dem Reflector.
So sieht das Setup aus
- DNS-Zone bei einem Anbieter mit API, etwa Cloudflare, und ein API-Token, das auf diese Zone beschränkt ist und nur die von cert-manager empfohlenen Rechte „Zone – DNS – Edit“ und „Zone – Zone – Read“ hat.
- Ein ClusterIssuer mit DNS-01-Solver, der das Token als Secret referenziert.
- Ein Certificate fü
*.example.comundexample.com, dessen Secret-Template die Reflector-Annotationen träg - Ingress oder Gateway pro Kunde, der auf das gespiegelte Secret zeigt statt auf ein eigenes.
Vier Objekte, die man einmal richtig schreiben muss. Clusterward macht daraus einen Eintrag in der Zertifikatsregistry: Basis-Domain, Token, fertig. Das Zertifikat wird im selben Schritt ausgestellt, in jede Namespace gespiegelt und täglich überwacht, siehe DNS und Zertifikate.
Was bleibt bei HTTP-01
Für alles, was keine Kundensubdomain ist: die Marketing-Website, die Admin-Oberfläche, die API unter einem festen Host. Hier ist ein Zertifikat pro Host richtig, weil sich die Liste nie ändert. Ein Service kann beides mischen: Wildcard für *.kunden.example.com, Let’s Encrypt pro Host für api.example.com.
Und hinter Cloudflare?
Wer Hosts über den Cloudflare-Proxy leitet, braucht am Origin gar kein öffentliches Zertifikat: TLS endet an der Edge. Dann ist der richtige Modus, kein eigenes Zertifikat auszustellen, sonst zählt jeder Kunde wieder auf das Limit, ohne dass jemand das Zertifikat je sieht.
Das Rate-Limit ist kein Fehler von Let’s Encrypt. Es ist der Hinweis, dass ein Zertifikat pro Kunde das falsche Modell ist.
Wie man das Limit erkennt, bevor es zuschlägt
Das Limit meldet sich nicht im Voraus. Es meldet sich, wenn die Ausstellung fehlschlägt, und dann steht im Ereignis des Certificate-Objekts von cert-manager ein Hinweis auf too many certificates already issued. Drei Signale, die früher kommen:
- Die Zahl der Certificate-Objekte in einer Basis-Domain wächst mit jedem Kunden. Wer sie zählt, sieht, wann die Woche eng wird.
- Fehlgeschlagene Validierungen häufen sich, meist weil ein Host schon angelegt wurde, bevor DNS zeigte. Sie zählen auf ein eigenes Limit.
- Onboardings dauern länger, weil die Zertifikatsausstellung in die Warteschlange gerät.
Ein täglicher Blick auf die Certificate-Objekte oder ein Wächter, der Zertifikate ohne Ready-Status meldet, reicht, um das rechtzeitig zu sehen.
Die Staging-Umgebung von Let’s Encrypt
Beim Aufbau eines neuen Setups sollte der Issuer zuerst auf die Staging-Umgebung von Let’s Encrypt zeigen. Sie stellt Zertifikate aus, denen kein Browser vertraut, aber mit sehr hohen Limits. Wer den Ablauf dort einmal durchspielt, bis Wildcard, Reflector und Ingress zusammenpassen, verbraucht das Produktionslimit nicht mit Fehlversuchen. Der Wechsel auf die Produktionsumgebung ist danach eine Zeile im Issuer.
Was mit dem Apex passiert
*.example.com deckt kunde.example.com ab, aber nicht example.com selbst und nicht www.kunde.example.com. Ein Wildcard gilt für genau eine Ebene. Das Certificate braucht deshalb beide Namen, *.example.com und example.com, und wer Subdomains zweiter Ebene vergibt, braucht ein zweites Wildcard für *.kunde.example.com oder ein anderes Namensschema. Am einfachsten: eine Ebene, keine Ausnahmen.
Fazit
Wer Subdomains pro Kunde plant, plant ein Wildcard-Zertifikat mit. Das ist eine Stunde Arbeit am Anfang und erspart die Woche, in der das Onboarding stillsteht, weil Let’s Encrypt bis Montag wartet.
Zertifikate für viele Subdomains planen? Schreiben Sie uns, wie Ihre Kunden-Domains aussehen. Wir zeigen, wie Wildcard-Zertifikat und Onboarding zusammenspielen. Frage zu Zertifikaten stellen →
Quellen und weiterführende Links
Häufige Fragen
- Let’s Encrypt begrenzt neue Zertifikate pro registrierter Domain und Woche; die Größenordnung liegt bei einigen Dutzend, die genaue Zahl steht in der Dokumentation. Alle Subdomains wie kunde1.example.com zählen auf example.com. Dazu kommen eigene Limits für fehlgeschlagene Validierungen.