Warum wird nach der Installation eines SSL-Sicherheitszertifikats weiterhin eine Sicherheitswarnung angezeigt?

Nach Abschluss der Installation des SSL-Sicherheitszertifikats zeigt der Browser weiterhin „Verbindung nicht sicher“, „Zertifikat ungültig“ an oder in der Adressleiste erscheint kein Schlosssymbol. In der Regel ist nicht die Zertifikatsdatei selbst ungültig, sondern die Bereitstellungskette ist unvollständig, die aufgerufene Domain stimmt nicht überein, die Seite lädt weiterhin HTTP-Ressourcen oder der Server hat HTTPS nicht korrekt aktiviert. Solche Probleme beeinträchtigen das Vertrauen der Besucher in die Website und können dazu führen, dass Browser Vorgänge wie Anmeldung, Formularübermittlung oder Zahlungsweiterleitung blockieren oder vor Risiken warnen.

Bei der Fehlersuche sollte nicht nur geprüft werden, „ob das Zertifikat gekauft und hochgeladen wurde“. Maßgeblich sind das vom Browser tatsächlich aufgerufene Zertifikat, der Zugriffsweg und die Seitenressourcen: Bestimmen Sie zunächst den Fehlertyp, prüfen Sie dann Domain, Zertifikatskette, Port und Weiterleitungsregeln und beheben Sie anschließend gemischte Inhalte. So vermeiden Sie, Zertifikate wiederholt auszutauschen, ohne das Problem lösen zu können.

Prüfen Sie zuerst die Browsermeldung, um festzustellen, auf welcher Ebene das Problem liegt

Klicken Sie in der Browser-Adressleiste auf den Hinweis „Nicht sicher“ oder das Schlosssymbol, um die Zertifikatsdetails und die konkrete Fehlermeldung anzuzeigen. Unterschiedliche Symptome weisen auf unterschiedliche Ursachen hin.

Auch die Browser-Konsole ist entscheidend. Wenn in der Konsole „Mixed Content“ angezeigt wird, bedeutet dies, dass die Hauptseite bereits über HTTPS geöffnet wurde, bestimmte Ressourcen jedoch weiterhin über HTTP angefordert werden. Wird ein falscher Zertifikatsname oder eine fehlgeschlagene Zertifikatskettenprüfung angezeigt, sollte die Server-Bereitstellungsebene überprüft werden.

Nicht übereinstimmende Domains sind nach der Installation eines SSL-Sicherheitszertifikats ein besonders leicht zu übersehendes Problem

Ein Zertifikat ist nur für die darin aufgeführten Domains gültig und deckt nicht automatisch alle Varianten ab. Wird ein Zertifikat beispielsweise nur für www.example.com ausgestellt, kann der direkte Aufruf von example.com weiterhin einen Fehler verursachen. Ein gewöhnliches Einzel-Domain-Zertifikat für die Hauptdomain deckt in der Regel auch Subdomains wie shop.example.com oder en.example.com nicht ab.

Prüfen Sie in den Zertifikatsdetails die „Subject Alternative Names (SAN)“ oder „Alternative Antragstellernamen“ und vergleichen Sie diese einzeln mit den tatsächlichen Zugangsadressen. Bestätigen Sie mindestens Folgendes:

• ob Domains mit www und ohne www beide abgedeckt sind oder ob eine einheitliche Weiterleitung eingerichtet wurde;
• ob mehrsprachige Websites, Shop-Subsites, Download-Seiten, Verwaltungs-Backends usw. eigenständige Subdomains verwenden;
• ob Nutzer möglicherweise über alte Domains, Testdomains oder IP-Adressen direkt zugreifen;
• ob das Zertifikat in der aktuell extern bereitgestellten Domain-Bindung oder virtuellen Host-Konfiguration installiert ist.

