Das kleine Schloss in der Adresszeile wirkt vertraut, eine Meldung wie „Verbindung nicht privat“ dagegen verunsichert sofort. Beides verweist auf dieselbe technische Grundlage: Der Browser versucht zu klären, ob die Verbindung geschützt aufgebaut werden kann und ob der angesprochene Server zum erwarteten Namen passt.
TLS steht für Transport Layer Security und ist ein Verschlüsselungsprotokoll, das Verbindungen zwischen Anwendungen absichert, etwa zwischen Browser und Webserver. Es ist die Technik hinter HTTPS, kommt aber auch bei der E-Mail-Übertragung, bei APIs oder in Komponenten von VPN-Lösungen vor.
Wichtig ist die Unterscheidung: TLS schützt die Verbindung auf dem Transportweg. Es sagt nicht automatisch, ob eine Webseite seriös ist, ob ein Anbieter vertrauenswürdig handelt oder ob eine Nachricht kein Phishing-Versuch ist. Um Browserwarnungen richtig einzuordnen, müssen daher Verbindungsschutz, Zertifikatsprüfung und allgemeine Vertrauenswürdigkeit getrennt betrachtet werden.
Vom Browser-Schloss zur TLS-Definition: Was die Verbindung schützen soll
Ein Sicherheitssymbol in der Adresszeile signalisiert in der Regel, dass der Browser eine geschützte Verbindung zur aufgerufenen Webseite herstellen konnte. Erscheint stattdessen eine Warnung, ist eine dafür notwendige technische Prüfung fehlgeschlagen. Symbol und Warnung beziehen sich zunächst auf den Verbindungsaufbau – nicht auf die Qualität, Rechtmäßigkeit oder Seriosität der Inhalte.
TLS legt fest, wie zwei Anwendungen eine geschützte Verbindung vereinbaren und Daten anschließend so übertragen, dass Dritte sie auf dem Transportweg nicht ohne Weiteres lesen oder unbemerkt verändern können. Der Schutz setzt voraus, dass das Protokoll korrekt umgesetzt ist und die Prüfung der Gegenstelle erfolgreich bleibt.
TLS ist die technische Grundlage von HTTPS
Beim Aufruf einer Adresse mit https:// wird das Webprotokoll HTTP über eine TLS-geschützte Verbindung übertragen. HTTPS und TLS sind daher eng verbunden, aber nicht bedeutungsgleich: HTTP regelt den Austausch von Webinhalten, während TLS den Transport dieser Daten absichert.
TLS ist nicht auf Webseiten beschränkt. Auch E-Mail-Dienste können damit Verbindungen bei der Übertragung oder beim Abruf von Nachrichten schützen. APIs verwenden TLS beim Datenaustausch über Netzwerke. Ebenso kann das Protokoll in einzelnen Komponenten von VPN-Lösungen und zusammen mit anderen Anwendungsprotokollen eingesetzt werden. Welche Absicherung tatsächlich verwendet wird, hängt vom jeweiligen Dienst und seiner Konfiguration ab.
Die drei zentralen Schutzziele
- Vertraulichkeit: Übertragene Daten werden verschlüsselt. Inhalte wie Passwörter, Nachrichten oder Zahlungsinformationen sollen auf dem Transportweg nicht einfach mitgelesen werden können.
- Integrität: TLS macht unbemerkte Veränderungen während der Übertragung erkennbar. Manipulierte Daten sollen nicht stillschweigend als unveränderte Antwort akzeptiert werden.
- Authentisierung der Gegenstelle: Der Client, beispielsweise der Browser, prüft im Rahmen der Zertifikatsvalidierung, ob er mit dem Server spricht, der zum aufgerufenen Namen gehört.
Diese Ziele beziehen sich auf die Verbindung zwischen den beteiligten Anwendungen. TLS verhindert nicht, dass Schadsoftware Daten vor der Verschlüsselung erfasst oder dass eine berechtigte Anwendung empfangene Informationen unsicher speichert. Auch die Vertrauenswürdigkeit eines Betreibers lässt sich daraus nicht ableiten.
Eine betrügerische Webseite kann für ihre eigene, möglicherweise irreführend benannte Domain ein gültiges Zertifikat besitzen. Die Verbindung zu dieser Domain ist dann technisch geschützt, obwohl das Angebot weiterhin Phishing betreiben kann. Das Sicherheitssymbol ist deshalb kein allgemeines Gütesiegel.
Merksatz: TLS schützt die Verbindung, nicht automatisch den Anbieter oder dessen Inhalte.
Wie der TLS-Handshake funktioniert: Zertifikat, Schlüssel und Vertrauenskette
Bevor Browser und Server geschützte Anwendungsdaten austauschen, führen sie einen TLS-Handshake aus. Dieser „Handschlag“ ist kein einzelner Prüfschritt, sondern ein geordneter Ablauf: Beide Seiten stimmen geeignete Verbindungsparameter ab, der Server legt sein Zertifikat vor, der Browser prüft es und beide Seiten leiten Schlüssel für die Sitzung ab.
Der Ablauf in sechs Schritten
- Der Client beginnt den Verbindungsaufbau. Der Browser teilt mit, welche TLS-Versionen und kryptografischen Parameter er unterstützt. Bei Webservern nennt er in der Regel außerdem den gewünschten Hostnamen, damit der Server die passende Konfiguration auswählen kann.
- Der Server wählt gemeinsame Parameter. Er antwortet mit einer Kombination, die beide Seiten unterstützen. Können sie sich nicht auf akzeptierte Parameter einigen, kommt keine TLS-Sitzung zustande.
- Der Server legt sein Zertifikat vor. Dieses digitale Dokument enthält unter anderem den oder die Namen, für die es gilt, einen öffentlichen Schlüssel, den Gültigkeitszeitraum und Angaben zur ausstellenden Stelle.
- Der Browser validiert das Zertifikat. Er prüft insbesondere, ob der aufgerufene Name erfasst ist, das Zertifikat zeitlich gültig ist und eine akzeptierte Vertrauenskette besitzt. Je nach Verbindung kommen weitere Prüfungen hinzu.
- Beide Seiten leiten Schlüsselmaterial ab. Moderne TLS-Verbindungen handeln gemeinsames Schlüsselmaterial aus und erzeugen daraus Sitzungsschlüssel. Der Server weist dabei nach, dass er über den zum Zertifikat gehörenden privaten Schlüssel verfügt, ohne diesen zu übertragen.
- Die geschützte Sitzung beginnt. Nach erfolgreichem Handshake werden die Anwendungsdaten verschlüsselt und gegen unbemerkte Veränderungen abgesichert übertragen.
Was öffentliche und private Schlüssel leisten
Der öffentliche Schlüssel darf im Zertifikat sichtbar sein. Sein privater Gegenpart muss dagegen geheim bleiben und beim Server beziehungsweise in dessen geschützter Infrastruktur gespeichert werden. Während des Handshakes kann der Server mit dem privaten Schlüssel seinen Schlüsselbesitz nachweisen. Ein Zertifikat allein genügt daher nicht: Zur erfolgreichen Authentisierung gehört auch der Nachweis, dass die Gegenstelle den passenden privaten Schlüssel kontrolliert.
Zertifizierungsstelle und Vertrauenskette
Ein Browser vertraut nicht jedem vorgelegten Zertifikat ungeprüft. Betriebssysteme und Anwendungen führen Vertrauensanker, meist Stammzertifikate bestimmter Zertifizierungsstellen. Das Serverzertifikat kann direkt oder über eine oder mehrere Zwischenstellen auf einen solchen Vertrauensanker zurückgeführt werden. Diese Abfolge bildet die Vertrauenskette.
Eine Zertifizierungsstelle bestätigt mit ihrer Signatur, dass das ausgestellte Zertifikat nach ihren Prüfregeln mit den angegebenen Namen oder Identitätsangaben verbunden wurde. Bei einer Domainvalidierung weist der Antragsteller die Kontrolle über die betreffende Domain nach. Das ist keine inhaltliche Prüfung des Angebots, des Geschäftsmodells oder der Absichten des Betreibers.
Auch der Gültigkeitszeitraum ist begrenzt. Der Browser vergleicht Beginn und Ablaufdatum mit der lokalen Systemzeit. Außerdem prüft er, ob die aufgerufene Domain zu den Namen im Zertifikat gehört. Ein zeitlich gültiges Zertifikat für eine andere Domain besteht diese Namensprüfung nicht.
TLS schützt die Verbindung, während das Zertifikat einen Schlüssel an einen Namen beziehungsweise eine geprüfte Identitätsangabe bindet. Diese Bindung macht eine Webseite jedoch nicht automatisch seriös. Eine Phishing-Seite kann ein gültiges Zertifikat für ihren eigenen irreführenden Domainnamen besitzen.
Browserwarnungen richtig einordnen: Welche Prüfung scheitert und was jetzt sicher ist
Eine TLS- oder Zertifikatswarnung beweist nicht automatisch einen Angriff. Sie bedeutet jedoch, dass der Browser eine wesentliche Prüfung nicht erfolgreich abschließen konnte. Das kann die zeitliche Gültigkeit, den Domainnamen, die Vertrauenskette oder die TLS-Konfiguration betreffen.
Sobald Sie Zugangsdaten, Zahlungsinformationen, Kundendaten oder Angaben für ein Verwaltungsportal übertragen wollen, gilt eine klare Sicherheitsregel: Gehen Sie nicht über die Warnung hinweg, sondern brechen Sie den Vorgang bis zur Klärung ab. Das gilt besonders für Onlinebanking, Shops, geschäftliche Anwendungen und Konten mit weitreichenden Berechtigungen.
Diagnoseworkflow für typische TLS- und Zertifikatsfehler
Der genaue Wortlaut und die Darstellung einer Warnung unterscheiden sich je nach Browser, Betriebssystem und Version. Entscheidend ist daher, welche Prüfung fehlgeschlagen ist. Die folgenden Fehlerbilder führen jeweils von der sichtbaren Beobachtung zu einem sicheren nächsten Schritt.
1. Das Zertifikat ist abgelaufen
Was Sie sehen: Der Browser meldet, dass das Zertifikat nicht mehr gültig oder sein Gültigkeitszeitraum überschritten ist.
Hier scheitert die Prüfung: Der aktuelle Zeitpunkt liegt nach dem im Zertifikat angegebenen Ablaufdatum. Der Browser kann die zeitliche Gültigkeit deshalb nicht bestätigen.
Was dahinterstecken kann: Der Betreiber hat die Erneuerung versäumt, das neue Zertifikat wurde fehlerhaft eingebunden oder ein zwischengeschaltetes System liefert noch ein altes Zertifikat aus. Auch eine deutlich falsche Geräteuhr kann eine ähnliche Meldung auslösen.
Was jetzt sicher ist: Prüfen Sie zunächst Datum, Uhrzeit und Zeitzone des Geräts. Sind diese korrekt, liegt die Behebung in der Regel beim Betreiber oder der zuständigen IT. Geben Sie bis dahin keine sensiblen Daten ein.
Ein abgelaufenes Zertifikat beweist keine Manipulation. Dennoch kann der Browser nicht bestätigen, dass es weiterhin als gültiger Nachweis verwendet werden darf. Vor einer Anmeldung ist das Wegklicken daher riskant.
2. Das Zertifikat nennt eine andere Domain
Was Sie sehen: Der Browser meldet, dass das Zertifikat nicht zur aufgerufenen Adresse passt oder für einen anderen Namen ausgestellt wurde.
Hier scheitert die Prüfung: Der Domainname in der Adresszeile stimmt mit keinem Namen überein, für den das Zertifikat gültig ist. Die Bindung des Schlüssels an die erwartete Gegenstelle lässt sich nicht bestätigen.
Was dahinterstecken kann: Möglich sind ein Tippfehler, ein veralteter Link, eine fehlerhafte Serverkonfiguration oder ein Zertifikat für einen anderen Hostnamen. Ebenso können eine unerwartete Umleitung oder ein zwischengeschaltetes System beteiligt sein.
Was jetzt sicher ist: Kontrollieren Sie die Adresse Zeichen für Zeichen. Öffnen Sie einen bekannten Dienst über eine selbst eingegebene offizielle Adresse, ein geprüftes Lesezeichen oder eine vertrauenswürdige Anwendung neu. Verwenden Sie nicht den Link aus einer verdächtigen Nachricht.
Dieser Fehler ist vor einem Login besonders bedeutsam. Die Verbindung könnte zwar verschlüsselt werden, doch der Browser kann nicht bestätigen, dass sie bei der erwarteten Gegenstelle endet.
3. Das Zertifikat ist selbstsigniert oder nicht vertrauenswürdig
Was Sie sehen: Der Browser bezeichnet den Aussteller als unbekannt, kann die Zertifikatskette nicht verifizieren oder meldet ein selbstsigniertes Zertifikat.
Hier scheitert die Prüfung: Die Vertrauenskette lässt sich nicht bis zu einer vom System anerkannten oder administrativ vorgesehenen Stammzertifizierungsstelle zurückverfolgen. Ein selbstsigniertes Zertifikat besitzt nicht automatisch das Vertrauen des Geräts.
Was dahinterstecken kann: In Testsystemen, lokalen Geräten und internen Netzen werden solche Zertifikate mitunter bewusst eingesetzt. Im öffentlichen Web können auch eine unvollständige Zertifikatskette, eine Fehlkonfiguration oder eine nicht überprüfbare Gegenstelle die Ursache sein.
Was jetzt sicher ist: Auf einer öffentlichen Login-, Banking- oder Shopseite sollten Sie nicht fortfahren. Bei einem internen Dienst klären Sie mit der zuständigen IT, welche Zertifikatsinfrastruktur vorgesehen ist. Installieren Sie keine unbekannten Stammzertifikate aufgrund einer Webseite oder unverlangten Nachricht.
4. Die lokale Systemzeit ist falsch
Was Sie sehen: Mehrere ansonsten bekannte Webseiten melden plötzlich abgelaufene, noch nicht gültige oder zeitlich ungültige Zertifikate.
Hier scheitert die Prüfung: Der Browser vergleicht den Gültigkeitszeitraum des Zertifikats mit der lokalen Systemzeit. Liegt die Geräteuhr vor Beginn oder nach Ende dieses Zeitraums, erscheint das Zertifikat aus Sicht des Geräts ungültig.
Was dahinterstecken kann: Datum, Uhrzeit oder Zeitzone wurden falsch eingestellt. Auch eine gestörte Zeitsynchronisation oder eine ausgefallene interne Uhr kommt infrage.
Was jetzt sicher ist: Vergleichen Sie Datum, Uhrzeit und Zeitzone mit einer vertrauenswürdigen Quelle und verwenden Sie die vorgesehene Systemfunktion zur Korrektur. Laden Sie die Seite danach neu und prüfen Sie, ob die Warnung verschwunden ist.
Ein typischer Praxisfall ist ein länger ausgeschaltetes Notebook, dessen Datum deutlich abweicht. Ein eigentlich gültiges Zertifikat kann dann als „noch nicht gültig“ oder „abgelaufen“ erscheinen. Verschwindet die Warnung nach sicherer Korrektur der Uhrzeit, war die zeitliche Prüfung lokal verfälscht. Bleibt sie bestehen, muss die verbleibende Ursache separat geklärt werden.
5. Browser und Server finden keine akzeptable TLS-Konfiguration
Was Sie sehen: Die Verbindung wird bereits beim Aufbau abgebrochen. Der Browser weist möglicherweise auf eine nicht unterstützte Sicherheitskonfiguration, eine inkompatible Protokollversion oder fehlende gemeinsame Verschlüsselungsparameter hin.
Hier scheitert die Prüfung: Client und Server können sich nicht auf akzeptierte TLS-Parameter einigen. Eine geschützte Sitzung kommt daher nicht zustande.
Was dahinterstecken kann: Der Server unterstützt nur veraltete Protokolle oder ungeeignete Verfahren. Umgekehrt kann ein stark veralteter Browser moderne Vorgaben des Servers nicht erfüllen. Zwischengeschaltete Sicherheitskomponenten können die Aushandlung ebenfalls beeinflussen.
Was jetzt sicher ist: Aktualisieren Sie Browser und Betriebssystem über die vorgesehenen vertrauenswürdigen Wege. Bleibt das Problem bestehen, muss der Betreiber oder die zuständige IT die Konfiguration prüfen. Schutzfunktionen abzuschalten oder veraltete Protokolle zu erzwingen, ist keine sichere Lösung.
6. Ein Unternehmensfilter verändert den Vertrauenspfad
Was Sie sehen: Auf einem verwalteten Arbeitsgerät nennt das Zertifikat möglicherweise eine unternehmenseigene Stelle als Aussteller. Alternativ treten Warnungen nur im Firmennetz oder nur auf einem bestimmten Gerät auf.
Hier scheitert die Prüfung: Falls die unternehmenseigene Stammstelle fehlt, abgelaufen oder nicht korrekt bereitgestellt ist, kann der Browser den veränderten Vertrauenspfad nicht bestätigen.
Was dahinterstecken kann: Manche verwalteten Netze prüfen verschlüsselte Verbindungen über einen administrativ eingerichteten Filter. Dabei endet eine TLS-Verbindung am Filtersystem, während zum Endgerät eine weitere Verbindung mit einem organisationsintern ausgestellten Zertifikat aufgebaut wird.
Was jetzt sicher ist: Klären Sie die Meldung mit der zuständigen IT und nennen Sie die betroffene Adresse, das Gerät und das verwendete Netz. Installieren Sie keine Zertifikatsdatei eigenmächtig. Ob der angezeigte Aussteller vorgesehen ist, muss die Organisation bestätigen.
7. Die Seite enthält Mixed Content
Was Sie sehen: Die Hauptseite wird über HTTPS geladen, einzelne Bilder, Skripte, Schriftarten oder eingebettete Inhalte fehlen jedoch. Der Browser kann zusätzlich auf blockierte unsichere Inhalte hinweisen.
Hier scheitert die Prüfung: Der TLS-Aufbau der Hauptseite kann erfolgreich gewesen sein. Einzelne Ressourcen werden jedoch über unverschlüsseltes HTTP angefordert und besitzen daher nicht denselben Transport- und Integritätsschutz.
Was dahinterstecken kann: Häufig sind veraltete Links, falsch konfigurierte Erweiterungen oder externe Inhalte, die nicht per HTTPS eingebunden werden. Besonders relevant sind aktive Bestandteile wie Skripte, weil Veränderungen ihr Verhalten beeinflussen können.
Was jetzt sicher ist: Erzwingen Sie nicht das Laden blockierter Inhalte. Funktionieren Login, Formular oder Bezahlvorgang nicht zuverlässig, brechen Sie den Vorgang ab. Der Betreiber muss die betroffenen Ressourcen über vertrauenswürdige HTTPS-Adressen bereitstellen.
8. HSTS verhindert eine unsichere Ausnahme
Was Sie sehen: Der Browser verweigert die Verbindung vollständig und bietet möglicherweise keine Möglichkeit an, trotz des Zertifikatsproblems fortzufahren.
Hier scheitert die Prüfung: Für die Domain ist eine strikte HTTPS-Nutzung vorgesehen. Gleichzeitig kann der Browser die TLS-Verbindung oder das Zertifikat nicht ordnungsgemäß bestätigen. Eine unsichere Ausnahme würde dieser Vorgabe widersprechen.
Was dahinterstecken kann: Das Zertifikat kann abgelaufen sein, einen falschen Namen enthalten oder über eine nicht akzeptierte Vertrauenskette verfügen. Auch eine fehlerhafte Serverkonfiguration oder ein nicht korrekt eingerichteter Filter kommt infrage.
Was jetzt sicher ist: Versuchen Sie nicht, HSTS oder die Zertifikatsprüfung zu umgehen. Prüfen Sie Adresse, Systemzeit und Netzwerk. Bei einem internen Angebot ist die zuständige IT, bei einem öffentlichen Dienst der Betreiber für die Klärung verantwortlich.
HSTS und Mixed Content bezeichnen unterschiedliche Situationen. Bei Mixed Content kann die per HTTPS geladene Hauptseite einzelne unsichere Ressourcen enthalten, die der Browser blockiert. Bei einer HSTS-bezogenen Blockierung wird die Verbindung zur angeforderten Domain wegen einer nicht erfüllten strikten HTTPS-Vorgabe grundsätzlich verweigert.
Die sichere Endentscheidung
Bei einer Warnung vor einem Login, einer Zahlung oder der Übermittlung vertraulicher Daten gilt: Brechen Sie den Vorgang zunächst ab. Prüfen Sie die vollständige Adresse sowie Datum, Uhrzeit und Zeitzone des Geräts. Öffnen Sie bekannte Dienste anschließend über eine selbst eingegebene offizielle Adresse, ein geprüftes Lesezeichen oder eine vertrauenswürdige Anwendung neu.
Bleibt die Warnung bestehen, kontaktieren Sie den Betreiber oder die zuständige IT über einen bereits bekannten, unabhängigen Weg. Erst wenn die Ursache geklärt und die Prüfung ohne Ausnahme erfolgreich ist, sollten sensible Daten übertragen werden. Eine Browserwarnung ist kein Beweis für einen Angriff, aber ein klarer Hinweis darauf, dass die erwartete Gegenstelle oder der geschützte Verbindungsaufbau derzeit nicht zuverlässig bestätigt werden kann.
Wichtige TLS-Begriffe kurz erklärt und häufige Fragen
In Browsermeldungen, Hosting-Oberflächen und Supportfällen tauchen einige Begriffe regelmäßig auf. Für ihre Einordnung genügt meist ein Verständnis ihrer Funktion; kryptografische Einzelheiten sind dafür nicht erforderlich.
TLS 1.2 und TLS 1.3
TLS 1.2 und TLS 1.3 sind unterschiedliche Versionen des Protokolls. TLS 1.3 vereinfacht und modernisiert Teile des Verbindungsaufbaus, während TLS 1.2 weiterhin in vielen Umgebungen vorkommt. Welche Version verwendet werden kann, hängt von Client, Server und deren Sicherheitsvorgaben ab. Ältere Protokollstände können mit heutigen Anforderungen unvereinbar sein.
Cipher Suite, SNI, HSTS und Mixed Content
- Cipher Suite: Der Begriff bezeichnet ein Bündel kryptografischer Verfahren beziehungsweise Parameter, die für eine TLS-Verbindung verwendet werden. Client und Server müssen eine akzeptierte Kombination finden.
- SNI: Die Server Name Indication übermittelt beim Verbindungsaufbau den gewünschten Hostnamen. So kann ein Server, der mehrere Namen bedient, die passende TLS-Konfiguration und das passende Zertifikat auswählen.
- HSTS: HTTP Strict Transport Security ermöglicht einer Webseite, dem Browser eine strikte HTTPS-Nutzung vorzugeben. Bei Zertifikatsproblemen kann dies verhindern, dass eine unsichere Ausnahme zugelassen wird.
- Mixed Content: Die Hauptseite wird per HTTPS geladen, bindet aber einzelne Ressourcen über unverschlüsseltes HTTP ein. Je nach Art der Ressource und Browserverhalten können diese Inhalte blockiert werden.
TLS ersetzt weder eine Prüfung des Anbieters noch sichere Passwortpraxis, Mehrfaktor-Authentisierung, Schutz vor Schadsoftware oder Aufmerksamkeit gegenüber Phishing. Das Protokoll schützt den Transport zu der technisch bestätigten Gegenstelle; es bewertet nicht die Absichten dieser Gegenstelle.
Häufige Fragen zu TLS
Was bedeutet TLS?
TLS steht für Transport Layer Security. Das Verschlüsselungsprotokoll schützt Verbindungen zwischen Anwendungen vor einfachem Mitlesen und unbemerkten Veränderungen und unterstützt die Prüfung der Gegenstelle.
Ist TLS dasselbe wie HTTPS?
Nein. HTTPS bezeichnet HTTP über eine TLS-geschützte Verbindung. TLS kann auch andere Anwendungsprotokolle absichern.
Was ist ein Zertifikat?
Ein Zertifikat ist ein digitales Dokument, das unter anderem einen öffentlichen Schlüssel mit Namen beziehungsweise geprüften Identitätsangaben, einem Gültigkeitszeitraum und einer ausstellenden Stelle verbindet.
Was ist ein TLS-Handshake?
Beim TLS-Handshake stimmen Client und Server Verbindungsparameter ab, prüfen das Zertifikat und leiten Schlüssel für die anschließende geschützte Sitzung ab.
Warum ist ein Zertifikat abgelaufen?
Zertifikate gelten nur für einen begrenzten Zeitraum. Eine Warnung kann auf eine versäumte Erneuerung, eine fehlerhafte Bereitstellung oder eine falsche lokale Systemzeit hindeuten.
Was bedeutet selbstsigniertes Zertifikat?
Ein selbstsigniertes Zertifikat wurde nicht über die übliche Vertrauenskette einer bereits anerkannten Zertifizierungsstelle bestätigt. Seine Legitimität muss daher auf einem anderen, verlässlichen Weg geklärt werden.
Ist eine TLS-Seite automatisch seriös?
Nein. Auch eine betrügerische Webseite kann eine gültig verschlüsselte Verbindung für ihre eigene Domain anbieten. TLS ist kein Gütesiegel und kein Schutz vor Phishing.
Warum blockiert der Browser eine Verbindung?
Der Browser blockiert eine Verbindung, wenn er eine wesentliche TLS- oder Zertifikatsprüfung nicht erfolgreich abschließen kann. Mögliche Gründe sind ein ungültiger Zeitraum, ein falscher Domainname, eine nicht akzeptierte Vertrauenskette, inkompatible TLS-Parameter oder eine strikte HSTS-Vorgabe.
TLS ist eine zentrale Sicherheitstechnik des Internets, aber kein Vertrauenssiegel für alles, was hinter einer Webseite steht. Das Protokoll schützt die Verbindung, während das Zertifikat den verwendeten Schlüssel an einen Namen oder eine geprüfte Identitätsangabe bindet.
Wenn der Browser eine TLS- oder Zertifikatswarnung zeigt, ist nicht automatisch ein Angriff bewiesen. Sicher ist aber: Eine wichtige Prüfung wurde nicht erfolgreich abgeschlossen. Vor Logins, Zahlungen oder der Übertragung vertraulicher Daten sollte die Ursache geklärt sein, statt die Warnung routinemäßig zu übergehen.
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten