Warum wird ein selbst gehostetes Zertifikat lokal erneuert, schlägt aber aus dem Internet fehl?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Why Does a Self-Hosted Certificate Renew Locally but Fail From the Internet?

Ein Zertifikat kann lokal erneuert werden und dennoch öffentlich fehlschlagen, wenn die ACME-Zertifizierungsstelle die Challenge über den aus dem Internet erreichbaren Pfad nicht erreichen oder überprüfen kann.

Auf einem selbst gehosteten NAS oder Heimserver kann ein lokaler Testlauf bestätigen, dass Certbot, acme.sh oder der Reverse-Proxy Challenge-Dateien erstellen und auf die eigene Konfiguration zugreifen kann. Die öffentliche Ausstellung stellt jedoch andere Anforderungen: Der autoritative DNS muss auf die richtige Adresse verweisen, der ausgewählte IPv4- oder IPv6-Pfad muss erreichbar sein, der Router und die Firewall müssen die Validierungsanfrage weiterleiten, und der Reverse-Proxy muss das exakte Challenge-Token ausliefern, bevor Weiterleitungen oder Anwendungsrouten dazwischenfunken.

Lokalen Erfolg des Clients von der öffentlichen Domain-Validierung trennen

Lesen Sie das Erneuerungsprotokoll und ermitteln Sie, was tatsächlich erfolgreich war. Eine lokale Konfigurationsprüfung, ein Zertifikatsparser-Test, das Schreiben in das Webroot oder eine Staging-Anfrage beweisen nicht, dass eine externe Zertifizierungsstelle den Heimserver erreicht hat.

Ein häufiger Fall im Nginx Proxy Manager weist bei einer trotz funktionierender lokaler Proxy-Oberfläche fehlschlagenden HTTP-Challenge auf die Erreichbarkeit des öffentlichen Ports 80 als erste zu überprüfende Voraussetzung hin.

Notieren Sie den Challenge-Typ, den Hostnamen, die Validierungs-URL, die aufgelöste Adresse und den genauen Fehler der Zertifizierungsstelle. Fahren Sie erst ab dem ersten externen Fehler fort – DNS-Abfrage, TCP-Verbindung, HTTP-Status, Token-Abweichung oder sekundäre Validierung –, statt die Erneuerung wiederholt zu erzwingen, ohne neue Erkenntnisse zu gewinnen.

Autoritative A- und AAAA-Einträge mit dem tatsächlichen Serverpfad vergleichen

Fragen Sie jeden Hostnamen des Zertifikats über den autoritativen DNS ab und protokollieren Sie die A- und AAAA-Antworten. Vergleichen Sie sie mit der aktuellen öffentlichen IPv4-Adresse des Routers, der erreichbaren IPv6-Adresse des Servers und dem Proxy, der die Challenge tatsächlich ausliefert.

In einem Virtualmin-Fall war die Erneuerung erst erfolgreich, nachdem ein veröffentlichter AAAA-Eintrag entfernt worden war, der die Validierung auf einen fehlerhaften IPv6-Pfad leitete. Dies zeigt, wie ein fehlerhafter AAAA-Validierungspfad eine ansonsten funktionierende IPv4-Konfiguration außer Kraft setzen kann.

Wenn eine Adressfamilie nicht vollständig erreichbar ist, entfernen Sie den entsprechenden Eintrag vorübergehend oder reparieren Sie Firewall, Routing, Listener und Proxy-Pfad. Prüfen Sie außerdem, ob alle autoritativen Nameserver vor einem erneuten Versuch der Ausstellung dieselben aktuellen Einträge zurückgeben.

Die exakte HTTP-Challenge-URL von außerhalb des Heimnetzes testen

Legen Sie für HTTP-01 eine harmlose Testdatei unter dem konfigurierten Pfad /.well-known/acme-challenge/ ab und rufen Sie sie über den Zertifikatshostnamen per HTTP aus dem Mobilfunknetz oder einem anderen externen Netzwerk ab.

Ein Bericht zum Selbsthosting von Home Assistant zeigt, wie eine durch den ISP blockierte HTTP-Challenge die HTTP-Validierung verhindert, selbst wenn der Dienst lokal funktioniert.