Versuchen Sie nicht, eine Namensabweichung dadurch zu verdecken, dass „alle Domains auf HTTPS weitergeleitet werden“. Die Weiterleitung erfolgt erst nach dem TLS-Handshake. Der Browser muss zunächst das Zertifikat der aktuellen Domain prüfen; bei einem nicht passenden Zertifikatsnamen erscheint daher weiterhin zuerst eine Warnung. Der richtige Ansatz besteht darin, den Zertifikatsumfang für die tatsächlichen Zugangsadressen zu erweitern oder Domains auf DNS-, Website-Einstiegs- und Werbelink-Ebene einheitlich zu standardisieren.

Bei einer fehlenden Zertifikatskette scheint der Server korrekt eingerichtet zu sein, kann vom Client jedoch nicht verifiziert werden

Ein SSL-Zertifikat besteht in der Regel nicht nur aus einem Serverzertifikat. Der Browser benötigt außerdem Zwischenzertifikate, um einen Validierungspfad zu einem vertrauenswürdigen Stammzertifikat aufzubauen. Wird bei der Bereitstellung nur das Domain-Zertifikat hochgeladen, ohne das von der CA bereitgestellte Zwischenzertifikatpaket zu konfigurieren, melden einige Browser oder ältere Geräte das Zertifikat als nicht vertrauenswürdig.

In einer Nginx-Umgebung besteht ein häufiges Problem darin, dass ssl_certificate auf eine einzelne Zertifikatsdatei verweist statt auf eine vollständige Kettendatei mit Server- und Zwischenzertifikaten. Bei Apache muss geprüft werden, ob die entsprechende Zertifikatskettenkonfiguration den Anforderungen der aktuellen Version entspricht. In Umgebungen mit Control Panels sollte die von der Zertifizierungsstelle bereitgestellte Datei „vollständige Zertifikatskette“, „fullchain“ oder „CA Bundle“ verwendet werden, anstatt nur den ersten Zertifikatsblock einzufügen.

Auch eine falsche Reihenfolge der Kette muss vermieden werden. Üblicherweise wird zuerst das Website-Zertifikat bereitgestellt und anschließend werden die Zwischenzertifikate der Reihe nach angefügt; das Stammzertifikat muss der Server normalerweise nicht aktiv ausliefern. Laden Sie nach dem Austausch der Dateien die Webservice-Konfiguration neu und prüfen Sie erneut über ein externes Netzwerk, statt nur auf dem Server selbst zu kontrollieren, ob die Dateien vorhanden sind.

HTTPS ist aktiviert – warum wird die Seite dennoch als unsicher angezeigt?

Diese Situation hängt meist mit gemischten Inhalten zusammen. Das Seiten-HTML wird über HTTPS übertragen, aber Bilder, JavaScript, CSS, Videos, Schriftarten, Tracking-Code, iframes oder Schnittstellenadressen sind weiterhin als http:// hinterlegt. Moderne Browser blockieren bestimmte aktive Inhalte wie Skripte und XHR-Anfragen direkt; einige Bilder oder Medienressourcen können hingegen geladen werden, führen jedoch zu einem niedrigeren Sicherheitsstatus.

Beginnen Sie bei der Behebung mit dem Quellcode der Seite und der Browser-Konsole, ermitteln Sie die konkrete Ressourcenadresse und prüfen Sie anschließend die Ressourcenquelle:

1. Statische Ressourcen der Website sollten auf absolute HTTPS-Adressen umgestellt werden oder relative Pfade verwenden, die für die aktuelle Website geeignet sind;
2. Fest codierte HTTP-Links in Vorlagen, Rich-Text-Inhalten, Produktdetails und historischen Artikeln sollten gesammelt geprüft werden;
3. Bei Skripten von Drittanbietern, Karten, Kundendienstfenstern, Videoeinbettungen und Formularkomponenten muss sichergestellt werden, dass sie HTTPS unterstützen;
4. Auch Schnittstellen-Domains, Dateispeicher-Domains und Bild-CDNs müssen gültige Zertifikate bereitstellen; es genügt nicht, nur die Domain der Startseite zu ändern;
5. Leeren Sie nach den Änderungen den Website-Cache, CDN-Cache und Browser-Cache und führen Sie anschließend erneut Tests durch.

