SSL-Zertifikat und HTTPS prüfen: Häufige Fehler erkennen

HTTPS gehört heute zum Standard einer professionellen Website. Es verschlüsselt die Verbindung zwischen Browser und Webserver und schützt übertragene Daten davor, auf dem Transportweg unbemerkt mitgelesen oder verändert zu werden.

Dass eine Website grundsätzlich über https:// erreichbar ist, bedeutet allerdings noch nicht automatisch, dass die gesamte HTTPS-Konfiguration fehlerfrei ist.

Ein abgelaufenes Zertifikat, ein falscher Hostname, Mixed Content, fehlerhafte Weiterleitungen oder Probleme mit der Zertifikatskette können dazu führen, dass Browser Sicherheitswarnungen anzeigen oder einzelne Ressourcen nicht korrekt laden.

In diesem Artikel zeigen wir dir, wie du SSL-/TLS- und HTTPS-Probleme systematisch untersuchst und typische Fehler voneinander unterscheidest.

Kurz erklärt: SSL-Zertifikate ermöglichen eine verschlüsselte HTTPS-Verbindung und bestätigen, für welche Domain beziehungsweise Hostnamen ein Zertifikat gültig ist. Wenn der Browser eine HTTPS-Warnung anzeigt, solltest du deshalb nicht nur prüfen, ob überhaupt ein Zertifikat vorhanden ist, sondern auch dessen Gültigkeit, Hostnamen, Zertifikatskette und die von der Website geladenen Ressourcen.

SSL und TLS: Was ist eigentlich richtig? #

Im Alltag wird weiterhin häufig von einem SSL-Zertifikat gesprochen.

Technisch verwenden moderne HTTPS-Verbindungen jedoch TLS. SSL bezeichnet ältere Vorgängerprotokolle.

Begriffe wie:

SSL-Zertifikat
SSL-Verschlüsselung
SSL für Website

sind im allgemeinen Sprachgebrauch trotzdem weiterhin üblich.

Technisch präziser wäre beispielsweise:

TLS-Zertifikat

oder

HTTPS-Verbindung mit TLS

In diesem Artikel verwenden wir den geläufigen Begriff SSL-Zertifikat dort, wo er das Verständnis erleichtert.

Was macht HTTPS? #

Bei einer HTTPS-Verbindung kommuniziert der Browser verschlüsselt mit dem Server.

Vereinfacht:

Browser
   ↓
TLS-Verbindung
   ↓
Identität / Zertifikat prüfen
   ↓
verschlüsselte Verbindung
   ↓
Webserver

Dadurch sollen insbesondere Vertraulichkeit und Integrität der übertragenen Daten geschützt werden.

HTTP und HTTPS sind unterschiedliche URL-Varianten #

Diese beiden URLs sehen ähnlich aus:

http://example.com/

https://example.com

Technisch handelt es sich jedoch um unterschiedliche URL-Varianten.

Bei einer vollständig auf HTTPS umgestellten Website sollte die HTTP-Version normalerweise sauber auf die entsprechende HTTPS-Version weiterleiten.

Beispielsweise:

http://example.com/beispiel/

        ↓

301 Permanent Redirect

        ↓

https://example.com/beispiel/

Wie permanente Weiterleitungen funktionieren, erklären wir unter 301-Weiterleitung einrichten: URLs dauerhaft umleiten.

Was ist ein SSL-Zertifikat? #

Ein Zertifikat enthält Informationen, die für die Herstellung und Prüfung einer sicheren Verbindung benötigt werden.

Dazu gehören unter anderem Angaben darüber, für welche Hostnamen das Zertifikat gültig ist, von wem es ausgestellt wurde und in welchem Zeitraum es gültig ist.

Ein Browser prüft diese Informationen beim Aufbau der HTTPS-Verbindung.

Welche Angaben solltest du bei einem Zertifikat prüfen? #

Bei der Fehlersuche sind insbesondere folgende Punkte relevant:

Domain / Hostname

Aussteller

Gültigkeitsbeginn

Gültigkeitsende

Subject Alternative Names

Zertifikatskette

Vertrauenswürdigkeit

Moderne Browser stellen einen Teil dieser Informationen über die Sicherheits- beziehungsweise Zertifikatsinformationen oder die Entwicklertools bereit.

Das Schloss-Symbol ist nicht die ganze Diagnose #

Browseroberflächen verändern sich regelmäßig. Je nach Browser und Version wird eine sichere Verbindung deshalb nicht immer mit exakt demselben Symbol dargestellt.

Verlasse dich bei der technischen Diagnose nicht ausschließlich auf ein Schloss-Symbol.

Wichtiger ist:

