Ein Unternehmen installiert ein Zertifikat für example.com, doch Besucher von www.example.comerhalten weiterhin eine Sicherheitswarnung. Zugleich prüft das CDN das Origin-Zertifikat nicht und ein Formular auf der Startseite sendet an eine HTTP-Adresse.
Eine erneute Zertifikatsinstallation behebt diese drei Ursachen nicht. Browserfehler, betroffener Hostname, TLS-Endpunkt und Seitenanfragen müssen nacheinander geprüft werden.
- 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 Rückweg
- Wie AIOWS unterstützt: AIOWS SSL Manager
- Passende AIOWS-Artikel
- Fazit und empfohlener Weg
- Offizielle Quellen
Was das Thema bedeutet
Die Meldung „Nicht sicher“ kann nach einer SSL-Installation verschiedene Ursachen haben: Der aufgerufene Hostname fehlt im Zertifikat, die Kette ist abgelaufen oder unvollständig, die Seite wird noch per HTTP ausgeliefert oder sie lädt unsichere Ressourcen nach. Auch ein HTTP-Formularziel, der Proxymodus oder lokal gespeicherte HSTS-Daten beeinflussen die Browseranzeige.
Das öffentlich sichtbare Zertifikat stammt häufig vom CDN oder Load Balancer und nicht unmittelbar vom WordPress-Server. TLS am Edge, TLS zum Ursprung, kanonische Weiterleitungen und Mixed Content hängen zusammen, werden aber an unterschiedlichen Stellen konfiguriert.
Ein realistisches WordPress-Beispiel
Im Beispiel besitzt die Hauptdomain das richtige Zertifikat, die www-Variante jedoch nicht. Das CDN beendet die Verbindung des Besuchers und greift anschließend auf den Ursprung zu, ohne dessen Zertifikat zu prüfen. Nach diesen Korrekturen bleibt die HTTP-Adresse des Formulars als eigener WordPress-Fehler bestehen.
Tests der tatsächlichen öffentlichen URLs geben die Reihenfolge vor: zunächst alle vorgesehenen Hostnamen abdecken, dann die Verschlüsselung zum Ursprung prüfen und erst danach unsichere Seitenressourcen korrigieren.
Warum es wichtig ist und wann es eingesetzt wird
Zertifikatswarnungen beeinträchtigen Anmeldungen, Zahlungen, Formulare und das Vertrauen der Besucher. Sie können außerdem bedeuten, dass nicht der gesamte Übertragungsweg geschützt ist, obwohl an einem Endpunkt ein gültiges Zertifikat erscheint.
Diese Prüfung ist immer dann nötig, wenn eine reale öffentliche URL nach der Zertifikatsinstallation unsicher bleibt. Ausgangspunkt sind der genaue Browserfehler und der betroffene Hostname. Zertifikatsprüfungen dürfen nicht abgeschaltet und HSTS nicht während einer ungeklärten Konfiguration aktiviert werden.
Der einfache Weg für Einsteiger
- Listen Sie alle öffentlichen Hostnamen auf, die die Website bedienen soll, einschließlich Hauptdomain und
www-Variante. - Prüfen Sie für jeden Namen das ausgelieferte Zertifikat, seine Domainnamen, den Aussteller, die Laufzeit und die Zwischenzertifikate.
- Verfolgen Sie HTTP- und HTTPS-Weiterleitungen bis zur vorgesehenen kanonischen Adresse und schließen Sie Schleifen aus.
- Kontrollieren Sie WordPress- und Website-Adresse sowie die endgültige Seite auf HTTP-Ressourcen und unsichere Formularziele.
- Testen Sie Anmeldung, eine harmlose Formularübermittlung und eine unveränderte Seite in einem sauberen Browser, bevor die endgültige Weiterleitung erzwungen wird.
Der technische Weg
Vergleichen Sie Zertifikat und SNI-Ergebnis am öffentlichen Edge mit der direkten Verbindung zum Ursprung. Berücksichtigen Sie IPv4 und IPv6, relevante CDN-Knoten, Host-Header-Routing, die Prüfung des Origin-Zertifikats durch den Proxy und die Zuständigkeit für die Erneuerung.
Ist die öffentliche Zertifikatskette korrekt, helfen Netzwerk- und Sicherheitsansicht des Browsers bei der Suche nach Mixed Content oder einem unsicheren Formularziel. Lokal gespeicherte HSTS-Daten sind ein zusätzlicher Clientfaktor, aber kein Beleg für eine korrekte Serverkonfiguration.
Risiken, häufige Fehler, Backup und Rückweg
Häufig werden nur einzelne Hostnamen ins Zertifikat aufgenommen, Weiterleitungen vor funktionierendem Ziel-HTTPS aktiviert oder Proxymodi ohne Prüfung des Ursprungs gewählt. Auch das Abschalten der Zertifikatsprüfung beseitigt lediglich die Warnung, nicht den Fehler.
Während Änderungen an Weiterleitung oder Proxy muss der bisherige Zugang erhalten bleiben. Kehren Sie zurück, wenn die Verwaltung unerreichbar wird, Hostnamen zur falschen Website führen, der Ursprung kein vertrauenswürdiges TLS aushandelt oder die Zuständigkeit für die Erneuerung fehlt. HSTS kommt erst nach einer stabilen Prüfung aller Wege infrage.
Wie AIOWS unterstützt:
AIOWS SSL Manager
Der AIOWS SSL Manager bündelt unterstützte WordPress-Einstellungen für HTTPS, Weiterleitungen und Mixed-Content-Prüfungen. So lassen sich WordPress-Adressen und Weiterleitungszustand von Zertifikats- und Proxyproblemen außerhalb von WordPress unterscheiden.
Nutzen Sie das Modul erst nach der Prüfung der öffentlichen und internen Zertifikate. Halten Sie eine einzige Stelle für Weiterleitungen sowie einen Rückweg zur Administration fest und testen Sie anschließend direktes HTTPS, die HTTP-Weiterleitung, Anmeldung, Formulare und Seitenressourcen in einer sauberen Sitzung.
AIOWS kann keine externen Zertifikate validieren, CDN- oder Origin-TLS reparieren, DNS ändern oder eine unsichere Drittanbieterressource absichern. Diese Aufgaben bleiben bei Zertifikatsstelle, Hosting, CDN und dem jeweiligen Anbieter.
Passende AIOWS-Artikel
- Mixed Content in WordPress beheben: HTTPS-Fehler richtig lösen
- HTTPS in WordPress erzwingen, ohne die Website zu beschädigen
- WordPress-SSL-Zertifikat und HTTPS-Status prüfen
Fazit und empfohlener Weg
Beginnen Sie mit der genauen Warnung und dem betroffenen Hostnamen. Prüfen Sie Zertifikat am öffentlichen Edge, verschlüsselte Verbindung zum Ursprung, kanonische Weiterleitungen und Seitenressourcen getrennt. Erst wenn alle vorgesehenen Hostnamen und wichtigen Funktionen in einem sauberen Browser bestehen, ist die Umstellung abgeschlossen.
