So beheben Sie den Fehler „Diese Website kann keine sichere Verbindung bereitstellen”

Der Fehler "Diese Website kann keine sichere Verbindung bereitstellen" bedeutet, dass Ihr Browser den TLS-Handshake mit dem Zielserver nicht abschließen konnte. Der Verbindungsversuch wurde abgebrochen, bevor ein verschlüsselter Kanal aufgebaut werden konnte, sodass der Browser weder die Identität des Servers überprüfen noch eine Cipher Suite aushandeln konnte.

Dieser Fehler tritt in Chrome, Firefox, Edge und Safari auf und wird fast immer von einem spezifischen Fehlercode begleitet – am häufigsten ERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCH oder SSL_ERROR_HANDSHAKE_FAILURE_ALERT. Jeder Code verweist auf eine bestimmte Fehlerquelle: die Zertifikatskonfiguration des Servers, den TLS-Stack des Clients oder den Netzwerkpfad zwischen beiden. Die Identifizierung der verantwortlichen Schicht, bevor Einstellungen geändert werden, spart erheblich Zeit.

Was während eines TLS-Handshakes tatsächlich passiert

Bevor wir uns den Lösungen widmen, ist es wichtig, den Fehlermechanismus zu verstehen. Wenn Ihr Browser eine Verbindung zu einer HTTPS-Website herstellt, führt er in Millisekunden einen TLS-Handshake durch:

1. Der Browser sendet eine ClientHello-Nachricht, in der er die unterstützten TLS-Versionen und Cipher Suites ankündigt.
2. Der Server antwortet mit einem ServerHello, wählt eine Protokollversion und eine Cipher aus und präsentiert dann seine Zertifikatskette.
3. Der Browser validiert das Zertifikat anhand vertrauenswürdiger Root-Zertifizierungsstellen (CAs), prüft das Ablaufdatum, verifiziert, ob die Domain mit dem Subject Alternative Name (SAN) übereinstimmt, und bestätigt, dass das Zertifikat nicht widerrufen wurde (über OCSP oder CRL).
4. Beide Seiten leiten Sitzungsschlüssel ab und beginnen mit der verschlüsselten Kommunikation.

Ein Fehler in einem dieser vier Schritte erzeugt die Meldung "Keine sichere Verbindung möglich". Der Fehlercode im Detailbereich des Browsers zeigt genau an, welcher Schritt fehlgeschlagen ist.

Ursachen nach Fehlercodes geordnet

Wenn der Fehlercode die Verantwortung beim Serveradministrator sieht und Sie den Server nicht kontrollieren, sind Ihre Möglichkeiten auf die Kontaktaufnahme mit dem Website-Betreiber beschränkt. Die folgenden Abschnitte konzentrieren sich auf Fehler, die Sie auf der Client-Seite beheben können, gefolgt von serverseitigen Maßnahmen für Administratoren.

Clientseitige Lösungen

1. Zertifikat prüfen, bevor Änderungen vorgenommen werden

Klicken Sie auf das Schloss-Symbol (oder das Warnsymbol) in der Adressleiste und wählen Sie Verbindung ist sicher > Zertifikat ist gültig. Prüfen Sie:

• Gültigkeitszeitraum: Das Datum unter „Nicht nach” muss in der Zukunft liegen.
• Ausgestellt für: Die Domain im SAN-Feld des Zertifikats muss exakt mit der URL übereinstimmen, einschließlich Subdomains.
• Ausgestellt von: Die CA-Kette muss bei einer Root-CA enden, der Ihr Betriebssystem vertraut.

Wenn das Zertifikat abgelaufen oder nicht übereinstimmend ist und Sie den Server nicht besitzen, hören Sie hier auf und kontaktieren Sie den Website-Betreiber. Wenn Sie den Server verwalten, springen Sie zum serverseitigen Abschnitt weiter unten.

2. Systemdatum und -uhrzeit synchronisieren

Die Zertifikatsvalidierung ist zeitkritisch. Eine Systemuhr, die auch nur wenige Minuten falsch geht, kann dazu führen, dass der Browser ein gültiges Zertifikat als abgelaufen einstuft oder ein noch nicht gültiges Zertifikat als vorzeitig verwendet betrachtet.

Windows:

w32tm /resync /force

Alternativ klicken Sie mit der rechten Maustaste auf die Systemuhr, wählen Datum/Uhrzeit anpassen und aktivieren Uhrzeit automatisch festlegen mit dem Windows-Zeitdienst.