Wird https:// verwendet?

Ist das Zertifikat gültig?

Passt es zum Hostnamen?

Ist die Verbindung vertrauenswürdig?

Werden unsichere Ressourcen geladen?

Erster Test: Website direkt mit HTTPS aufrufen #

Beginne mit der tatsächlichen HTTPS-Adresse:

https://deine-domain.ch

Prüfe zunächst, ob die Seite ohne Sicherheitswarnung geöffnet wird.

Anschließend solltest du nicht nur die Startseite testen, sondern auch einige typische Unterseiten.

Beispielsweise:

Startseite

Unterseite

Blogartikel

Kontaktseite

Shop- oder Produktseite

Ein Problem kann nur einzelne Seiten oder Ressourcen betreffen.

Zweiter Test: HTTP-Version aufrufen #

Rufe anschließend bewusst die unverschlüsselte Variante auf:

http://deine-domain.ch/

Bei einer vollständig auf HTTPS umgestellten Website sollte daraus normalerweise die entsprechende HTTPS-Adresse werden.

Prüfe auch eine Unterseite:

http://deine-domain.ch/beispiel/

Sie sollte nicht pauschal auf die Startseite geschickt werden, sondern normalerweise auf:

https://deine-domain.ch/beispiel

www und non-www ebenfalls prüfen #

Zusätzlich existieren häufig Varianten mit und ohne www.

Beispielsweise:

https://example.com/

https://www.example.com/

Wenn nur eine dieser Varianten als primäre Website verwendet wird, sollte die andere konsistent darauf weiterleiten.

Dasselbe gilt für HTTP-Varianten.

Eine typische Konfiguration kann beispielsweise so aussehen:

http://example.com/
        ↓
https://www.example.com/

http://www.example.com/
        ↓
https://www.example.com/

https://example.com/
        ↓
https://www.example.com/

Welche Variante als Hauptadresse verwendet wird, ist weniger wichtig als eine konsistente technische Umsetzung.

Fehler 1: Zertifikat ist abgelaufen #

Zertifikate besitzen einen begrenzten Gültigkeitszeitraum.

Wird ein Zertifikat nicht rechtzeitig erneuert, kann der Browser eine Sicherheitswarnung anzeigen.

Bei der Diagnose solltest du deshalb die Gültigkeitsdaten kontrollieren:

gültig ab:
...

gültig bis:
...

Liegt das aktuelle Datum außerhalb des gültigen Zeitraums, muss das Zertifikat erneuert beziehungsweise die automatische Erneuerung überprüft werden.

Warum Zertifikate automatisch erneuert werden #

Moderne Hosting-Systeme automatisieren die Ausstellung und Erneuerung von Zertifikaten häufig.

Eine automatische Erneuerung kann jedoch scheitern, wenn beispielsweise die Domain nicht mehr korrekt auf den Server zeigt oder eine notwendige Validierung nicht durchgeführt werden kann.

Deshalb sollte bei einem abgelaufenen Zertifikat nicht nur das Zertifikat manuell ersetzt, sondern auch die Ursache der fehlgeschlagenen Erneuerung untersucht werden.

Fehler 2: Zertifikat ist noch nicht gültig #

Auch ein Zertifikat mit einem Gültigkeitsbeginn in der Zukunft kann eine Warnung verursachen.

Bei solchen Fehlern sollte zusätzlich geprüft werden, ob Datum und Uhrzeit auf dem betroffenen Gerät beziehungsweise System korrekt eingestellt sind.

Eine falsche lokale Uhr kann dazu führen, dass ein eigentlich gültiges Zertifikat aus Sicht des Geräts noch nicht gültig oder bereits abgelaufen erscheint.

Fehler 3: Zertifikat passt nicht zur Domain #

Ein Zertifikat muss für den aufgerufenen Hostnamen gültig sein.

Angenommen, du rufst auf:

https://shop.example.com

Das ausgelieferte Zertifikat deckt aber nur:

www.example.com

ab.

Dann besteht ein Hostname-Mismatch.

Der Browser kann nicht bestätigen, dass das Zertifikat für den tatsächlich aufgerufenen Hostnamen ausgestellt wurde.

Subject Alternative Names prüfen #

Moderne Zertifikate können für mehrere Hostnamen gültig sein.

Diese werden typischerweise über sogenannte Subject Alternative Names – kurz SAN – angegeben.

Beispielsweise könnte ein Zertifikat folgende Namen abdecken:

example.com

www.example.com

Eine weitere Subdomain wie:

shop.example.com

ist dadurch nicht automatisch eingeschlossen.

Wildcard-Zertifikate #

