Warum Browser „Nicht sicher“ anzeigen: Ursachen und Lösungen

Ein Browser zeigt „Nicht sicher“ an, wenn eine Seite ohne gültige HTTPS-Verschlüsselung ausgeliefert wird: Sie wird über einfaches HTTP geladen, sie mischt HTTP- und HTTPS-Ressourcen, oder ihr TLS-Zertifikat ist abgelaufen, fehlerhaft ausgestellt oder passt nicht zur Domain. Die Lösung besteht fast immer darin, die gesamte Seite über HTTPS mit einem gültigen, korrekt ausgestellten Zertifikat und ohne unsichere Unterressourcen auszuliefern.

Was die Warnung „Nicht sicher“ auslöst

Der Hauptauslöser ist einfach: Jede Seite, die über einfaches HTTP statt über HTTPS (HTTP über TLS, Transport Layer Security) geladen wird, ist unverschlüsselt und nicht authentifiziert, deshalb markiert der Browser sie. Seit Chrome 68 im Juli 2018 kennzeichnet Google alle einfachen HTTP-Seiten in der Adressleiste als „Nicht sicher“, nicht nur solche mit Anmeldeformularen, wie es die frühere, engere Richtlinie vorsah. Firefox zeigt bei HTTP-Seiten ein durchgestrichenes Schloss und blendet eine deutlichere Warnung ein, wenn die Seite ein Passwortfeld enthält. Safari zeigt den Text „Nicht sicher“ neben der Adressleiste an, besonders hervorgehoben, wenn es ein Text- oder Passwortfeld gibt.

Browser warnen auch bei HTTPS-Seiten, wenn das Zertifikat selbst das Problem ist: abgelaufen, selbstsigniert, für den falschen Hostnamen ausgestellt oder nicht ordnungsgemäß in den Certificate-Transparency-Logs eingetragen (einem öffentlichen Protokollsystem, das Chrome für vertrauenswürdige Zertifikate voraussetzt). Eine dritte Kategorie erfasst Websites, die technisch zwar HTTPS nutzen, einige Ressourcen aber trotzdem über HTTP laden: Mixed Content.

Die vier eigentlichen Ursachen

Jede dieser Ursachen erzeugt eine etwas andere Browsermeldung, aber alle gehen auf denselben Kern zurück: Der Browser kann nicht garantieren, dass die Verbindung durchgehend verschlüsselt ist und tatsächlich zu der Domain gehört, die sie vorgibt.

Warum trotz HTTPS „Nicht sicher“ angezeigt wird

Dieser Fall verwirrt die meisten, denn die Website hat offensichtlich ein Schloss oder ein installiertes Zertifikat und wird trotzdem markiert. Fast immer ist Mixed Content der Grund: Das HTML wird über HTTPS ausgeliefert, aber ein Stylesheet, ein Skript, ein Bild oder ein iframe ist fest auf http:// statt auf https:// oder eine protokollrelative URL eingetragen. Browser blockieren solche unsicheren Unterressourcen oder stufen sie herab, statt ihnen zu vertrauen. Aktiver Mixed Content – Skripte, iframes, Stylesheets und fetch/XHR-Anfragen – wird komplett blockiert. Deshalb kann eine Seite ihr Styling verlieren oder ganz kaputtgehen, sobald sie auf HTTPS umzieht. Passive Inhalte wie Bilder und Medien werden meist noch geladen, das reicht aber, um das Schloss zu entfernen und „Nicht sicher“ anzuzeigen.

Mixed Content finden und beheben

1. Öffne die Browserkonsole (DevTools → Console). Mixed-Content-Warnungen nennen die genauen problematischen http://-URLs.
2. Korrigiere jeden Verweis: Stelle http:// auf https:// um, wo die Ressource das unterstützt, oder verwende eine root-relative (/path) bzw. protokollrelative (//host/path) URL, damit sie das Schema der Seite übernimmt.
3. Prüfe die üblichen Verstecke: fest eingetragene Links in Templates, ältere CMS-Inhalte, E-Mail- und Marketing-Einbettungen, Werbe- und Analytics-Tags sowie Widgets von Drittanbietern.
4. Richte ein Sicherheitsnetz ein: Der Header Content-Security-Policy: upgrade-insecure-requests weist den Browser an, alle verbleibenden http://-Unterressourcen stillschweigend auf https:// umzuschreiben, sodass eine übersehene URL das Schloss nicht kaputtmacht.

Wenn das SSL-Zertifikat die Ursache ist

Der häufigste wiederkehrende Grund, warum eine Website „Nicht sicher“ wird, ist kein fehlerhafter Build, sondern ein abgelaufenes Zertifikat:

• Abgelaufen: ein manuelles Zertifikat, das niemand im Blick hatte, oder eine automatische Erneuerung, die unbemerkt fehlgeschlagen ist. Erneuere und installiere es neu, und automatisiere die Erneuerung (ACME / Let's Encrypt), wo immer es geht.
• Unvollständige Zertifikatskette: Das Zertifikat ist gültig, aber der Server sendet das Zwischenzertifikat nicht mit, sodass manche Browser und Clients es ablehnen. Installiere die vollständige Kette neu.
• Falscher Hostname oder nicht vertrauenswürdiger Aussteller: ein selbstsigniertes Zertifikat oder eines, das für example.com ausgestellt ist, während www.example.com ausgeliefert wird. Lass es für genau die richtigen Hostnamen (alle, in der SAN-Liste) von einer vertrauenswürdigen CA neu ausstellen.

Warte nicht, bis ein Kunde es dir sagt

„Nicht sicher“ ist ein Vertrauens- und SEO-Problem – Google wertet HTTPS als Ranking-Signal, und Browser zeigen die Warnung jedem Besucher –, doch meist erfährst du davon erst durch einen Kunden statt vorher. Die eigentliche Lösung ist daher, es zu überwachen. InfraNest erkennt jedes TLS-Zertifikat auf den Domains und Servern, die du verbindest, verfolgt jedes Ablaufdatum mit Warnungen Wochen im Voraus, bewertet die Konfiguration mit A–F und meldet Fehlkonfigurationen – ein fehlendes Zwischenzertifikat, einen falschen Hostnamen, einen nahenden Ablauf –, bevor ein Browser das Schloss in eine Warnung verwandelt. Grün bleibt grün.