Linux (systemd):

timedatectl set-ntp true
timedatectl status

macOS: Öffnen Sie Systemeinstellungen > Allgemein > Datum & Uhrzeit und aktivieren Sie Datum und Uhrzeit automatisch festlegen.

Starten Sie nach der Synchronisierung den Browser neu und testen Sie erneut.

3. SSL-Status und Cache des Browsers leeren

Browser speichern Ergebnisse der Zertifikatsvalidierung und HSTS-Richtlinien (HTTP Strict Transport Security) im Cache. Ein veralteter Cache-Eintrag kann den Zugriff blockieren, selbst nachdem ein serverseitiges Zertifikatsproblem behoben wurde.

Chrome — Browserdaten löschen:

Navigieren Sie zu chrome://settings/clearBrowserData, wählen Sie Gesamte Zeit, aktivieren Sie Cookies und andere Websitedaten sowie Bilder und Dateien im Cache und klicken Sie dann auf Daten löschen.

Chrome — HSTS-Eintrag für eine bestimmte Domain löschen:

Navigieren Sie zu chrome://net-internals/#hsts, geben Sie die Domain unter Sicherheitsrichtlinien für Domain löschen ein und klicken Sie auf Löschen. Dies ist besonders nützlich, wenn eine Domain zuvor nur über HTTPS erreichbar war und jetzt falsch konfiguriert ist.

Windows — SSL-Status auf Betriebssystemebene löschen:

Control Panel > Network and Internet > Internet Options > Content tab > Clear SSL State

Dadurch wird der Zertifikatscache geleert, der von Internet Explorer, Edge (Legacy) und einigen Windows-Anwendungen verwendet wird.

Firefox: Navigieren Sie zu about:preferences#privacy, scrollen Sie zu Cookies und Website-Daten und klicken Sie auf Daten löschen.

4. HTTPS-Inspektion des Antivirenprogramms deaktivieren

Sicherheitsprodukte von Anbietern wie Avast, AVG, Kaspersky, ESET und Bitdefender führen eine SSL/TLS-Interception durch – sie fungieren als lokaler Man-in-the-Middle-Proxy und signieren Zertifikate mit ihrer eigenen Root-CA neu. Wenn ihre Root-CA nicht ordnungsgemäß im Vertrauensspeicher des Browsers installiert ist oder das Interception-Modul fehlerhaft ist, schlägt jede HTTPS-Verbindung fehl.

So testen Sie, ob dies die Ursache ist:

1. Deaktivieren Sie vorübergehend den Web Shield, das HTTPS-Scanning oder die SSL-Filterung in den Einstellungen Ihres Antivirenprogramms.
2. Laden Sie die fehlerhafte Seite neu.
3. Wenn der Fehler verschwindet, ist das Antivirenprogramm die Ursache.

Die dauerhafte Lösung besteht darin, die betroffene Domain zur Ausschlussliste des Antivirenprogramms hinzuzufügen, anstatt das HTTPS-Scanning global zu deaktivieren, was Ihre Sicherheit verringern würde.

5. Browser aktualisieren

Modernes TLS erfordert Browser-Unterstützung für mindestens TLS 1.2 und TLS 1.3 für optimale Sicherheit. Browser, die älter als ungefähr Chrome 70, Firefox 63 oder Edge 79 sind, unterstützen möglicherweise kein TLS 1.3 oder haben bekannte Handshake-Fehler.

Chrome:

Navigieren Sie zu chrome://settings/help. Chrome sucht automatisch nach Updates und installiert diese beim Neustart.

Firefox:

Navigieren Sie zu about:support und klicken Sie dann unter dem Hilfe-Menü auf Nach Updates suchen.

Durch die Aktualisierung des Browsers wird auch sichergestellt, dass der integrierte Root-CA-Speicher des Browsers aktuell ist, was bei Zertifikaten neuerer CAs wichtig ist.

6. TLS-Protokolleinstellungen im Browser prüfen

Chrome und Edge (Chromium-basiert):

Diese Browser bieten seit Chrome 84 keine TLS-Versionsschalter in der Benutzeroberfläche mehr an. TLS 1.0 und 1.1 sind dauerhaft deaktiviert. Wenn eine Website TLS 1.0 oder 1.1 erfordert, muss die Website aktualisiert werden – es gibt keine clientseitige Umgehungslösung, und das sollte auch so bleiben.

Um nach experimentellen TLS-Flags zu suchen, navigieren Sie zu chrome://flags und suchen Sie nach TLS. In den meisten Produktions-Builds werden keine umsetzbaren Flags angezeigt.