Ein Wildcard-Zertifikat kann mehrere Subdomains einer bestimmten Ebene abdecken.

Beispielsweise:

*.example.com

kann für Hostnamen wie:

shop.example.com

mail.example.com

portal.example.com

verwendet werden.

Die Hauptdomain:

example.com

wird durch den Wildcard-Namen selbst jedoch nicht automatisch abgedeckt. Sie muss gegebenenfalls zusätzlich im Zertifikat enthalten sein.

Fehler 4: Zertifikatskette unvollständig #

Browser vertrauen einem Serverzertifikat nicht isoliert. Zwischen dem Zertifikat der Website und einer vertrauenswürdigen Stammzertifizierungsstelle können Zwischenzertifikate liegen.

Vereinfacht:

Website-Zertifikat
        ↓
Intermediate CA
        ↓
Root CA

Der Server muss die benötigte Zertifikatskette korrekt bereitstellen.

Fehlt ein notwendiges Zwischenzertifikat, können einzelne Clients Probleme bei der Vertrauensprüfung bekommen.

Warum funktioniert eine fehlerhafte Zertifikatskette manchmal trotzdem? #

Ein bereits verwendeter Browser oder ein bestimmtes Betriebssystem kann benötigte Zwischenzertifikate unter Umständen bereits kennen.

Dadurch kann eine fehlerhafte Serverkonfiguration auf einem Gerät scheinbar funktionieren, während ein anderes Gerät eine Zertifikatswarnung anzeigt.

Wenn HTTPS-Probleme nur auf bestimmten Geräten auftreten, sollte deshalb auch die Zertifikatskette untersucht werden.

Fehler 5: Mixed Content #

Mixed Content entsteht, wenn eine HTTPS-Seite Ressourcen über unverschlüsseltes HTTP lädt.

Die eigentliche Seite wird beispielsweise aufgerufen über:

https://example.com

im HTML befindet sich jedoch eine Ressource wie:

<img src="http://example.com/bild.jpg">

oder:

<script src="http://example.com/script.js"></script>

Die Seite selbst verwendet HTTPS, einzelne Bestandteile werden aber über HTTP angefordert.

Warum Mixed Content problematisch ist #

HTTPS soll eine sichere Verbindung für die ausgelieferten Inhalte herstellen.

Werden Bestandteile über HTTP geladen, ist diese Sicherheitsannahme für diese Ressourcen nicht vollständig gegeben.

Browser können solche Anfragen deshalb blockieren, automatisch aktualisieren oder Warnungen ausgeben – abhängig vom Ressourcentyp und Browser.

Typische Ursachen für Mixed Content #

Nach einer Umstellung von HTTP auf HTTPS bleiben häufig alte absolute URLs zurück.

Beispielsweise in:

HTML-Inhalten

CSS-Dateien

Theme-Einstellungen

WordPress-Datenbank

Widgets

Page Buildern

JavaScript

externen Ressourcen

alten Bild-URLs

Besonders bei älteren Websites können solche URLs an vielen Stellen gespeichert sein.

Mixed Content mit den Browser-Entwicklertools finden #

Die Entwicklertools moderner Browser sind für diese Diagnose besonders hilfreich.

Öffne die betroffene Seite und kontrolliere insbesondere die Konsole und den Netzwerkbereich.

Bei Mixed Content findest du dort häufig Hinweise auf die betroffene Ressource.

Suche nach URLs, die mit:

http://

beginnen, obwohl die Seite selbst über:

https://

geladen wurde.

Praxis-Tipp: Behebe die eigentliche HTTP-Referenz. Eine Browserwarnung lediglich zu ignorieren oder Sicherheitsmechanismen lokal abzuschalten löst das Problem nicht für deine Besucher.

Mixed Content in WordPress #

Bei WordPress tritt Mixed Content besonders häufig nach einer Umstellung der Domain, einem Website-Umzug oder einer früheren HTTP-Konfiguration auf.

Prüfe zunächst, ob die WordPress- und Website-Adresse korrekt auf HTTPS eingestellt sind.

Beispielsweise:

https://example.com

Alte HTTP-Adressen können zusätzlich direkt in Inhalten, Widgets, Theme-Optionen oder Datenbankfeldern gespeichert sein.

Nicht einfach blind Search & Replace durchführen #

Ein pauschales Suchen und Ersetzen direkt in einer WordPress-Datenbank kann problematisch sein.

WordPress, Themes und Plugins können strukturierte beziehungsweise serialisierte Daten speichern. Ein ungeeignetes Ersetzen kann diese Daten beschädigen.

Verwende deshalb geeignete WordPress-Werkzeuge und erstelle vor umfangreichen Änderungen ein Backup.

