Da ich nun von NPM auf Zoraxy gewechselt bin, will ich natürlich auch eine Wildcard über DNS-Challenge machen.
Ich bekomme immer diesen Fehler.
Acme: Fehler: 429 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:rateLimited :: zu viele Zertifikate (50) wurden in den letzten 168h0m0s bereits für "nas64.de" ausgestellt, erneuter Versuch nach dem 17.08.2025 13:34:01 UTC: siehe https://letsencrypt.org/docs/rate-limits/#new-certificates-per-registered-domain
Scheint eher ein generelles Problem zu sein. Ausgerechnet an dem Tag, wo ich hier hin umsteigen wollte. Denn ich habe über Traefik auch Probleme. Mal bekomme ich ein Fehler „unknown certificate authority“, mal ein 403 und 504. Aber acme_challenges tauchen im CDN trotzdem auf, aber halt keine Zertifikate in der acme.json.
Du willst ein von let’s encrypt signiertes Zertifikat und läufst in ein rate limit.
→ Man könnte jetzt nach rate limits von Let’s Encrypt suchen. Zum Beispiel direkt auf deren Website.
Hier ist die Lösung: Rate Limits - Let's Encrypt - Freie SSL/TLS Zertifikate
In der Meldung steht, dass ein rate limit von 50 für eine Domain überschritten wurde.
Man könnte jetzt die Suche eingrenzen, indem man einfach mal nach “50” auf der Seite sucht:
Ich habe die DNS-Challange (*.???.nas64.de) die Tage immer mal wieder getestet. Leider immer noch das gleiche Problem. Hast du schon was herausgefunden bei Let’s Encrypt und der Domain *.*nas64.de?
ich habe das gleiche Problem. Aus lokaler Verbundenheit (Grüße aus Essen) würde ich gerne deinen Dyndns-Service benutzen, Dennis. Hab mir eine Subdomain für nas64.de erstellt und bekomme bei Letsencrypt den gleichen Fehler wie der TE.
Wird das gelöst werden, sodass sich warten lohnt?
Besteht bei anderen deiner Domains das gleiche Problem?
Letsencrypt betrachtet (first level) Domains und alle Anfragen, die unter einer first level Domain gestellt werden.
Im Fall von nas64.de werden also sämtliche Anfragen in einen Topf für nas64.de geworfen. lustige-katzenbilder.nas64.de, dennis-soll-mehr-arbeiten.nas64.de, mein-toller-homeserver.nas64.de, ….. landen alle im gleichen Topf, in dem auch die Zertifikats-Anfrage für deine Subdomain gelandet ist.
LE sieht pro first level Domain (z.B. nas64.de) Rate Limits vor.
Dazu wird z.B. in den Topf für nas64.de geschaut.
Wenn also ausreichend viele Kunden Subdomains verwenden und Zertifikate m.H.v. LE generieren, dann wird das rate limit erreicht.
Das ist aber nicht nur bei IPv64.net als DynDNS Dienst und der Domain nas64.de so, sondern betrifft grundsätzlich jeden DynDNS Dienst und jede Domain. Je größer und bekannter der Dienst und je mehr Mitglieder eine Domain nutzen, desto höher die Wahrscheinlichkeit, dass die Rate Limits erreicht werden.
LE kann, auf Antrag, die Rate Limits anheben. Mehr als freundlich fragen, kann Dennis allerdings nicht machen.
Wenn man kurz darüber nachdenkt sollten sich die Fragen: “Besteht bei anderen deiner Domains das gleiche Problem?” und “Wird das gelöst werden, sodass sich warten lohnt?“ von selbst beantworten.
Ich hatte mir die Logsfiles als auch die darin enthaltenen Links auf die Supportseiten von Letsencrypt angeschaut. Dennoch danke für deine technischen Ausführungen.
Wenn man sich kurz die Beiträge 6 und 8 anschaut, sollte es sich von selbst beantworten, warum die Frage “Wird das gelöst werden, sodass sich warten lohnt?“ Sinn ergibt.
Um es klarer zu formulieren. Anscheinend waren Anstrengungen unternommen worden, um diese (und vielleicht weitere) Domains bei Letsencrypt auf eine Liste setzen zu lassen, mutmaßlich, um das Limit zu erhöhen/umgehen. Ich nehme an, dass das Erfolg hatte. Und nun scheint es nicht mehr zu gehen. Also liegt es doch nahe, nachzufragen, ob der vorherige Status wieder hergestellt werden kann, oder ob es fortan quasi unmöglich ist, ein Letsencrypt für eine der IPv64-Domains der erstellen.
Ob das Problem bei anderen Domains bzw. sogar anderen Anbietern besteht, haben wir ja geklärt: Grundsätzlich ja, weil das Problem inherent mit den Rate Limits von LetsEncrypt zusammen hängt. Im Einzelfall kommt es aber auch darauf an, wie viele Nutzer pro Domain Zertifikate über LE beziehen (wollen) und ob die Anbieter mit ihren Domains bei LE auf einer Whitelist sind oder nicht.
Ob das Problem gelöst werden kann, ist auch beantwortet: Generell ja, wenn LE die Domain whitelisted. Das hat Dennis, soweit ich seine Aussage verstehe, bereits angefragt.
Wenn niemand die Möglichkeit hat, die Whitelist bei LE einzusehen und Dennis noch keine Rückmeldung hat, dann kann dir aber niemand die Frage beantworten, ob überhaupt bzw. wann der Antrag von LE angenommen wird. Ich würde fast annehmen, dass Dennis es uns wissen lässt, sobald er mehr Informationen hat.
In der Zwischenzeit hast du aber ganz offensichtlich festgestellt, dass bisher noch kein erneutes Whitelisting stattgefunden hat.
Vereinfacht gesagt, deine Frage erinnert an den Esel aus Shrek:
Ob sich das Warte für dich persönlich lohnt, kann dir niemand von uns sagen.
Ich z.B. will, dass meine IT läuft. Selbst in meinem Homelab ist alles von Anfang bis Ende automatisiert. Die 6€ im Jahr für eine eigene Domain und der Scripting-Aufwand, den ich betrieben habe, alles bei mir zu automatisieren, sind es mir wert, um nicht von irgendwelchen Dritten abhängig zu sein. - Würde allerdings jeder so denken, gäbe es u.A. keine DynDNS Anbieter mehr. Die Existenz der Anbieter und der Erfolg, den Dennis DynDNS Dienst hat, zeigen aber, dass bei weitem nicht jeder so denkt.
Wie unnötig bis frech, dass deine inhaltlich wertvollen Beiträge persönliche und überzogene Spitzen enthalten.
Die Frage, ob sich das warten lohnt, übersetze ich dir aber gerne: “Ist nach gut 6 Wochen (seit der Info, dass dem nachgegangen wird) ein Fortschritt erkennbar, der eine Vermutung zulässt, ob das Problem gelöst werden wird?”
Wie dem auch. Ich werde mir eine eigene Domain registrieren.
Und noch für alle anderen, z. B. @JeromeB: Mir ist es nun gelungen, ein Letsencrypt-Zertifikat für “nas64.de” zu erstellen. Ich habe exakt zu dem in der Fehlermeldung genannten Zeitpunkt den Request abgesendet (Achtung, die Angabe ist in UTC).