Firefox:

Navigieren Sie zu about:config und suchen Sie nach security.tls.version.min. Der Wert sollte 3 sein (entspricht TLS 1.2). Das Setzen auf 1 oder 2, um einen defekten Server zu unterstützen, ist ein Sicherheitsrisiko und sollte nur in isolierten Testumgebungen durchgeführt werden.

Internet Explorer / Legacy Edge:

Navigieren Sie zu Internetoptionen > Erweitert > Sicherheit und stellen Sie sicher, dass TLS 1.2 verwenden und TLS 1.3 verwenden aktiviert sind. Deaktivieren Sie SSL 3.0 verwenden, TLS 1.0 verwenden und TLS 1.1 verwenden.

7. Browser-Erweiterungen deaktivieren oder prüfen

Erweiterungen mit Netzwerkzugriff – insbesondere VPNs, Werbeblocker, Datenschutz-Tools und Proxy-Switcher – können TLS-Verbindungen abfangen oder verändern. Um einen Erweiterungskonflikt zu isolieren:

Navigieren Sie zu chrome://extensions/ und deaktivieren Sie alle Erweiterungen. Laden Sie die fehlerhafte Seite neu. Wenn der Fehler behoben ist, aktivieren Sie die Erweiterungen nacheinander wieder und laden Sie nach jeder Aktivierung neu, bis die problematische Erweiterung identifiziert ist.

8. DNS-Resolver ändern

DNS beeinflusst TLS nicht direkt, aber ein DNS-Resolver, der falsche IP-Adressen zurückgibt (aufgrund von Poisoning, Filterung oder ISP-Eingriff), kann Ihren Browser zu einem Server leiten, der ein Zertifikat für die falsche Domain präsentiert, was einen ERR_CERT_COMMON_NAME_INVALID-Fehler verursacht.

Der Wechsel zu einem öffentlichen Resolver eliminiert DNS-Manipulation auf ISP-Ebene:

Windows — DNS über PowerShell ändern:

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("1.1.1.1","1.0.0.1")

Ersetzen Sie "Ethernet" durch Ihren tatsächlichen Schnittstellennamen (verwenden Sie Get-NetAdapter zum Auflisten der Schnittstellen).

Linux:

sudo nano /etc/resolv.conf

Fügen Sie hinzu:

nameserver 1.1.1.1
nameserver 8.8.8.8

Empfohlene öffentliche Resolver:

9. Netzwerk-Stack zurücksetzen (Windows)

Ein beschädigter Winsock-Katalog oder TCP/IP-Stack kann zu intermittierenden TLS-Fehlern führen, die scheinbar nichts mit Zertifikaten zu tun haben. Führen Sie Folgendes als Administrator aus:

netsh int ip reset
netsh winsock reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

Starten Sie den Computer nach Ausführung aller fünf Befehle neu. Überspringen Sie den Neustart nicht – netsh winsock reset erfordert insbesondere einen Neustart, um wirksam zu werden.

Serverseitige Lösungen für Administratoren

Wenn Sie den Webserver verwalten, der das Zertifikat präsentiert, sind die folgenden die häufigsten serverseitigen Ursachen und deren Behebung.

Abgelaufenes oder falsch konfiguriertes SSL-Zertifikat

Ein abgelaufenes Zertifikat ist die häufigste Ursache dieses Fehlers auf Serverebene. Wenn Sie eine Website in einer VPS Hosting-Umgebung betreiben, sollte die Zertifikatserneuerung automatisiert sein.

Zertifikatsablauf über die Befehlszeile prüfen:

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates

Erneuerung mit Certbot (Let's Encrypt) automatisieren:

sudo certbot renew --dry-run

Fügen Sie einen Cron-Job oder systemd-Timer hinzu, um certbot renew zweimal täglich auszuführen – Let's Encrypt-Zertifikate laufen alle 90 Tage ab, und Certbot erneuert nur, wenn weniger als 30 Tage verbleiben.

0 0,12 * * * root certbot renew --quiet

Wenn Sie ein kommerziell validiertes Zertifikat mit erweiterter Validierung oder Wildcard-Abdeckung benötigen, bieten SSL-Zertifikate von einer vertrauenswürdigen CA die erforderliche Vertrauenskette für alle gängigen Browser.

Unvollständige Zertifikatskette

Eine sehr häufige Fehlkonfiguration: Der Server präsentiert nur das End-Entity-Zertifikat ohne die Zwischen-CA-Zertifikate. Der Browser kann keinen Vertrauenspfad zu einer Root-CA aufbauen, die er kennt, was zu ERR_CERT_AUTHORITY_INVALID führt.

Diagnose mit SSL Labs:

Führen Sie Ihre Domain durch den SSL Labs Server Test (externes Tool). Ein Kettenproblem wird sofort erkannt.

Behebung auf Nginx:

Die ssl_certificate-Direktive muss auf eine Datei verweisen, die die vollständige Kette enthält – Ihr Zertifikat gefolgt von allen Zwischen-Zertifikaten:

cat your_domain.crt intermediate.crt > fullchain.crt

ssl_certificate /etc/nginx/ssl/fullchain.crt;
ssl_certificate_key /etc/nginx/ssl/your_domain.key;

Behebung auf Apache:

SSLCertificateFile /etc/apache2/ssl/your_domain.crt
SSLCertificateKeyFile /etc/apache2/ssl/your_domain.key
SSLCertificateChainFile /etc/apache2/ssl/intermediate.crt

Veraltete TLS-Versionen und schwache Cipher Suites

Browser haben die Unterstützung für TLS 1.0 und TLS 1.1 entfernt. Wenn Ihr Server nur diese Protokollversionen anbietet, werden moderne Browser die Verbindung vollständig verweigern.

Empfohlene Nginx TLS-Konfiguration:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_stapling on;
ssl_stapling_verify on;

Empfohlene Apache TLS-Konfiguration:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off

Testen Sie nach der Änderung der Serverkonfiguration mit:

openssl s_client -connect yourdomain.com:443 -tls1_2
openssl s_client -connect yourdomain.com:443 -tls1_3

Zertifikatsdomain-Nichtübereinstimmung

Wenn Ihr Zertifikat www.example.com abdeckt, Benutzer jedoch auf example.com zugreifen (oder umgekehrt), meldet der Browser eine Domain-Nichtübereinstimmung. Die korrekte Lösung besteht darin, ein Zertifikat mit beiden Namen im SAN-Feld auszustellen oder ein Wildcard-Zertifikat (*.example.com) zu verwenden.

Wenn Sie eine neue Domain in einer Dedicated Servers-Umgebung einrichten, überprüfen Sie immer, ob das SAN-Feld alle Hostname-Varianten abdeckt, auf die der Server antworten wird, bevor Sie live gehen.

Blockierung gemischter Inhalte

Eine über HTTPS geladene Seite, die auf HTTP-Ressourcen (Bilder, Skripte, Stylesheets) verweist, löst Warnungen zu gemischten Inhalten aus. Obwohl dies nicht direkt den Fehler „Keine sichere Verbindung möglich” erzeugt, kann es zu partiellen Seitenfehlern führen, die fälschlicherweise als TLS-Fehler diagnostiziert werden.

Prüfen Sie gemischte Inhalte mit:

curl -s https://yourdomain.com | grep -Eo 'src="http://[^"]*"|href="http://[^"]*"'

Vergleich clientseitiger und serverseitiger Ursachen

Überlegungen zur Hosting-Umgebung

Die von Ihnen betriebene Hosting-Umgebung beeinflusst direkt, wie einfach Sie serverseitige TLS-Probleme beheben können.

Bei Shared Web Hosting wird die Zertifikatsverwaltung in der Regel über das Kontrollpanel abgewickelt. Die meisten modernen Shared-Hosting-Plattformen bieten eine kostenlose Let's Encrypt-Integration, aber Sie haben nur begrenzte Kontrolle über die serverweiten TLS-Protokolleinstellungen.

Auf einem VPS mit cPanel erhalten Sie Zugang zu AutoSSL für die automatisierte Zertifikatsbereitstellung und können Apache- oder Nginx-TLS-Einstellungen direkt konfigurieren. Dies ist die empfohlene Umgebung für Websites, bei denen die Präzision der TLS-Konfiguration wichtig ist.

Auf Bare-Metal-Dedicated Servers haben Sie die vollständige Kontrolle über den gesamten TLS-Stack – OpenSSL-Version, Cipher-Suite-Auswahl, OCSP-Stapling, HSTS-Preloading und Certificate Pinning – sind aber auch vollständig dafür verantwortlich, die Konfiguration aktuell zu halten.

Praktische Entscheidungs-Checkliste

Verwenden Sie diese Checkliste, um den Fehler systematisch zu analysieren, anstatt Lösungen wahllos anzuwenden:

• Tritt der Fehler auf allen HTTPS-Websites oder nur auf einer auf?
• Alle Websites: Konzentrieren Sie sich auf Systemuhr, Antivirus-HTTPS-Scanning, Browser-Update, OS-Root-CA-Speicher.
• Eine Website: Das Problem ist fast sicher serverseitig.

• Was sagt der spezifische Fehlercode?
• ERR_CERT_DATE_INVALID: Prüfen Sie zuerst die Systemuhr, dann den Zertifikatsablauf.
• ERR_CERT_AUTHORITY_INVALID: Prüfen Sie die Vollständigkeit der Zertifikatskette.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH: Server verwendet veraltetes TLS oder nicht unterstützte Ciphers.
• ERR_CERT_COMMON_NAME_INVALID: Zertifikats-SAN stimmt nicht mit der Domain überein.

• Verschwindet der Fehler in einem anderen Netzwerk?
• Ja: Firewall, Proxy oder TLS-Inspektion auf ISP-Ebene ist die Ursache.

• Verschwindet der Fehler bei deaktiviertem Antivirenprogramm?
• Ja: Konfigurieren Sie eine Ausnahme für die Domain in den HTTPS-Scanning-Einstellungen des Antivirenprogramms.

• Sind Sie der Serveradministrator?
• Führen Sie openssl s_client-Diagnosen und den SSL Labs-Test durch, bevor Sie Konfigurationsdateien ändern.
• Automatisieren Sie die Zertifikatserneuerung unmittelbar nach der Behebung des unmittelbaren Problems.

FAQ

Warum erscheint „Diese Website kann keine sichere Verbindung bereitstellen” nur auf einer Website?

Wenn der Fehler auf eine einzelne Domain beschränkt ist, liegt die Ursache fast immer auf der Serverseite: ein abgelaufenes Zertifikat, eine unvollständige Zertifikatskette, eine Domain-Nichtübereinstimmung im SAN-Feld des Zertifikats oder ein Server, der so konfiguriert ist, dass er nur veraltete TLS-Versionen (1.0 oder 1.1) verwendet, die moderne Browser nicht mehr akzeptieren.

Kann ein VPN diesen Fehler verursachen?

Ja. Einige VPN-Clients leiten DNS-Anfragen über ihre eigenen Resolver oder führen eine Datenverkehrsinspektion durch, die TLS-Handshakes stört. Wenn der Fehler nur bei aktivem VPN auftritt, deaktivieren Sie die Funktion „Split Tunneling” oder „SSL-Inspektion” des VPNs oder fügen Sie die betroffene Domain als Ausnahme hinzu.

Behebt das Leeren des Caches immer SSL-Fehler?

Nein. Das Leeren des Caches behebt Fehler, die durch veraltete HSTS-Richtlinien oder zwischengespeicherte ungültige Zertifikatsantworten verursacht werden. Es hat keinen Einfluss auf serverseitige Zertifikatsprobleme, Systemuhrprobleme oder Antivirus-Interception. Verwenden Sie das Cache-Leeren als ersten Schritt, nicht als universelle Lösung.

Wie überprüfe ich, ob das SSL-Zertifikat meines Servers korrekt konfiguriert ist, ohne einen Browser zu verwenden?

Verwenden Sie OpenSSL von einem beliebigen Computer mit Netzwerkzugang:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

Die Ausgabe zeigt die vollständige Zertifikatskette, die ausgehandelte TLS-Version, die ausgewählte Cipher Suite und etwaige Verifizierungsfehler. Dies ist die zuverlässigste Diagnosemethode für serverseitige TLS-Probleme.

Was ist der Unterschied zwischen ERR_SSL_PROTOCOL_ERROR und ERR_SSL_VERSION_OR_CIPHER_MISMATCH?

ERR_SSL_PROTOCOL_ERROR zeigt an, dass der Server eine Antwort gesendet hat, die keinem erkannten TLS-Datensatzformat entspricht – oft verursacht durch einen Server, der eine HTTP-Antwort auf Port 443 sendet, einen falsch konfigurierten Load Balancer oder eine Firewall, die die Verbindung mitten im Handshake beendet. ERR_SSL_VERSION_OR_CIPHER_MISMATCH bedeutet, dass der Handshake korrekt begonnen hat, Client und Server sich jedoch nicht auf eine gemeinsam unterstützte TLS-Version oder Cipher Suite einigen konnten, typischerweise weil der Server nur veraltete Protokolle unterstützt.