Fehler 6: Weiterleitungsschleife nach HTTPS-Umstellung #

Eine fehlerhafte HTTPS-Konfiguration kann eine Redirect-Schleife erzeugen.

Beispielsweise:

HTTP
 ↓
HTTPS
 ↓
HTTP
 ↓
HTTPS
 ↓
...

Der Browser beendet die Weiterleitung nach einer gewissen Anzahl von Schritten und meldet einen Fehler.

Die Ursache kann an unterschiedlichen Stellen liegen:

Webserver-Konfiguration

.htaccess

WordPress

Plugin

Reverse Proxy

CDN

Load Balancer

Mehrere HTTPS-Weiterleitungen gleichzeitig vermeiden #

Probleme entstehen häufig, wenn mehrere Ebenen unabhängig voneinander versuchen, HTTPS zu erzwingen.

Beispielsweise:

CDN erzwingt HTTPS

Webserver erzwingt HTTPS

WordPress-Plugin erzwingt HTTPS

zusätzliche .htaccess-Regel
erzwingt HTTPS

Das muss nicht zwangsläufig einen Fehler verursachen, macht die Konfiguration aber unnötig komplex und erschwert die Diagnose.

HTTPS sollte an einer dafür geeigneten Stelle sauber und nachvollziehbar umgesetzt werden.

Fehler 7: Zu viele Weiterleitungen #

Auch ohne Endlosschleife kann eine unnötig lange Redirect-Kette entstehen.

Beispielsweise:

http://example.com/
 ↓
http://www.example.com/
 ↓
https://www.example.com/
 ↓
https://www.example.com/de/

Wenn technisch möglich, sollten unnötige Zwischenschritte vermieden werden.

Eine saubere Konfiguration leitet eine alte Variante möglichst direkt auf die endgültige Ziel-URL.

Fehler 8: HTTPS funktioniert nur mit oder ohne www #

Wenn:

https://example.com

funktioniert, aber:

https://www.example.com

eine Zertifikatswarnung erzeugt, sollte geprüft werden:

Existiert der DNS-Eintrag?

Zeigt er auf die richtige Infrastruktur?

Ist der Hostname im Zertifikat enthalten?

Ist der Webserver für diesen Host konfiguriert?

Ist die Weiterleitung korrekt?

Ein Zertifikat kann nur sinnvoll für einen Hostnamen bereitgestellt werden, wenn die gesamte Domain- und Serverkonfiguration dazu passt.

DNS und SSL hängen bei der Ausstellung zusammen #

Bei vielen automatisierten Zertifikatsverfahren muss nachgewiesen werden, dass die Domain beziehungsweise der Hostname kontrolliert wird.

Wenn die Domain auf eine falsche Infrastruktur zeigt, kann eine automatische Ausstellung oder Erneuerung deshalb scheitern.

Bei Problemen solltest du die DNS-Auflösung kontrollieren. Wie das funktioniert, erklären wir unter DNS-Einträge prüfen.

DNS-Änderung und Zertifikat nicht verwechseln #

Nach einem Serverwechsel können zwei getrennte Vorgänge beteiligt sein:

DNS
→ Besucher müssen den
  richtigen Server erreichen

TLS
→ dieser Server muss ein
  gültiges Zertifikat ausliefern

Ein korrektes Zertifikat auf dem neuen Server hilft nicht, wenn ein Besucher aufgrund seiner DNS-Auflösung noch einen anderen Server erreicht.

Umgekehrt kann die Domain bereits auf dem neuen Server ankommen, während dort noch kein passendes Zertifikat installiert wurde.

Fehler 9: Falsches Zertifikat wird ausgeliefert #

Ein Server kann mehrere Websites und Zertifikate verwalten.

Bei einer fehlerhaften virtuellen Host-Konfiguration kann für eine Domain unter Umständen ein Zertifikat einer anderen Website ausgeliefert werden.

Das erkennst du daran, dass der aufgerufene Hostname nicht zu den Namen im ausgelieferten Zertifikat passt.

In diesem Fall muss nicht der Browser repariert werden, sondern die Zertifikats- beziehungsweise Webserver-Konfiguration.

Fehler 10: Zertifikat erneuert, Browser zeigt trotzdem altes Zertifikat #

Wenn ein Zertifikat erneuert wurde, aber weiterhin das alte Zertifikat ausgeliefert wird, können unterschiedliche Ursachen bestehen.

Beispielsweise:

Webserver verwendet noch
alte Zertifikatsdatei

Dienst wurde nach Änderung
nicht korrekt neu geladen

Reverse Proxy liefert
anderes Zertifikat

