Let’s-Encrypt-Fehlersuche — warum certbot scheitert

Ein Online-Werkzeug zur Diagnose gescheiterter Let's-Encrypt- und ACME-Ausstellungen. Certbot meldet fast jedes Problem als dasselbe „authorization failed“ und verbirgt damit, ob die Ursache DNS ist, ein geschlossener Port, eine Umleitung, die den Challenge-Pfad verschluckt, oder ein CAA-Eintrag, der die Stelle ausschließt. Hier werden alle drei Voraussetzungen von außerhalb Ihres Netzes geprüft — so wie es die Zertifizierungsstelle tun wird — und die konkrete Ursache benannt.

So geht es

1
Genauen Namen eingeben

Den Namen, den Sie certbot mit -d übergeben. Scheitert die Ausstellung für www.example.com, prüfen Sie diesen und nicht die nackte Domain — sie können sich unterschiedlich verhalten.

2
Challenge-Typ wählen

HTTP-01, sofern Sie keinen Platzhalter brauchen und Port 80 offen ist, sonst DNS-01.

3
Zuerst die Fehler lesen

Probleme stehen vor den Beobachtungen, das Schwerwiegendste zuerst. Alles als Fehler Markierte ist ein Grund, warum die Ausstellung jetzt scheitert.

4
Beheben, dann erneut prüfen

Ergebnisse werden nur kurz zwischengespeichert, ein erneuter Lauf nach einer Änderung zeigt also den neuen Zustand statt des alten.

Prüfen Sie die drei Dinge, auf die eine Zertifizierungsstelle schaut, bevor Sie certbot erneut starten

Geben Sie genau den Namen an, der hinter -d steht. Scheitert certbot an www.example.com, prüfen Sie www.example.com, nicht example.com.
Die CA holt eine Datei über einfaches HTTP von Ihrem Webserver. Das nutzt certbot standardmäßig.

Was geprüft wird

Ob der Name auflöst und wohin
A- und AAAA-Einträge, mit einer Warnung für den Nur-IPv6-Fall: Let's Encrypt bevorzugt IPv6 und fällt nie auf IPv4 zurück — ein Server, der auf IPv6 nicht wirklich lauscht, scheitert also an der Validierung, während die Seite für die meisten Besucher gesund aussieht.
Ob der Challenge-Pfad erreichbar ist
Ruft /.well-known/acme-challenge/ von außen über einfaches HTTP ab. Ein 404 ist die richtige Antwort — er beweist, dass die Anfrage Ihren Webserver erreicht hat. Eine abgelehnte Verbindung, ein 403 aus einer Punkt-Verzeichnis-Regel oder eine pauschale Umleitung auf die Startseite sind die echten Fehler und werden einzeln gemeldet.
Ob CAA die Stelle zulässt
CAA-Einträge werden am Namen und an jeder übergeordneten Ebene geprüft, denn ein Eintrag auf example.com gilt auch für www.example.com. Ein CAA-Eintrag mit einer anderen CA ist eine der zeitraubendsten Ursachen, weil die ACME-Fehlermeldung das nicht klar sagt.
Umleitungen werden untersucht, nicht nur befolgt
Eine Umleitung von HTTP auf HTTPS ist unproblematisch und bricht die Validierung nie — das ist wissenswert, weil sie häufig zu Unrecht verdächtigt wird. Eine Umleitung, die woanders als auf dem Challenge-Pfad endet, ist es nicht; das Werkzeug unterscheidet beides.
Der Befehl für den nächsten Schritt
Ein certbot-Aufruf passend zum gewählten Challenge-Typ, mit den Optionen, die zum Befund passen.

Häufige Fragen

Meine Seite läuft nur über HTTPS. Warum spielt Port 80 eine Rolle?

Weil die HTTP-01-Challenge immer auf Port 80 beginnt. Die Zertifizierungsstelle verbindet sich zuerst dorthin, unabhängig davon, was Ihre Seite danach tut, und eine Firewall, die Port 80 verwirft, macht die Challenge unmöglich. Eine Umleitung von Port 80 auf HTTPS ist unproblematisch — die CA folgt ihr und prüft dabei kein Zertifikat. Den Port zu schließen ist es nicht. Geht das Öffnen wirklich nicht, ist DNS-01 die Alternative.

Das Werkzeug meldet 404 und nennt es gut. Stimmt das?

Ja. Vor der Ausstellung gibt es keine Challenge-Datei, ein 404 ist also genau das, was ein richtig konfigurierter Server zurückgeben muss. Entscheidend ist, dass die Anfrage Ihren Webserver überhaupt erreicht hat. Während der Validierung legt certbot dort das echte Token ab und die CA findet es. Eine gescheiterte Verbindung oder ein 403 heißen, dass die Anfrage nie ankam — und das ist das eigentliche Problem.

Was ist ein CAA-Eintrag und warum hätte ich einen?

Ein DNS-Eintrag, der festlegt, welche Zertifizierungsstellen für Ihre Domain ausstellen dürfen. Die Stellen müssen ihn prüfen und ablehnen, wenn sie nicht aufgeführt sind. Solche Einträge stammen aus dem Einrichtungsassistenten eines früheren Anbieters, aus einem Hosting-Panel oder werden von einer übergeordneten Domain geerbt — ein Eintrag auf example.com gilt auch für www.example.com, weshalb „ich habe nie einen angelegt“ so oft falsch ist.

Ich bin an ein Limit gestoßen. Hilft das hier?

Indirekt, und genau darum geht es. Let's Encrypt begrenzt, wie viele Zertifikate pro Domain und Woche angefordert werden können, und aufgebraucht wird dieses Kontingent durch wiederholte Fehlversuche. Die Voraussetzungen vor dem nächsten certbot-Lauf zu prüfen, verhindert, dass das Kontingent für Versuche draufgeht, die ohnehin scheitern mussten.

Stellt das ein Zertifikat aus?

Nein, und das wird sich nicht ändern. Es führt keine ACME-Vorgänge aus, hält keinen Schlüssel und spricht mit keiner Zertifizierungsstelle — es beobachtet Ihre Domain nur von außen. Die Ausstellung gehört auf Ihren Server, wo der private Schlüssel liegt und die Erneuerung automatisch laufen kann; das kann eine Webseite nicht leisten.

Das könnte Ihnen auch gefallen

📝 CSR-Generator 🏷️ Generator für selbstsignierte Zertifikate 🔐 SSL-Checker 📜 SSL-Zertifikat-Decoder 🔗 Schlüssel-Zertifikat-Abgleich 🔄 Zertifikatsformat-Konverter ⛓️ Zertifikatsketten-Reparatur

Wie bewerten Sie dieses Tool?

Danke für Ihre Bewertung!
Möchten Sie mehr sagen? Hinterlassen Sie einen Kommentar!
Danke! Ihr Kommentar erscheint nach der Moderation.
Für wen ist dieses Tool gedacht?
💻 Entwicklerinnen & IT-Profis 🔒 Sicherheit & Privatsphäre
Veröffentlicht Aktualisiert Autor: