Der Browser erhält keine HTTP-Antwort, und im Serverlog erscheint lediglich ein TLS-Alert. In diesem Stadium hat WordPress die Anfrage noch gar nicht gesehen: Der Fehler liegt zwischen Client, CDN, Proxy, Load Balancer und Webserver.
Statt Plugins oder Themes zu ändern, müssen Sie die fehlgeschlagene Phase des TLS-Handshakes bestimmen. Dieser Artikel zeigt einen sicheren Diagnoseweg für SNI, Zertifikatskette, Protokoll- und Cipher-Auswahl sowie eine mögliche Client-Zertifikatsprüfung.
- Was das Thema bedeutet
- Ein realistisches WordPress-Beispiel
- Warum es wichtig ist und wann es eingesetzt wird
- Der einfache Weg für Einsteiger
- Der technische Weg
- Risiken, häufige Fehler, Backup und Rollback
- Wie AIOWS unterstützt: AIOWS SSL Manager
- Passende AIOWS-Artikel
- Fazit und empfohlener Weg
- Offizielle Quellen
Was beim TLS-Handshake passiert
Vor der ersten HTTP-Anfrage handeln Client und Server eine TLS-Version und eine Cipher Suite aus. Der Client sendet üblicherweise den gewünschten Hostnamen per SNI, der Server präsentiert seine Zertifikatskette und beide Seiten prüfen, ob die gewählten Verfahren kompatibel und vertrauenswürdig sind. Optional kann der Server ein Client-Zertifikat verlangen.
Scheitert einer dieser Schritte, entsteht keine verschlüsselte HTTP-Verbindung. WordPress-Code, Inhalte und Datenbank sind dann nicht Teil des unmittelbaren Fehlerpfads.
Ein realistisches WordPress-Beispiel
Nach einer Verschärfung der TLS-Richtlinie funktionieren moderne Browser, ein älterer Unternehmens-Proxy kann die Website jedoch nicht mehr erreichen. Dessen Anfrage bietet nur veraltete Protokolle an und sendet keinen passenden SNI-Host. Der Server bricht die Aushandlung ab, bevor WordPress antworten kann.
Die Lösung besteht nicht darin, alte TLS-Versionen global wieder zu aktivieren. Zuerst wird der betroffene Clientweg belegt. Danach entscheidet das Team, ob der Proxy aktualisiert, eine eng begrenzte Übergangslösung eingerichtet oder der alte Client nicht mehr unterstützt wird.
Warum die Einordnung wichtig ist
Handshake-Fehler können alle Website-Funktionen gleichzeitig blockieren, darunter Login, REST, Webhooks und Monitoring. Eine falsche Zuordnung zu WordPress verlängert den Ausfall und verführt zu Änderungen, die weder nötig noch wirksam sind.
Untersuchen Sie TLS, wenn keine HTTP-Antwort vorliegt, ein Browser einen Verbindungsfehler meldet oder ein CDN einen Fehler wie 525 ausgibt. Gibt es dagegen eine reguläre WordPress-Fehlerseite oder einen HTTP-Statuscode, hat der Handshake bereits funktioniert.
Der einfache Weg für Einsteiger
- Notieren Sie den genauen Fehler, Hostnamen, Zeitpunkt und betroffenen Client.
- Testen Sie denselben Host mit einem aktuellen Browser und aus einem zweiten Netz.
- Prüfen Sie, ob CDN oder Proxy betroffen ist oder ob auch der direkte Ursprung fehlschlägt.
- Kontrollieren Sie Zertifikatsname, Ablaufdatum und vollständige Kette.
- Machen Sie Änderungen an TLS-Richtlinien nur mit einem dokumentierten Rollback.
- Bestätigen Sie nach der Korrektur zuerst den Handshake und anschließend Login, REST und Webhooks.
Der technische Weg
Erfassen Sie Client- und Server-IP, SNI-Hostname, angebotene TLS-Versionen und Cipher Suites, ausgewählte Parameter, TLS-Alert, Zertifikatskette, Signaturalgorithmus und ALPN. Vergleichen Sie einen erfolgreichen Kontrollclient mit dem fehlerhaften Weg.
- Testen Sie jeden öffentlichen Host über IPv4 und IPv6.
- Trennen Sie CDN-zu-Client und CDN-zu-Ursprung, da beide unterschiedliche TLS-Richtlinien haben können.
- Prüfen Sie, ob am Listener versehentlich ein Client-Zertifikat verlangt wird.
- Ordnen Sie die erste Abweichung einer konkreten Konfigurationsänderung zu.
Risiken, häufige Fehler, Backup und Rollback
Das globale Aktivieren veralteter Protokolle oder schwacher Cipher Suites behebt zwar möglicherweise einen alten Client, senkt aber die Sicherheit für alle Besucher. Ebenso gefährlich ist es, Zertifikatsprüfungen zu deaktivieren oder selbstsignierte Zertifikate ungeprüft einzusetzen.
- Sichern Sie die aktuelle Listener-, Proxy- oder CDN-Konfiguration.
- Ändern Sie pro Test nur eine TLS-Variable.
- Behalten Sie einen modernen Kontrollclient und eine funktionierende Admin-Verbindung.
- Rollen Sie zurück, wenn zuvor erfolgreiche Clients oder die Verbindung zum Ursprung ausfallen.
Wie AIOWS unterstützt:
AIOWS SSL Manager
AIOWS SSL Manager unterstützt die Prüfung des WordPress-seitigen HTTPS-Zustands, sobald eine TLS-Verbindung zustande kommt. Damit lässt sich nach einer Infrastrukturkorrektur kontrollieren, ob WordPress die erwarteten sicheren Adressen verwendet und die Anwendung über HTTPS konsistent erreichbar ist.
Bei einem echten Handshake-Fehler beginnt die Diagnose jedoch vor WordPress. Prüfen Sie zunächst den öffentlichen Host und gegebenenfalls die separate Verbindung zwischen CDN und Ursprung. Erst wenn der TLS-Handshake erfolgreich ist und eine HTTP-Antwort vorliegt, ist es sinnvoll, die WordPress-seitigen Einstellungen mit SSL Manager zu überprüfen. Testen Sie danach Startseite, Login, Administration, REST und einen realen Formular- oder Webhook-Pfad.
Das Modul kann keine Cipher Suite am Load Balancer ändern, kein SNI-Routing im CDN korrigieren und keine externe Client-Zertifikatsrichtlinie aufheben. Diese Aufgaben bleiben bei der jeweiligen Infrastruktur. Halten Sie Änderungen an Listenern und TLS-Richtlinien deshalb außerhalb von WordPress fest und sichern Sie die vorherige Konfiguration. Wird die Verbindung für zuvor funktionierende Clients schlechter, rollen Sie die Infrastrukturänderung zurück. AIOWS hilft anschließend bei der klaren Abgrenzung: Funktioniert die sichere Verbindung, aber WordPress erzeugt falsche URLs oder Redirects, liegt ein Anwendungsthema vor; scheitert bereits die Aushandlung, muss die vorgelagerte Ebene repariert werden.
Passende AIOWS-Artikel
- SSL auf einer WordPress-Website richtig einrichten
- SSL-Zertifikatname stimmt in WordPress nicht überein
- WordPress-SSL-Zertifikat und HTTPS-Status prüfen
Fazit und empfohlener Weg
Diagnostizieren Sie den Fehler vor der HTTP-Ebene. Korrigieren Sie gezielt Zertifikatskette, SNI, Protokoll, Cipher oder Client-Authentifizierung und schwächen Sie eine moderne TLS-Richtlinie nur bei einer belegten, eng begrenzten Ausnahme.