CDN terminiert TLS

DNS zeigt auf
anderen Server

Entscheidend ist deshalb nicht nur, welches Zertifikat irgendwo auf dem Server gespeichert ist, sondern welches Zertifikat beim tatsächlichen Verbindungsaufbau ausgeliefert wird.

CDN und Reverse Proxy berücksichtigen #

Bei Verwendung eines CDN oder Reverse Proxy kann die TLS-Verbindung an mehreren Stellen stattfinden.

Vereinfacht:

Besucher
   ↓ HTTPS
CDN / Proxy
   ↓ HTTPS
Origin-Server

Damit können auch unterschiedliche Zertifikate beteiligt sein.

Ein gültiges Zertifikat am Origin-Server bedeutet deshalb nicht automatisch, dass das öffentlich ausgelieferte Zertifikat korrekt ist – und umgekehrt.

HTTPS im Browser prüfen #

Für eine erste Diagnose kannst du den Browser verwenden.

Kontrolliere:

aufgerufene URL

Sicherheitsstatus

Zertifikatsinformationen

Hostname

Gültigkeitszeitraum

Aussteller

Konsole

Netzwerk-Anfragen

Bei einem Fehler solltest du die genaue Meldung dokumentieren, statt lediglich „SSL funktioniert nicht“ zu notieren.

Die genaue Fehlermeldung ist entscheidend #

Zwischen folgenden Situationen besteht ein großer Unterschied:

Zertifikat abgelaufen

Hostname stimmt nicht

Zertifikatskette fehlerhaft

Mixed Content

Redirect-Schleife

DNS zeigt falsch

Server nicht erreichbar

Alle können aus Sicht eines Benutzers zunächst wie ein „HTTPS-Problem“ wirken, benötigen aber völlig unterschiedliche Lösungen.

HTTP-Statuscode zusätzlich prüfen #

HTTPS und HTTP-Statuscodes sind unterschiedliche Ebenen.

Eine TLS-Verbindung kann erfolgreich aufgebaut werden und die Website anschließend trotzdem antworten mit:

404 Not Found

500 Internal Server Error

503 Service Unavailable

Dann funktioniert die verschlüsselte Verbindung, während die Anwendung oder der angeforderte Inhalt ein anderes Problem besitzt.

Die wichtigsten Statuscodes erklären wir unter HTTP-Statuscodes erklärt: 200, 301, 404, 403 und 500.

Ein HTTP-500-Fehler ist kein SSL-Fehler #

Wenn der Browser erfolgreich eine HTTPS-Verbindung aufbaut und der Server anschließend mit 500 Internal Server Error antwortet, hat TLS seinen Teil bereits erfolgreich erledigt.

Die Ursache liegt dann typischerweise auf einer späteren Ebene.

DNS
 ↓
TLS erfolgreich
 ↓
HTTP-Anfrage
 ↓
Anwendung
 ↓
500 Internal Server Error

Diese Ebenen sauber auseinanderzuhalten spart bei der Fehlersuche viel Zeit.

Ein DNS-Fehler ist ebenfalls nicht automatisch ein SSL-Fehler #

Kann der Domainname überhaupt nicht aufgelöst werden, erreicht der Browser möglicherweise noch keinen Server, mit dem er eine TLS-Verbindung aufbauen könnte.

Auch wenn die Website im Browser nicht erscheint, liegt dann zunächst ein DNS- beziehungsweise Erreichbarkeitsproblem vor.

HTTPS und Website-Monitoring #

Ein externer HTTPS-Monitor kann regelmäßig prüfen, ob eine sichere Verbindung zur Website aufgebaut und eine erwartete Antwort empfangen werden kann.

Je nach Monitoring-System können auch Zertifikatsprobleme oder ein bevorstehendes Ablaufdatum überwacht werden.

Wie solche Prüfungen grundsätzlich funktionieren, erklären wir unter Website-Monitoring: Erreichbarkeit und Ausfälle überwachen.

Warum Zertifikatsüberwachung sinnvoll ist #

Automatische Zertifikatserneuerung reduziert den administrativen Aufwand erheblich. Trotzdem kann eine Erneuerung aufgrund einer technischen Störung scheitern.

Ein zusätzlicher externer Check kann deshalb helfen, ein unerwartet bevorstehendes Ablaufdatum rechtzeitig zu erkennen.

Monitoring ersetzt allerdings nicht die Behebung der Ursache, wenn die automatische Erneuerung tatsächlich gestört ist.

HTTPS und Google #

Für Suchmaschinen sollten die Signale einer HTTPS-Website konsistent sein.

Wenn HTTPS die gewünschte Variante ist, sollten unter anderem:

interne Links

Weiterleitungen

Canonical-URLs

XML-Sitemap

öffentliche Website-URLs

konsistent auf die HTTPS-Version zeigen.

Die XML-Sitemap sollte entsprechend die gewünschten HTTPS-URLs enthalten. Mehr dazu findest du unter XML-Sitemap: Was sie macht und wie du sie bei Google einreichst.

Canonical nicht auf HTTP zeigen lassen #

Wenn die Website vollständig auf HTTPS umgestellt wurde, sollte eine HTTPS-Seite normalerweise nicht gleichzeitig über ihr Canonical-Element eine HTTP-Version als bevorzugte URL auszeichnen.

Eine solche Konfiguration erzeugt widersprüchliche technische Signale.

Vereinfacht sollte das Bild so aussehen:

HTTP
 ↓ 301
HTTPS
 ↓
Canonical → HTTPS
 ↓
Sitemap → HTTPS
 ↓
interne Links → HTTPS

Nach einer HTTP-zu-HTTPS-Umstellung prüfen #

Wenn eine Website neu auf HTTPS umgestellt wurde, solltest du nicht nur kontrollieren, ob die Startseite ein Zertifikat besitzt.

Prüfe systematisch:

HTTPS-Startseite erreichbar?

HTTP → HTTPS?

Unterseiten korrekt weitergeleitet?

www / non-www korrekt?

Zertifikat für alle
benötigten Hostnamen gültig?

Mixed Content vorhanden?

interne Links auf HTTPS?

Canonical auf HTTPS?

Sitemap enthält HTTPS?

wichtige Seiten in
Search Console prüfen?

HTTPS-Version in Google Search Console kontrollieren #

Mit der URL-Prüfung der Google Search Console kannst du untersuchen, welche URL Google kennt und wie eine konkrete Seite verarbeitet wird.

Bei Problemen mit der Indexierung solltest du HTTPS jedoch nicht isoliert betrachten. Crawlbarkeit, HTTP-Status, Canonical, Sitemap und Indexierungsanweisungen spielen ebenfalls eine Rolle.

Den systematischen Ablauf findest du unter Google indexiert meine Website nicht: Ursachen prüfen.

Mixed Content und SEO nicht überdramatisieren #

Mixed Content sollte behoben werden, vor allem aus Sicherheits-, Funktions- und Qualitätsgründen.

Es ist jedoch wenig hilfreich, jeden HTTPS-Fehler pauschal als „SEO-Katastrophe“ zu bezeichnen.

Die tatsächlichen Auswirkungen hängen davon ab, welcher Fehler vorliegt und welche Ressourcen beziehungsweise URLs betroffen sind.

Technische Probleme sollten deshalb anhand ihrer realen Ursache behoben werden und nicht aufgrund übertriebener SEO-Versprechen.

HTTPS macht eine Website nicht automatisch sicher #

Dieser Unterschied ist besonders wichtig.

HTTPS schützt die Datenübertragung zwischen Client und Server.

Es schützt eine Website aber nicht automatisch vor:

unsicheren Passwörtern

veralteten Plugins

Schadsoftware

SQL-Injection

gestohlenen Zugangsdaten

unsicheren Benutzerkonten

Dateimanipulation

Anwendungsfehlern

Wichtig: Ein gültiges SSL-Zertifikat bedeutet, dass eine verschlüsselte Verbindung zu dem bestätigten Hostnamen hergestellt werden kann. Es ist kein allgemeines Sicherheitszertifikat für die gesamte Website.

Auch eine gehackte Website kann ein gültiges Zertifikat besitzen #

Ein kompromittierter Webserver kann weiterhin ein vollkommen gültiges TLS-Zertifikat ausliefern.

Der Browser kann dann eine technisch verschlüsselte Verbindung herstellen, obwohl die Website selbst manipuliert wurde.

HTTPS und Anwendungssicherheit müssen deshalb getrennt betrachtet werden.

HTTPS schützt nicht vor einer falschen Website #

Ein gültiges Zertifikat bestätigt in erster Linie die Verbindung zum im Zertifikat enthaltenen Hostnamen. Es bestätigt nicht, dass ein Unternehmen, Angebot oder Inhalt automatisch vertrauenswürdig ist.

Auch betrügerische Websites können HTTPS verwenden.

Besucher sollten deshalb weiterhin die tatsächliche Domain und den Kontext einer Website beachten.

Was tun bei einer Browserwarnung? #

Wenn dein Browser vor einer Zertifikats- oder HTTPS-Verbindung warnt, solltest du die Warnung nicht einfach dauerhaft umgehen.