Es wird nicht empfohlen, sich ausschließlich auf die Browserstrategie „unsichere Anfragen automatisch aktualisieren“ zu verlassen. Sie kann als Übergangsmaßnahme dienen, gewährleistet jedoch nicht, dass alle Ressourcen korrekt geladen werden. Unterstützen Drittanbieterressourcen kein HTTPS, können weiterhin fehlende Stile, Funktionsstörungen oder fehlgeschlagene Datenanfragen auftreten.

Überprüfen Sie Server-Listening, Weiterleitungen und Konfigurationen mehrerer Knoten

Ein korrektes Zertifikat bedeutet nicht zwangsläufig, dass Port 443 bereits vom richtigen Website-Service übernommen wurde. Es sollte bestätigt werden, dass Server-Firewall, Sicherheitsgruppe und Webservice den Zugriff auf Port 443 erlauben und dass dieser Port an das Zertifikat der Ziel-Domain gebunden ist. In Umgebungen mit gemeinsam genutzter IP und mehreren Websites kann eine fehlerhafte SNI-Konfiguration dazu führen, dass der Server das Zertifikat einer anderen Website zurückgibt, wodurch eine Domain-Abweichung entsteht.

Auch die Weiterleitung von HTTP zu HTTPS muss überprüft werden. Im Idealfall führt der Aufruf der Version http:// mit einer einmaligen 301- oder 308-Weiterleitung zur kanonischen HTTPS-Adresse. Es darf keine Schleife entstehen, bei der HTTP zu HTTPS und HTTPS wieder zurück zu HTTP weiterleitet. Ebenso sollten verschiedene Seiten nicht fortlaufend zwischen Varianten mit und ohne www weiterleiten. Insbesondere Anmeldeseiten, Formularübermittlungsseiten, Zahlungsrückrufseiten und Backend-Zugänge sollten separat geprüft werden.

Wenn der Website CDN, Load Balancer oder Reverse Proxy vorgeschaltet sind, müssen außerdem die Zertifikate der Edge-Knoten und des Origin-Servers jeweils separat überprüft werden. Funktionieren die Edge-Knoten, während der Origin-Server fehlerhaft ist, können bestimmte Origin-Abrufszenarien scheitern. Wurde der Origin-Server aktualisiert, während das CDN noch ein altes Zertifikat verwendet, kann der externe Zugriff ebenfalls weiterhin das alte Zertifikat anzeigen. Bei Dual-Stack-DNS-Auflösung mit IPv4 und IPv6 sollten die Knoten beider Adresstypen getestet werden.

Vermeiden Sie wiederkehrende Probleme wie „direkt nach der Verlängerung erneut ein Fehler“

Wenn nach einer Zertifikatsverlängerung weiterhin das alte Zertifikat angezeigt wird, wurde häufig der Konfigurationsreferenzpfad nicht aktualisiert, der Dienst nicht neu geladen oder ein Knoten nicht mit der neuen Datei synchronisiert. Bei der Erstellung von Aufzeichnungen zu Zertifikatsänderungen sollten gleichzeitig die vom Zertifikat abgedeckten Domains, das Ablaufdatum, der Speicherort des privaten Schlüssels, der Speicherort der vollständigen Kettendatei, die Bereitstellungsknoten und der Vorgang zum Neuladen dokumentiert werden. Prüfen Sie vor und nach der Aktualisierung über das externe Netzwerk die Seriennummer und Gültigkeitsdauer, um sicherzustellen, dass der Browser tatsächlich das neue Zertifikat erhält.

Bei Marketing-Landingpages, unabhängigen Websites und mehrsprachigen Seiten sollte die HTTPS-Prüfung außerdem in den Veröffentlichungsprozess integriert werden: Prüfen Sie vor der Veröffentlichung einer neuen Seite die Protokolle externer Ressourcen, stellen Sie bei neu hinzugefügten Subdomains sicher, dass sie im Zertifikat enthalten sind, und überprüfen Sie bei neu eingebundenen Drittanbieter-Tools deren Einbettungscode. So lässt sich der Hinweis „Nicht sicher“ bereits vor der Veröffentlichung vermeiden, anstatt erst nach Rückmeldungen von Besuchern einzelne Korrekturen vorzunehmen.