Hier ist eine Frage, über die es sich nachzudenken lohnt: Wenn „ SSL “ schon seit Jahren nicht mehr existiert, warum spricht dann die gesamte Branche immer noch jeden Tag von „SSL“? Man kauft ein „SSL -Zertifikat“, konfiguriert „SSL -Einstellungen“ und liest auf den Seiten der Anbieter über „SSL -Sicherheit“, doch das Protokoll, das die eigentliche Arbeit leistet, ist mit ziemlicher Sicherheit „ TLS “. Die Unterscheidung zwischen „ SSL “ und „ TLS “ ist zu einer der hartnäckigsten Namenskonventionen in der Cybersicherheit geworden.
Der Grund ist wichtiger als Nebensächlichkeiten. DasSecurity Socket Layer-Protokoll(SSL) wurde bereits 2015 offiziell als veraltet eingestuft, und bis 2020 waren alle Versionen von „ SSL “ aus den unterstützten Browsern und Servern verschwunden. Die Zertifikate, die Zertifizierungsstellen als „SSL -Zertifikate“ vermarkten, sind in der PraxisTransport Layer Security-Zertifikate(TLS). Die Bezeichnung hat überlebt, das Protokoll hingegen nicht.
Dieser Artikel verzichtet auf grundlegende Definitionen und konzentriert sich stattdessen auf das, was Sicherheitsteams tatsächlich benötigen. Wir werden die tatsächlichen Unterschiede zwischen den beiden Protokollen verdeutlichen, erläutern, warum Terminologieunterschiede Ihre Sicherheitslage verzerren können, und darlegen, was Ihr Team heute tun sollte. Beide Protokolle stützen sich auf X.509-Zertifikate, um Endpunkte zu authentifizieren und Vertrauen herzustellen. Daher bestimmt der von Ihnen verwendete Wortschatz, wie gut Sie die von Ihnen betriebenen Systeme verstehen.
Ein kurzer Rückblick: Von „ SSL “ bis TLS
Netscape, ein in den 1990er Jahren beliebter Internetbrowser, entwickelte „ SSL “, um frühe Webtransaktionen zu sichern. „ SSL “ 1.0 kam aufgrund schwerwiegender Sicherheitslücken nie auf den Markt. „ SSL “ 2.0 erschien 1995, wies jedoch ebenfalls Schwachstellen auf. „ SSL “ 3.0 folgte 1996, bevor es 2015 offiziell als veraltet eingestuft wurde.
Als das Protokoll eine standardisierte, herstellerneutrale Heimat benötigte, übernahm die Internet Engineering Task Force (IETF) die Verantwortung. Die IETF entwickelte „ TLS “ als Nachfolger von „ SSL“: „ TLS “ 1.0 wurde 1999 eingeführt und baute auf „ SSL “ 3.0 auf, war jedoch bewusst nicht mit diesem kompatibel. „ TLS “ Version 1.1 erschien 2006, TLS 1.2 im Jahr 2008 und schließlich TLS 1.3 im Jahr 2018 nach rund 30 IETF-Entwürfen. Die große Anzahl an Entwürfen spiegelt die Weiterentwicklung von TLS wider, bei der zahlreiche im Laufe der Jahre entdeckte Schwachstellen behoben und das Protokoll entsprechend abgesichert wurde. Beispiele für solche Schwachstellen sind Padding- und Downgrade-Angriffe, Poodle, Heartbleed usw.
Die anschließende Bereinigung war entscheidend. Microsoft, Apple, Google, Mozilla, Cloudflare und Cisco haben „ TLS “ 1.0 und 1.1 bis März 2020 alle als veraltet eingestuft. Heute sind nur noch „ TLS “ 1.2 und „ TLS “ 1.3 im aktiven Einsatz, und alle früheren Versionen stellen mittlerweile eher ein Risiko dar als eine Legacy-Option.
Zehn wesentliche technische Unterschiede zwischen „ SSL “ und TLS
Die Protokolle weisen zwar gewisse Ähnlichkeiten auf, unterscheiden sich jedoch in ihren internen Abläufen in einer Weise, die sich direkt auf die Sicherheit auswirkt. Die folgende Tabelle fasst zehn wesentliche Unterschiede zusammen, auf die im Anschluss näher eingegangen wird – angefangen beim allgemeinen „ SSL “-Design bis hin zum modernsten „ TLS “ 1.3.
| SSL | TLS (1.3) | |
|---|---|---|
| Perfektes Vorwärtsgeheimnis | Niemals verpflichtend | Obligatorisch (mit einer einzigen Ausnahme) |
| AEAD | Niemals | Obligatorisch |
| Algorithmen | Schwache Algorithmen, darunter MD5, SHA-1 und DES | Starke moderne Algorithmen, darunter SHA-2 und AES |
| Warnmeldungen | Wurde in früheren Versionen unverschlüsselt gesendet | Verschlüsselt, mit Fehlermeldung |
| Schlüsselableitungsfunktionen | Ad-hoc-KDFs basieren häufig auf bestimmten Algorithmen | Verwendet moderne KDFs mit starken Sicherheitsnachweisen |
| Padding-Angriffe auf RSA | Lässt RSA-Versionen zu, die für Padding-Angriffe anfällig sind | Lässt keine RSA-Versionen zu, die anfällig für Padding-Angriffe sind |
| Schutz vor Downgrade- und Substitutionsangriffen | In vielerlei Hinsicht anfällig für Downgrade- und Substitutionsangriffe | Verfügt über zahlreiche Mechanismen zum Schutz vor Herabstufungen, darunter Transkripte, die jede Phase des Protokolls kryptografisch verknüpfen |
| PQC | PQC wird niemals standardisiert werden für SSL | Derzeit werden PQC-Standards entwickelt |
| Protokoll aufzeichnen | Das firmeneigene Protokoll von Netscape | Von der IETF standardisiertes Datensatzprotokoll |
| Optimiert | 2 RTT | 1 RTT |
 
