ERR_SSL_PROTOCOL_ERROR

Was dieser Fehler bedeutet und wie du ihn erkennst

• Chrome oder Edge meldet „Diese Website kann keine sichere Verbindung bereitstellen“ mit ERR_SSL_PROTOCOL_ERROR.
• Der Fehler kann die gesamte Website, eine Subdomain oder nur einen Hostnamen hinter einem Proxy oder Load Balancer betreffen.
• Unverschlüsseltes HTTP auf Port 80 kann funktionieren, während HTTPS fehlschlägt. Das deutet auf ein Problem im TLS-Pfad hin, nicht zwangsläufig auf ein Problem der Anwendung.
• Der Fehler kann nach einer Zertifikatserneuerung, Servermigration, Änderung der Webserver-Konfiguration, CDN-Änderung oder Änderung des Dienstes auftreten, der auf Port 443 lauscht.
• Ein direkter Origin-Test und ein Test über den öffentlichen Hostnamen können unterschiedliche Ergebnisse liefern, wenn ein CDN, Reverse Proxy oder Load Balancer beteiligt ist.

Hauptursachen nach Wahrscheinlichkeit

1. Port 443 liefert unverschlüsseltes HTTP oder ein anderes Nicht-TLS-Protokoll aus. Der HTTPS-Listener fehlt möglicherweise oder der falsche Dienst ist an Port 443 gebunden. Der Browser empfängt dann Daten, die keinen TLS-Handshake darstellen.
2. Der virtuelle HTTPS-Host oder Server-Block ist falsch konfiguriert. Der Server lauscht möglicherweise an der falschen Adresse, wählt den falschen Hostnamen aus oder enthält nicht die vom Webserver benötigten TLS-Direktiven.
3. CDN, Reverse Proxy oder Load Balancer verwendet eine falsche Origin-Konfiguration. Der Proxy verwendet möglicherweise HTTP, während der Origin-Server HTTPS erwartet, oder verbindet sich mit dem falschen Port oder Backend.
4. Die TLS-Konfiguration ist inkompatibel oder fehlerhaft. Nicht unterstützte Protokollversionen, zu restriktive Cipher-Einstellungen, SNI-Routing-Probleme oder ein falsch konfiguriertes TLS-terminierendes Gerät können den Handshake vor der Zertifikatsprüfung abbrechen.
5. Das Zertifikat oder die Zertifikatskette ist unbrauchbar. Ein abgelaufenes Zertifikat, ein fehlendes Zwischenzertifikat oder ein Zertifikat, das den angeforderten Hostnamen nicht abdeckt, kann eine sichere Verbindung verhindern. Manche Browser und Verbindungspfade zeigen stattdessen eine spezifischere Zertifikatswarnung an.
6. Ein erneuertes Zertifikat wurde vom Dienst nicht geladen. Das Aktualisieren von Zertifikatsdateien auf dem Datenträger ändert das vom laufenden Webserver präsentierte Zertifikat nicht, solange dessen Konfiguration nicht entsprechend dem dokumentierten Verfahren des Dienstes neu geladen oder der Dienst neu gestartet wurde.

So behebst du den Fehler

1. Feststellen, ob der Fehler öffentlich, Origin-spezifisch oder lokal ist

Rufen Sie den exakt betroffenen Hostnamen über ein zweites Netzwerk oder Gerät auf. Wenn nur ein Computer fehlschlägt, prüfen Sie lokale Sicherheitssoftware, Interception-Proxys und die Systemzeit. Wenn jeder Client fehlschlägt, setzen Sie die Untersuchung auf Server-, Proxy-, CDN- oder Load-Balancer-Seite fort.

Wenn HTTP funktioniert, HTTPS jedoch nicht, konzentrieren Sie sich auf den TLS-Listener, Port 443, die Zertifikatauswahl und jeden Proxy zwischen Client und Origin-Server. Gehen Sie nicht davon aus, dass ein erfolgreicher HTTP-Aufruf die korrekte HTTPS-Konfiguration bestätigt.

2. TLS-Handshake testen, ohne den Serverstatus zu ändern

Führen Sie in einem administrativen Terminal mit Netzwerkzugriff auf den Endpunkt Folgendes aus:

openssl s_client -connect [your-hostname]:443 -servername [your-hostname] -showcerts

Die Option -servername ist wichtig, wenn SNI Zertifikate oder virtuelle Hosts auswählt. Notieren Sie, ob der Handshake beginnt, welches Zertifikat zurückgegeben wird, wann das Zertifikat abläuft, welche Hostnamen in den Subject Alternative Names enthalten sind und ob Zwischenzertifikate mitgeliefert werden.

• Wenn die Verbindung unverschlüsseltes HTTP zurückgibt oder fehlschlägt, bevor ein Zertifikat erscheint, prüfen Sie den Listener auf Port 443 und das Proxy-Routing.
• Wenn ein Zertifikat zurückgegeben wird, vergleichen Sie es mit dem angeforderten Hostnamen und prüfen Sie seine Gültigkeitsdaten sowie die Zertifikatskette.
• Wenn ein direkter Origin-Test funktioniert, der öffentliche Hostname jedoch fehlschlägt, untersuchen Sie CDN, Reverse Proxy, Load Balancer oder DNS-Pfad, statt die Anwendung zu ändern.

3. HTTPS-Listener und Hostnamen-Routing prüfen

Prüfen Sie mit entsprechendem Serverzugriff und der erforderlichen Berechtigung die aktive Webserver-Konfiguration und bestätigen Sie, dass:

• der vorgesehene Dienst auf Port 443 lauscht;
• der HTTPS-Server-Block oder virtuelle Host aktiviert ist;
• der angeforderte Hostname in den relevanten server_name- oder ServerName-/ServerAlias-Einstellungen enthalten ist;
• TLS für diesen Listener aktiviert ist; und
• die Pfade zu Zertifikat und privatem Schlüssel auf die vorgesehenen Dateien verweisen.

Prüfen Sie bei Nginx den aktivierten Server-Block und seine Konfiguration listen 443 ssl. Prüfen Sie bei Apache die Konfiguration <VirtualHost *:443> und SSLEngine on. Übernehmen Sie keine Direktiven zwischen Produkten, ohne Syntax und von der installierten Serverversion unterstützte Optionen zu prüfen.

4. Zertifikat und Zertifikatskette validieren

Bestätigen Sie, dass das präsentierte Zertifikat:

• nicht abgelaufen und nicht vorzeitig ungültig ist;
• den exakten Hostnamen in seinen Subject-Alternative-Name-Einträgen abdeckt;
• zum zugehörigen privaten Schlüssel passt; und
• von der erforderlichen Zertifikatskette mit Zwischenzertifikaten begleitet wird.

Ein Zertifikat für die Stammdomain deckt nicht automatisch jede Subdomain ab. Die Subdomain muss ausdrücklich aufgeführt oder durch ein geeignetes Wildcard-Zertifikat abgedeckt sein. Wenn der Server nur das Leaf-Zertifikat präsentiert, installieren Sie die von der Zertifizierungsstelle bereitgestellte Kettendatei im vom Webserver geforderten Format.

5. Erneuerung und Laden des Zertifikats prüfen

Bei einer von Certbot verwalteten Bereitstellung kann ein Administrator certbot renew --dry-run ausführen, um den Erneuerungsablauf zu testen, ohne ein Produktionszertifikat auszustellen. Prüfen Sie die Ausgabe, die Erneuerungskonfiguration, Berechtigungen und den Reload-Hook des Dienstes.

Wenn die Erneuerung erfolgreich war, Clients aber weiterhin das alte Zertifikat erhalten, bestätigen Sie, dass der Webserver oder TLS-terminierende Proxy die neuen Dateien geladen hat. Ein Reload oder Neustart ändert den Dienststatus und sollte nur während eines genehmigten Wartungsfensters mit Rollback-Plan und gemäß dem dokumentierten Verfahren des Produkts durchgeführt werden. Führen Sie diese operative Aktion getrennt von schreibgeschützter Diagnose durch.

6. TLS-Einstellungen von CDN, Proxy und Load Balancer prüfen

Ermitteln Sie, wo TLS terminiert wird: am CDN, Edge-Proxy, Load Balancer oder Origin-Server. Prüfen Sie, ob das konfigurierte Origin-Protokoll und der Origin-Port dem tatsächlich vom Origin bereitgestellten Dienst entsprechen.

Wenn ein CDN Modi wie Flexible, Full oder Full (strict) anbietet, wählen Sie den Modus, der der tatsächlichen Konfiguration und Zertifikatsgültigkeit des Origin-Servers entspricht. Ein weniger strenger Modus kann das zugrunde liegende Problem verbergen oder einen anderen Fehler verursachen. Er ist kein dauerhafter Ersatz für ein gültiges Origin-Zertifikat. Ändern Sie die Konfiguration nur mit entsprechender Berechtigung und testen Sie anschließend sowohl den öffentlichen Hostnamen als auch nach Möglichkeit den Origin-Pfad erneut.

7. Auf Beeinflussung durch Protokoll, SNI oder Netzwerkgeräte prüfen

Wenn der Endpunkt ein gültiges, passendes Zertifikat präsentiert, der Handshake aber weiterhin fehlschlägt, vergleichen Sie die Ergebnisse aus verschiedenen Netzwerken und mit verschiedenen TLS-Clients. Prüfen Sie Firewall-, Load-Balancer-, Web-Application-Firewall- und TLS-Inspection-Einstellungen auf blockierte Protokollversionen, nicht unterstützte Cipher-Richtlinien, falsches SNI-Routing oder veränderten Datenverkehr. Bewahren Sie die Handshake-Ausgabe und relevante Serverprotokolle für den Hosting-Anbieter oder Netzwerkadministrator auf.

Vorbeugung und Überprüfung der Lösung

• Überwachen Sie den Zertifikatsablauf unabhängig vom Erneuerungsmechanismus und lösen Sie Warnungen aus, bevor Zertifikate ungültig werden.
• Testen Sie die Erneuerung in einer Nicht-Produktionsumgebung oder per Dry Run und überprüfen Sie, ob der Reload-Hook des Dienstes tatsächlich das neue Zertifikat präsentiert.
• Führen Sie ein dokumentiertes Inventar aller Hostnamen, TLS-Terminierungspunkte, Zertifikate, privaten Schlüssel und Zwischenzertifikatsketten.
• Testen Sie nach Änderungen an Zertifikaten, Proxys, Load Balancern oder Port-Zuordnungen den öffentlichen Hostnamen und jede wichtige Subdomain.
• Prüfen Sie Änderungen an der TLS-Konfiguration vor der Bereitstellung auf Kompatibilität von SNI, Protokollversion, Cipher und Origin-Port.
• Bewahren Sie aktuelle Server-, Proxy- und Zertifikatsinformationen auf, damit ein fehlgeschlagener Handshake mit der letzten funktionierenden Konfiguration verglichen werden kann.

Häufig gestellte Fragen