Die externe Anfrage muss das richtige Token ohne Authentifizierung, Captive-Portal-Seite, Router-Anmeldeseite, 404-Fehler der Anwendung oder Weiterleitung zu einem nicht erreichbaren Ziel erreichen. Wenn TCP-Port 80 nie geöffnet wird, prüfen Sie ISP, CGNAT, Router-Weiterleitung, Host-Firewall und Proxy-Listener, bevor Sie den ACME-Client ändern.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Sicherstellen, dass Reverse-Proxy und Webroot dasselbe Token ausliefern

Vergleichen Sie den vom ACME-Client geschriebenen Token-Pfad mit dem Dateisystem oder dem temporären Responder, den der öffentliche virtuelle Host verwendet. Container, Bind-Mounts und getrennte Proxy-Netzwerke können dazu führen, dass der Client in ein Verzeichnis schreibt, während NGINX oder Caddy ein anderes ausliefert.

Prüfen Sie während einer einzelnen externen Challenge-Anfrage das Zugriffsprotokoll des Proxys. Eine eintreffende Anfrage mit Status 404 weist auf eine nicht übereinstimmende Route oder ein falsches Webroot hin; 401 oder 403 deutet auf Authentifizierung oder Filterung hin; 502 weist auf eine unnötige Upstream-Abhängigkeit im Challenge-Pfad hin.

Geben Sie dem Challenge-Pfad Vorrang vor der normalen Anwendungsrouting und behalten Sie den Hostnamen bei. Halten Sie Weiterleitungen einfach und überprüfen Sie sie extern. Leiten Sie das Token nicht durch eine Backend-Anwendung, die während der Erneuerung offline sein kann.

CGNAT, Firewalls und Erreichbarkeit von mehreren Standorten prüfen

Vergleichen Sie die WAN-Adresse des Routers mit der öffentlichen IPv4-Adresse und bestätigen Sie, dass der Validierungsport von mehr als einem externen Netzwerk aus erreichbar ist. Ein lokaler NAT-Loopback-Test kann erfolgreich sein, obwohl unaufgeforderter Internetverkehr den Router nie erreicht.

Zertifizierungsstellen validieren zunehmend von mehreren Netzwerkstandorten aus, um Routing-Angriffe zu erschweren. Die Forschung zu mehreren Validierungspunkten erklärt, warum ein Pfad, der aus einem Land, über einen ISP oder von einem Testdienst aus erreichbar ist, bei einer umfassenderen Validierung dennoch fehlschlagen kann.

Entfernen Sie während der Validierung Geoblocking, Länderfilter, vorübergehende Sperrregeln und Ratenbegrenzungen aus dem eng begrenzten Challenge-Pfad. Wenn die Heimverbindung hinter CGNAT liegt oder der ISP den erforderlichen Port blockiert, verwenden Sie stattdessen DNS-01 oder ein ausgehendes Validierungsdesign, anstatt unbeteiligte Firewall-Regeln abzuschwächen.

Den Challenge-Typ passend zur Netzwerkgrenze auswählen

Verwenden Sie HTTP-01 weiterhin, wenn der öffentliche DNS korrekt ist und Port 80 den Challenge-Responder zuverlässig erreichen kann. Nutzen Sie DNS-01, wenn der eingehende Zugriff nicht verfügbar ist, Wildcard-Zertifikate erforderlich sind oder der Dienst privat bleiben muss.

Der ZimaSpace-Artikel darüber, wie CGNAT die eingehende Validierung blockiert, hilft dabei zu erkennen, wann eine Änderung der ACME-Methode sinnvoller ist als eine Reparatur des lokalen Proxys.

Die Fehlerbehebung ist erst abgeschlossen, wenn eine erzwungene Erneuerung über die produktive Zertifizierungsstelle erfolgreich ist, das neue Zertifikat im aktiven Proxy bereitgestellt wurde, externe Clients die neue Seriennummer und das neue Ablaufdatum erhalten und ein unbeaufsichtigter Erneuerungstest ohne manuelle Port- oder DNS-Änderungen funktioniert.