Bei deiner eigenen Website empfiehlt sich folgende Diagnose:

genaue Fehlermeldung notieren
        ↓
Hostname kontrollieren
        ↓
Zertifikat ansehen
        ↓
Gültigkeitszeitraum prüfen
        ↓
SAN / Hostname prüfen
        ↓
Zertifikatskette prüfen
        ↓
DNS-Auflösung kontrollieren
        ↓
Proxy / CDN berücksichtigen
        ↓
Serverkonfiguration prüfen

Browser-Cache nicht vorschnell verantwortlich machen #

Bei HTTPS-Problemen wird häufig zuerst empfohlen, den Browser-Cache zu löschen.

Das kann in bestimmten Situationen hilfreich sein, sollte aber keine eigentliche Diagnose ersetzen.

Wenn das öffentlich ausgelieferte Zertifikat abgelaufen oder für den falschen Hostnamen ausgestellt ist, wird das Problem durch das Löschen des normalen Website-Caches nicht behoben.

Problem auf mehreren Geräten prüfen #

Wenn nur ein einzelnes Gerät eine Zertifikatswarnung zeigt, während andere aktuelle Geräte problemlos funktionieren, solltest du auch die lokale Umgebung untersuchen.

Mögliche Faktoren sind:

falsche Systemzeit

veraltetes Betriebssystem

veralteter Browser

lokaler Proxy

Antivirus-Software

Unternehmensnetzwerk

lokaler Zertifikatsspeicher

Wenn dagegen zahlreiche unabhängige Geräte dieselbe Warnung erhalten, spricht das stärker für ein server- oder zertifikatsseitiges Problem.

Fehler nur in einem Netzwerk #

Funktioniert HTTPS über Mobilfunk, aber nicht im Firmen- oder Heimnetzwerk, können zusätzlich lokale Netzwerkkomponenten beteiligt sein.

Beispielsweise:

Proxy

Firewall

DNS-Resolver

TLS-Inspection

VPN

lokaler Filter

Ein solcher Test hilft dabei, die Ursache räumlich einzugrenzen.

Systemzeit kontrollieren #

Zertifikate besitzen einen definierten Gültigkeitszeitraum.

Ist Datum oder Uhrzeit eines Geräts deutlich falsch, kann ein Browser ein gültiges Zertifikat als ungültig bewerten.

Bei unerklärlichen Zertifikatswarnungen auf nur einem Gerät gehört die Systemzeit deshalb zu den einfachen ersten Kontrollen.

Fehler nach einem Website-Umzug #

Nach einem Hosting- oder Serverwechsel können HTTPS-Probleme entstehen, wenn einzelne Bestandteile der Umstellung noch nicht zusammenpassen.

Prüfe insbesondere:

DNS zeigt auf neuen Server?

Zertifikat auf neuem Server vorhanden?

alle benötigten Hostnamen enthalten?

HTTP-Weiterleitungen korrekt?

alte HTTP-URLs in Website?

CDN / Proxy aktualisiert?

Sitemap und Canonical korrekt?

DNS-Änderungen können außerdem Zeit benötigen, bis unterschiedliche Resolver den neuen Zustand verwenden. Mehr dazu erklären wir unter DNS-Propagation erklärt.

Fehler nach Änderung der Domain #

Wenn eine Website von:

https://alte-domain.ch

auf:

https://neue-domain.ch

umzieht, benötigt die neue Domain ein passendes Zertifikat.

Auch die alte Domain sollte während der Migration weiterhin technisch erreichbar sein, damit Weiterleitungen zur neuen Domain funktionieren können.

Ein Zertifikatsfehler auf der alten HTTPS-Domain kann Besucher treffen, bevor überhaupt eine HTTP-Weiterleitung verarbeitet werden kann.

Warum HTTPS vor einer Weiterleitung funktionieren muss #

Das ist ein häufig übersehener technischer Punkt.

Ein Besucher ruft beispielsweise auf:

https://alte-domain.ch/seite

Bevor der Webserver eine Antwort wie:

301 Moved Permanently

senden kann, muss zunächst die TLS-Verbindung zur alten Domain aufgebaut werden.

Ist deren Zertifikat ungültig, kann der Browser bereits vorher eine Sicherheitswarnung anzeigen.

Praxis-Tipp: Lass bei einer Domainmigration das Zertifikat der alten HTTPS-Domain nicht vorschnell auslaufen. Die alten URLs müssen noch sicher erreichbar sein, damit ihre Weiterleitungen zuverlässig verarbeitet werden können.

SSL-Zertifikat und E-Mail nicht verwechseln #

Ein Zertifikat für die Website unter:

https://www.example.com

ist nicht automatisch die gesamte TLS-Konfiguration aller anderen Dienste der Domain.

E-Mail-Dienste wie IMAP oder SMTP können andere Hostnamen und eigene TLS-Verbindungen verwenden.

Ein funktionierendes HTTPS-Zertifikat der Website beweist deshalb nicht automatisch, dass sämtliche E-Mail-Dienste korrekt konfiguriert sind.

HTTPS-Fehler systematisch eingrenzen #

Eine gute Diagnose folgt einer festen Reihenfolge.

Domain aufrufen
        ↓
DNS funktioniert?
        ↓
Server erreichbar?
        ↓
TLS-Verbindung möglich?
        ↓
Zertifikat gültig?
        ↓
Hostname korrekt?
        ↓
Zertifikatskette korrekt?
        ↓
HTTP-Antwort korrekt?
        ↓
Weiterleitungen korrekt?
        ↓
Mixed Content?
        ↓
Anwendung funktioniert?

Damit vermeidest du, Probleme auf der falschen Ebene zu suchen.

Typische SSL- und HTTPS-Fehler #

Zertifikat abgelaufen

Zertifikat noch nicht gültig

Hostname stimmt nicht

www nicht abgedeckt

Subdomain nicht abgedeckt

Zertifikatskette unvollständig

falsches Zertifikat ausgeliefert

Mixed Content

HTTP leitet nicht auf HTTPS

Redirect-Schleife

unnötige Redirect-Kette

DNS zeigt auf falschen Server

CDN liefert anderes Zertifikat

alte HTTP-URLs nach Migration

Canonical zeigt auf HTTP

Sitemap enthält alte HTTP-URLs

alte Domain verliert Zertifikat
vor Abschluss der Migration

Checkliste: SSL und HTTPS prüfen #

https:// direkt aufrufen
        ↓
Browserwarnung vorhanden?
        ↓
Zertifikat öffnen
        ↓
Gültigkeitszeitraum prüfen
        ↓
Hostname / SAN prüfen
        ↓
Zertifikatskette prüfen
        ↓
http:// aufrufen
        ↓
Weiterleitung auf HTTPS prüfen
        ↓
www und non-www prüfen
        ↓
wichtige Unterseiten prüfen
        ↓
Browser-Konsole öffnen
        ↓
Mixed Content suchen
        ↓
HTTP-Status prüfen
        ↓
DNS-Auflösung prüfen
        ↓
CDN / Proxy berücksichtigen
        ↓
interne Links prüfen
        ↓
Canonical prüfen
        ↓
XML-Sitemap prüfen
        ↓
externes Monitoring kontrollieren

Zusammenfassung #

Ein funktionierendes HTTPS-Setup besteht aus mehr als einem installierten SSL-Zertifikat. Domain, DNS, Zertifikat, Webserver, Weiterleitungen und die von der Website geladenen Ressourcen müssen zusammenpassen.

Bei einem Zertifikatsfehler solltest du zunächst prüfen, ob das Zertifikat zeitlich gültig ist und zum aufgerufenen Hostnamen passt. Anschließend können Zertifikatskette, DNS-Auflösung, Serverkonfiguration sowie gegebenenfalls CDN oder Reverse Proxy untersucht werden.

Mixed Content ist ein anderes Problem: Hier funktioniert HTTPS grundsätzlich, die sichere Seite versucht jedoch einzelne Ressourcen über HTTP zu laden. Solche Referenzen sollten an ihrer eigentlichen Quelle korrigiert werden.

Bei einer vollständig auf HTTPS umgestellten Website sollten HTTP-Varianten sauber auf HTTPS weiterleiten. Interne Links, Canonical-URLs und XML-Sitemaps sollten ebenfalls konsistent die gewünschten HTTPS-Adressen verwenden.

Besondere Vorsicht ist bei Domain- und Servermigrationen erforderlich. Auch die alte Domain benötigt während einer HTTPS-Migration weiterhin ein gültiges Zertifikat, wenn Besucher sichere alte URLs aufrufen und anschließend per Redirect weitergeleitet werden sollen.

HTTPS darf außerdem nicht mit vollständiger Website-Sicherheit verwechselt werden. Eine verschlüsselte Verbindung schützt die Datenübertragung, verhindert aber keine Sicherheitslücken in WordPress, Plugins, Anwendungen oder Benutzerkonten.

Bei HTTPS-Problemen ist deshalb die genaue Fehlermeldung wichtiger als die pauschale Aussage „SSL funktioniert nicht“. Wer DNS, TLS, HTTP und Anwendung als getrennte Ebenen betrachtet, findet die tatsächliche Ursache wesentlich schneller.