Perfektes Vorwärtsgeheimnis
SSL Bisher wurde eine Sitzung üblicherweise dadurch geschützt, dass ihr Schlüssel mit dem Langzeitschlüssel des Servers verschlüsselt wurde. Wer diesen Langzeitschlüssel später in die Hände bekam, konnte damit jede aufgezeichnete Unterhaltung entsperren – auch solche, die bereits Jahre zurücklagen. TLS 1.3 verlangt für jede Verbindung einen neuen Einmal-Schlüssel, der sofort nach Beendigung der Verbindung verworfen wird. Der Diebstahl des privaten Schlüssels eines Servers ist zwar nach wie vor schwerwiegend, macht jedoch den bisherigen Datenverkehr nicht mehr zugänglich.
AEAD
SSL Die Daten wurden in zwei getrennten Schritten verschlüsselt und auf Manipulation geprüft – in einer Reihenfolge, die den Empfänger dazu zwang, die vom Angreifer bereitgestellten Daten erst zu entschlüsseln, bevor er deren Echtheit bestätigen konnte. Angreifer lernten, diese Lücke auszunutzen. TLS 1.3 erlaubt nur Verschlüsselungsverfahren, die beide Aufgaben gleichzeitig erledigen, sodass alles, was die Manipulationsprüfung nicht besteht, verworfen wird, bevor es überhaupt geprüft wird.
Algorithmen
SSL basierte auf Verschlüsselungsalgorithmen und Hash-Funktionen, die inzwischen geknackt wurden, und enthielt zudem bewusst abgeschwächte Optionen, die noch aus den Exportvorschriften der 1990er Jahre stammten. Mit der Version 1.3 von „ TLS “ wurden all diese Optionen entfernt und es wird nur noch eine kurze Liste von Algorithmen angeboten, die nach wie vor als vertrauenswürdig gelten. Genau das ist der Sinn des kleineren Menüs: Es gibt keine schwachen Optionen mehr, die ein falsch konfigurierter Server auswählen könnte.
Warnmeldungen
Wenn eine Verbindung über SSL fehlschlug, wurde die Fehlermeldung unverschlüsselt übertragen, sodass jeder, der das Netzwerk überwachte, genau erfahren konnte, was schiefgelaufen war. TLS 1.3 verschlüsselt diese Meldungen nahezu sofort und hält Fehler somit vertraulich. Der Nachteil für Administratoren besteht darin, dass eine Netzwerkaufzeichnung allein keinen Aufschluss mehr über die Fehlerursache gibt und die Fehlerbehebung nun über die Protokolle auf dem Client und dem Server erfolgen muss.
Schlüsselableitungsfunktionen
Jede Verbindung beginnt mit einem einzigen gemeinsamen Geheimnis und erfordert mehrere separate Schlüssel, die daraus abgeleitet werden. SSL verwendete für diesen Schritt ein selbst entwickeltes Verfahren, das sich zwar in der Praxis bewährt hat, jedoch nie durch einen Beweis untermauert wurde. TLS 1.3 nutzt eine standardisierte, gut erforschte Methode, die auf einer klaren Sicherheitsargumentation basiert, und leitet jeden Schlüssel so ab, dass das Erkennen eines Schlüssels keine Rückschlüsse auf die anderen zulässt.
Padding-Angriffe auf RSA
Jahrzehntelang wies eine bestimmte Art der RSA-Nutzung eine bekannte Schwachstelle auf, die es einem geduldigen Angreifer ermöglichte, das geheime Schlüsselpaar, das das Herzstück einer Verbindung bildet, zu ermitteln. Es wurden wiederholt Korrekturen vorgenommen, die jedoch immer wieder umgangen wurden. Mit der Version 1.3 von „ TLS “ wurde die Bereitstellung von Patches eingestellt und diese Art der RSA-Nutzung vollständig entfernt. RSA kommt zwar weiterhin zum Einsatz, jedoch ausschließlich zum Identitätsnachweis und nur in einer Form, deren Sicherheit fundiert nachgewiesen ist.
Schutz vor Downgrade- und Substitutionsangriffen
Bei einigen der bekanntesten Angriffe auf SSL wurde zu keinem Zeitpunkt die Kryptografie geknackt. Die Angreifer schalteten sich in die Verbindung ein und veränderten unbemerkt die anfängliche Verhandlungsphase, wodurch sie beide Seiten dazu brachten, sich auf einen schwachen Schutz zu einigen, von dem jede Seite glaubte, dass die andere ihn gefordert hatte. SSL konnte diese Manipulation nicht erkennen. TLS 1.3 stellt sicher, dass beide Parteien eine identische, unveränderte Verhandlungsphase sehen, bevor tatsächliche Daten übertragen werden.
Post-Quanten-Kryptografie
SSL wurde eingestellt, und es werden keine weiteren Arbeiten daran durchgeführt. TLS 1.3 wurde so konzipiert, dass neue Algorithmen integriert werden können, ohne dass eine neue Version des Protokolls erforderlich ist. Dies ist jetzt von Bedeutung, da die quantenresistente Kryptografie Einzug hält. Der postquantenische Schlüsselaustausch ist bereits in gängigen Browsern implementiert. Postquantenische Zertifikate stellen den schwierigeren verbleibenden Schritt dar, vor allem weil die neuen Schlüssel und Signaturen wesentlich umfangreicher sind.
Protokoll aufzeichnen
SSL war die Spezifikation eines einzelnen Unternehmens, die nach Belieben dieses Unternehmens überarbeitet wurde. Seit die Verantwortung auf ein Gremium für offene Standards übergegangen ist, wurde jede nachfolgende Version öffentlich von den Entwicklern des „ software “ geprüft und vor der Veröffentlichung von Forschern unabhängig analysiert. TLS 1.3 verbirgt zudem einen größeren Teil der internen Struktur einer Verbindung vor Netzwerkbeobachtern.
Handshake-Hin- und Rückläufe
Bevor über eine „ SSL “-Verbindung auch nur ein einziges Byte an tatsächlichen Daten übertragen werden konnte, mussten beide Seiten zwei vollständige Nachrichtenrunden austauschen. „ TLS “ 1.3 strukturiert diesen anfänglichen Austausch so um, dass eine Runde ausreicht. Bei einer langsamen Mobilfunkverbindung macht sich die dadurch eingesparte Hin- und Rückübertragung in der Ladegeschwindigkeit einer Seite bemerkbar.
TLS 1.2 im Vergleich zu TLS 1.3: Was hat sich geändert?
Da sowohl TLS 1.2 als auch TLS 1.3 weiterhin aktiv genutzt werden, ist das Verständnis der Unterschiede zwischen beiden Versionen eine praktische Notwendigkeit und keine rein theoretische Übung. Drei Änderungen stechen dabei besonders hervor.
Schnellere Handshake-Leistung
TLS 1.3 reduziert den Handshake auf einen einzigen Hin- und Rücklauf, gegenüber zwei in „ TLS “ 1.2. Weniger Hin- und Rückläufe bedeuten einen schnelleren Verbindungsaufbau und ein reaktionsschnelleres HTTPS für die Nutzer. Der optimierte Handshake-Prozess von „ TLS “ ist einer der eindeutigsten Gründe, „ TLS “ 1.3 als Ziel für neue Bereitstellungen zu wählen.
Standardmäßig perfekte Forward Secrecy
Wie oben erwähnt, schreibt „ TLS “ 1.3 die „Perfect Forward Secrecy“ mittels „Diffie-Hellman Ephemeral“ vor, während frühere Versionen dies als optional behandelten. Das Protokoll generiert für jede Sitzung einen eindeutigen Sitzungsschlüssel, sodass die Kompromittierung eines Schlüssels die anderen nicht gefährdet. Dieses Design begrenzt den Auswirkungsbereich eines Sicherheitsverstoßes und stärkt die Widerstandsfähigkeit gegen Brute-Force- und Man-in-the-Middle-Angriffe.
Entfernung veralteter kryptografischer Algorithmen
TLS TLS .1.3 wird mit einer einfachen Verschlüsselungssuite ausgeliefert, die ausschließlich Algorithmen ohne bekannte Sicherheitslücken enthält. 1.2 hingegen lässt noch einige schwache Verschlüsselungsalgorithmen zu, was die Angriffsfläche vergrößert und die Konfiguration erschwert. Laut NIST müssen Server und Clients im Rahmen des „ “-Programms 1.2 mit FIPS-basierten Verschlüsselungssuiten unterstützen, und das NIST empfiehlt Organisationen, Migrationspläne für den Umstieg auf 1.3 zu erstellen. TLS TLS TLS
Authentifizierte Verschlüsselung mit zugehörigen Daten (AEAD)
TLS Bis zur Version 1.2 wurden Verschlüsselung und Authentifizierung als separate Vorgänge behandelt, wobei der MAC in der Regel vor der Verschlüsselung angewendet wurde. Diese Reihenfolge zwang Empfänger dazu, den vom Angreifer kontrollierten Chiffretext vor dessen Überprüfung zu verarbeiten, was zu einer langen Reihe von Padding-Oracle-Angriffen führte. TLS Die Version 1.3 erlaubt ausschließlich AEAD-Verfahren, die Vertraulichkeit und Integrität unter einem einzigen Schlüssel zu einer einzigen Primitive zusammenfassen und die Zusammensetzung vollständig beseitigen.
Warum sich der Begriff „SSL“ hartnäckig hält (und wann er echte Probleme verursacht)
Der Begriff „SSL“ hat sich aus einem einfachen Grund durchgesetzt: Er ist fest in Produktschnittstellen, Dokumentationen und dem Marketing der Anbieter verankert. Kryptografie-Bibliotheken wie OpenSSL und WolfSSL tragen nach wie vor diesen Namen. In Konfigurationsmasken werden Felder weiterhin als „SSL “ bezeichnet, in Wissensdatenbanken wird nach wie vor auf die „SSL -Einrichtung“ verwiesen, und auf Verkaufsseiten wird nach wie vor mit „SSL -Zertifikaten“ geworben. Die Begriffe sind im alltäglichen Sprachgebrauch austauschbar geworden, obwohl das zugrunde liegende Protokoll „ TLS “ ist.
Meistens handelt es sich dabei um harmlose Vereinfachungen. Probleme entstehen erst, wenn die Bezeichnung und die Realität so weit auseinanderklaffen, dass dies Auswirkungen auf Entscheidungen hat. Ein Team könnte beispielsweise glauben, es nutze „SSL“, während seine Server tatsächlich TLS 1.2 verwenden, was eine ehrliche Einschätzung der Sicherheitslage erschwert.
Die Einhaltung von Vorschriften sorgt für eine weitere Komplikation. Prüfer weisen manchmal auf „SSL“-Verweise in der Dokumentation hin, in der die Konfigurationen von „ TLS “ beschrieben werden, was die Teams dazu zwingt, Zeit damit zu verbringen, die Formulierungen mit der tatsächlichen Umsetzung abzugleichen. In der Diskrepanz zwischen dem, was man als System bezeichnet, und dem, was darauf tatsächlich läuft, sammeln sich unbemerkt Verwirrung und Risiken an.
Die Zukunft von „ TLS “: kürzere Lebensdauer und Post-Quanten-Tauglichkeit
Die nächste wichtige Frage lautet: „Wie verwalten wir TLS in großem Maßstab, während sich die Rahmenbedingungen ändern?“ Zwei Faktoren verändern die Landschaft grundlegend: drastisch verkürzte Gültigkeitsdauern von Zertifikaten und das Aufkommen der Post-Quanten-Kryptografie.
Änderungen der Gültigkeitsdauer von Zertifikaten
Das CA/Browser Forum hat beschlossen, die Gültigkeitsdauer von „ TLS “-Zertifikaten nach einem festen Zeitplan zu verkürzen: auf 200 Tage bis 2026, auf 100 Tage bis 2027 und auf 47 Tage bis 2029. Mit der Verkürzung der Gültigkeitsdauer steigt das Volumen der Erneuerungen um etwa das Achtfache, sodass eine manuelle Nachverfolgung nicht mehr praktikabel ist. Die Vorbereitung auf eine Zertifikatslaufzeit von 47 Tagen bedeutet, die Verlängerung als automatisierten, ständig laufenden Prozess zu betrachten und nicht als bloße Kalendererinnerung.
Post-Quanten-Kryptografie
Das heutige „ TLS “ wurde nicht dafür konzipiert, Quantenangriffen standzuhalten, und der Schlüsselaustausch im Rahmen des Handshakes ist die am stärksten gefährdete Komponente. Das dringlichste Problem ist das „Harvest-Now-Decrypt-Later“-Szenario (HNDL), bei dem Angreifer heute verschlüsselten Datenverkehr erfassen und ihn erst entschlüsseln, sobald Quantencomputer ausgereift sind. Als Reaktion darauf stellt die Branche derzeit auf postquantene Kryptografie (PQC) um, bei der zukünftige Handshakes den klassischen Schlüsselaustausch wie RSA durch Schlüsselkapselungsmechanismen (KEMs) ersetzen.
Die Standards liegen bereits vor. Das NIST hat seine ersten PQC-Standards – FIPS 203, 204 und 205 – fertiggestellt, die im August 2024 veröffentlicht wurden. Der hybride PQC-Schlüsselaustausch läuft bereits auf dem heutigen „ TLS “ 1.3 über neue Schlüsselaustauschgruppen anstelle einer neuen Protokollversion, und der IETF-Entwurf definiert X25519MLKEM768, SecP256r1MLKEM768 und SecP384r1MLKEM1024 als hybride Mechanismen für „ TLS “ 1.3.
Die Einführung schreitet schneller voran, als viele erwarten. Eine im Jahr 2026 durchgeführte Erhebungsstudie ergab, dass rund 49 % der analysierten Domains durch den hybriden Schlüsselaustausch eine teilweise Post-Quantum-Bereitschaft aufwiesen, was auf die Integration von ML-KEM-768 in Browser, Cloud-Plattformen und CDNs zurückzuführen ist. Unternehmen sollten sich bereits jetzt auf hybride Zertifikatsmodelle vorbereiten, die sowohl klassische als auch Post-Quantum-Algorithmen unterstützen.
Zwar wird „ TLS “ 1.2 vielerorts noch unterstützt, doch ist die Umstellung auf „ TLS “ 1.3 der nächste Schritt, der mehr Sicherheit bietet und Ihre Infrastruktur zukunftssicher macht. Alle Mechanismen, die für die postquanten TLS standardisiert werden, zielen ausschließlich auf Version 1.3 ab, sodass „ TLS “ 1.2 bei der Migration gänzlich außer Betracht bleibt.
Wie Keyfactor helfen Keyfactor
Der Übergang vom „SSL“-Ansatz zu einem echten „ TLS “-Betrieb erfordert mehr als nur die Umbenennung eines Feldes in Ihrer Dokumentation. „ Keyfactor “ bietet Sicherheitsteams die Plattform, um Zertifikate angesichts immer kürzerer Lebensdauern in großem Maßstab zu verwalten und sich souverän auf den Übergang zur Post-Quantum-Ära vorzubereiten.
Automatisierung des Zertifikatslebenszyklus durch Keyfactor Command bietet durchgängige Transparenz und automatisierte Verlängerung – was angesichts von Zyklen, die sich auf 47 Tage verkürzen, unerlässlich wird. Die moderne PKI-Plattform EJBCAbietet eine PKI der Enterprise-Klasse, die Krypto-Agilität und Standard-Registrierungsprotokolle für die groß angelegte Ausstellung von „ TLS “-Zertifikaten unterstützt.Die kryptografische Erkennung und Bestandsaufnahmedeckt automatisch alle kryptografischen Ressourcen auf, sodass Sie die Quantencomputer-Bereitschaft bewerten und veraltete „ SSL “-Konfigurationen beseitigen können.
Das automatisierte Zertifikatslebenszyklusmanagement verwandelt ein Compliance-Problem in einen wiederholbaren Vorgang. Fordern Sie eine Demo an, um zu erfahren, wie „ Keyfactor “ Ihnen dabei hilft, Annahmen aus der „ SSL “-Ära hinter sich zu lassen und „ TLS “ so zu betreiben, wie es moderne Sicherheitsanforderungen erfordern.
Hast du Fragen zu „ SSL “ im Vergleich zu „ TLS “? Wir haben die Antworten.
Ist die Nutzung von „ SSL “ noch sicher?
Nein. Alle Versionen von „ SSL “ wurden aufgrund bekannter Sicherheitslücken als veraltet eingestuft, und „ SSL “ 3.0 wurde 2015 eingestellt. Moderne Browser und Server unterstützen „ SSL “ nicht mehr, daher sollten Sie „ TLS “ 1.2 oder 1.3 verwenden.
Sind „ SSL “-Zertifikate und „ TLS “-Zertifikate dasselbe?
In der Praxis ja. Anbieter und Zertifizierungsstellen, die „SSL “-Zertifikate verkaufen, bieten tatsächlich „ TLS “-Zertifikate an. Der Begriff wird weiterhin als Kurzform verwendet, doch das Protokoll, das Ihre Verbindung sichert, ist „ TLS “.
Was ist die derzeit sicherste Version von „ TLS “?
„TLS “ 1.3. Diese Version verzichtet auf veraltete Algorithmen, sorgt standardmäßig für „Perfect Forward Secrecy“ und reduziert den Handshake auf einen einzigen Roundtrip. Diese Kombination macht sie zur derzeit sichersten und effizientesten Option.
Muss ich von TLS 1.2 auf TLS 1.3 umsteigen?
TLS 1.2 ist nach wie vor weit verbreitet und bei korrekter Konfiguration sicher, doch TLS 1.3 bietet sowohl Leistungs- als auch Sicherheitsvorteile. Das NIST empfiehlt die Erstellung von Migrationsplänen; daher sollten Sie TLS 1.3 als Ziel für neue Installationen festlegen.
Wie wirken sich kürzere Gültigkeitsdauern von Zertifikaten auf die Verwaltung von SSL/TLS aus?
Das CA/Browser Forum senkt die maximale Gültigkeitsdauer bis 2029 auf 47 Tage, wodurch sich die Erneuerungszyklen etwa verachtfachen. Eine manuelle Verwaltung ist bei diesem Tempo nicht mehr tragbar, sodass ein automatisiertes Lebenszyklusmanagement unerlässlich wird.
Was bedeutet Post-Quanten-Kryptografie für TLS?
Quantencomputer könnten letztendlich die Algorithmen im heutigen Handshake von TLS knacken. Die Branche integriert derzeit quantenresistente Algorithmen, daher sollten Unternehmen ihre kryptografischen Ressourcen inventarisieren und hybride Zertifikatsmodelle planen, die sowohl klassische als auch Post-Quanten-Algorithmen unterstützen.
Warum zeigen Browser in ihren Sicherheitseinstellungen immer noch „SSL“ an?
Veraltete Bezeichnung. Browser und Tools verweisen aus Gewohnheit auf SSL , doch das Protokoll, das die Verbindung sichert, ist TLS. Wenn Sie eine sichere HTTPS-Verbindung sehen, läuft diese unter TLS.
Wie kann ich feststellen, welche Version von „ TLS “ auf meinem Server verwendet wird?
Verwenden Sie command-Line-Tools wie OpenSSL oder einen Online-Testdienst. Mit dem Befehl „openssl s_client -connect yourdomain.com:443“ werden die ausgehandelte „ TLS “-Version und die Verschlüsselungssuite angezeigt.
