{{sidenavigation.sidenavigationExpandLabel}}
{{getMsg('Help_YouAreHere')}}: /  {{page.title}} {{page.title}}
{{$root.getMsg("downLoadHelpAsPdf")}} {{helpModel.downloadHelpPdfDataStatus}}

Fehlerbehebung beim sicheren Zugriff

Wählen Sie das Symptom, das am besten zum Problem passt. Prüfen Sie jeweils nur eine Änderung und sichern Sie ein funktionierendes Zertifikat, bevor Sie Zertifikatspfade ändern.

Der Browser zeigt eine Zertifikatswarnung

Prüfen Sie, ob der angeforderte Hostname im Zertifikat enthalten ist und ob das Zertifikat weder Staging noch selbst signiert ist. Prüfen Sie, ob der Server die vollständige Zertifikatskette sendet. Die Seite Selbst signiertes HTTPS-Zertifikat erzeugen erklärt die Warnung bei Testzertifikaten.

DNS-01-Validierung schlägt fehl

Prüfen Sie den TXT-Record bei den autoritativen DNS-Servern und einem öffentlichen Resolver:

dig TXT _acme-challenge.app.example.com

Prüfen Sie Recordname, Wert, TTL, CAA-Richtlinie und DNS-Delegation. Warten Sie, bis alte zwischengespeicherte Werte abgelaufen sind. Bei einem API-Modul prüfen Sie Tokenumfang und die tatsächlich geänderte autoritative Zone.

Starten Sie nicht wiederholt neue Bestellungen, während die erste Bestellung auf DNS-Propagation wartet. Dadurch können Rate-Limits ausgelöst werden.

DNS-PERSIST-01 meldet eine abgelaufene Autorisierung

Verwenden Sie exakt Recordname und Wert, die der ACME-Client anzeigt. Prüfen Sie Ablaufdatum und verwendetes Clientkonto. Eine Staging-Autorisierung wird möglicherweise vom Produktionsverzeichnis nicht akzeptiert. Erstellen Sie eine neue Autorisierung, wenn Client oder Zertifizierungsstelle dies verlangen.

Erneuerte Dateien werden nicht verwendet

Prüfen Sie, ob der ACME-Client in die als eigenes Zertifikat konfigurierten Pfade schreibt und der private Schlüssel für den Serverprozess lesbar bleibt. Wenn ein externer Client erneuert, müssen dessen Zeitplan und Logs separat geprüft werden.

Die Aufgabe Automatische Aktualisierung von benutzerdefinierten SSL-Zertifikaten lädt geänderte eigene Zertifikatsdateien. Behalten Sie die Dateipfade bei und prüfen Sie, ob Änderung von Zertifikat und Schlüssel verarbeitet wird.

Wenn ein Reverse-Proxy oder Tunnel HTTPS beendet, konfigurieren Sie die externe sichtbare URL mit öffentlichem Schema, Hostnamen, Port und Kontext. Leiten Sie die auf der Seite Reverse-Proxy-Konfiguration genannten Header weiter.

Tailscale Serve kann keine Verbindung herstellen

Prüfen Sie, ob Server und Client beim selben Tailnet angemeldet sind, das Gerät freigegeben ist und ACLs die Verbindung erlauben. Prüfen Sie lokalen Dienstport und führen Sie Folgendes aus:

tailscale serve status

Stellen Sie sicher, dass der lokale Dienst auf der von Serve verwendeten Adresse lauscht. Wenn er nur an einer privaten Schnittstelle oder einem anderen Port lauscht, passen Sie Serve-Ziel oder Webserver-Verbindung an.

Ein öffentlicher Tunnel ist nicht erreichbar

Prüfen Sie Connectorprozess, Kontostatus und Statusseite des Anbieters. Prüfen Sie, ob der lokale Ursprungsport vom Connector-Host erreichbar ist. Kontrollieren Sie die Zugriffsrichtlinie und ob der öffentliche Hostname dem richtigen Connector zugeordnet ist.

Verwandte Seiten

Die Webserver-Konfiguration beschreibt HTTPS-Verbindung und Zertifikatsquelle. DNS-01 und Externe ACME-Clients enthalten die detaillierten Zertifikatsprüfungen.

i-net PDFC
Diese Anwendung verwendet Cookies um das Einloggen zu ermöglichen. Durch die weitere Nutzung dieser Anwendung stimmen Sie der Verwendung von Cookies zu.


Hilfe