So sieht die Meldung aus
Type: unauthorized Detail: 2001:db8::10: Invalid response from http://beispiel.de/.well-known/acme-challenge/kX3v9...: 404Häufige Ursachen
- Ein AAAA-Record zeigt auf eine IPv6-Adresse, auf der kein oder ein anderer vHost antwortet – Let's Encrypt bevorzugt IPv6.
- DNS zeigt noch auf den alten Server (Migration, hohe TTL).
- Rewrite- oder Redirect-Regeln (Nextcloud, WordPress, erzwungenes HTTPS auf fremdem Host) fangen den Pfad ab.
- Falscher
--webroot-Pfad, die Datei landet nicht dort, wo nginx sie ausliefert. - CDN, Proxy oder Firewall blockiert Port 80.
Prüfen
- A- und AAAA-Records prüfen
dig +short A beispiel.de; dig +short AAAA beispiel.de - Challenge-Pfad gezielt über IPv6 testen
curl -6 -sI http://beispiel.de/.well-known/acme-challenge/test - Lauscht nginx auf IPv6, Port 80?
nginx -T 2>/dev/null | grep -E 'listen .*\[::\]:80' - Ausstellung testen, ohne Rate-Limits zu belasten
certbot certonly --dry-run --webroot -w /var/www/letsencrypt -d beispiel.de
Lösung
- Im HTTP-vHost
listen [::]:80;ergänzen oder einen falschen AAAA-Record löschen. - Challenge-Pfad vor allen Redirects ausliefern:
location ^~ /.well-known/acme-challenge/ { root /var/www/letsencrypt; }. - Vor einer Migration die TTL senken und erst nach der Umstellung das Zertifikat anfordern.
- Ist Port 80 nicht erreichbar, auf DNS-01-Challenge umstellen (z. B. per DNS-Plugin von certbot).
Häufige Fragen
Warum klappt es im Browser, aber nicht für Let's Encrypt?
Ihr Browser nutzt evtl. IPv4 oder einen Cache. Let's Encrypt fragt über IPv6, sobald ein AAAA-Record existiert, und prüft von mehreren Standorten aus.
Wie viele Fehlversuche sind erlaubt?
Let's Encrypt erlaubt 5 fehlgeschlagene Validierungen pro Konto, Hostname und Stunde. Testen Sie deshalb mit --dry-run gegen die Staging-Umgebung.