Welche TLS-Versionen und Cipher Suites sollte ich heute auf dem Webserver erlauben?

TLS 1.0 bis TLS 1.3: Protokollversionen, Handshake-Änderungen und aktuelle Sicherheitslage

Zwischen TLS 1.0 und TLS 1.3 liegen nicht nur inkrementelle Anpassungen, sondern grundlegende Änderungen an Handshake, Kryptografie-Auswahl und Angriffsfestigkeit. In der Praxis entscheidet die Protokollversion darüber, ob moderne Cipher Suites (insbesondere AEAD) nutzbar sind, ob unsichere Mechanismen wie CBC in Kombination mit Legacy-Aushandlung überhaupt auftreten können und wie viel Angriffsfläche durch zusätzliche Round-Trips oder abwärtskompatible Logik entsteht.

TLS 1.0 und TLS 1.1: Legacy-Protokolle mit strukturellen Risiken

TLS 1.0 (RFC 2246) und TLS 1.1 (RFC 4346) gelten seit Jahren als veraltet. Beide Versionen unterstützen zwar prinzipiell RSA- und (EC)DHE-Schlüsselaustausch, sind aber in typischen Implementierungen eng mit Cipher Suites verbunden, die heute als riskant oder obsolet eingestuft werden (vor allem CBC-basierte Suiten und ältere Hash-Kombinationen). Zusätzlich erzwingen viele Umgebungen aus Kompatibilitätsgründen Fallback-Logik, die Angriffsflächen eröffnet oder zumindest das Fehlerrisiko in der Konfiguration erhöht.

Praktisch relevant sind vor allem drei Punkte: Erstens fehlt ein moderner, klarer Trennstrich bei der Aushandlung kryptografischer Parameter; zweitens sind viele Schutzmaßnahmen gegen Downgrade- oder Padding-orientierte Angriffe historisch gewachsen und abhängig von korrekter Implementierung; drittens reduzieren aktuelle Browser und Plattformen die Unterstützung zunehmend oder haben sie bereits entfernt. Wo TLS 1.0/1.1 noch aktiv ist, tauchen häufig Interop-Probleme mit modernen Clients auf, und Audits bewerten die Konfiguration regelmäßig als nicht konform (z. B. in PCI-DSS-nahen Anforderungen).

TLS 1.2: Flexible Kryptografie, aber anfällig für Fehlkonfigurationen

TLS 1.2 (RFC 5246) ist funktional der Wendepunkt: Die PRF und die Signaturalgorithmen lassen sich besser an moderne Hashverfahren koppeln, und AEAD-Cipher Suites wie AES-GCM oder ChaCha20-Poly1305 sind möglich. Gleichzeitig bleibt TLS 1.2 in der Praxis ein Protokoll, in dem falsche Prioritätenlisten, aktiviertes RSA-Key-Exchange oder ein unkontrolliertes Nebeneinander von CBC- und AEAD-Suiten das Sicherheitsniveau deutlich drücken können.

Wesentlich ist die Trennung zwischen Schlüsselaustausch und Authentisierung: In TLS 1.2 kann ein Server immer noch Cipher Suites anbieten, die keine Vorwärtsgeheimnis-Eigenschaft liefern (z. B. statisches RSA-Key-Exchange). Für aktuelle Sicherheitsanforderungen gilt deshalb: (EC)DHE erzwingen, AEAD bevorzugen, und nur Signaturen mit zeitgemäßen Hash-Algorithmen zulassen. In der Praxis setzt sich ECDHE gegenüber DHE durch, weil es bei vergleichbarer Sicherheit effizienter ist; DHE bleibt relevant, wenn bestimmte Compliance-Profile/Policies (z. B. FIPS-gebundene Umgebungen) oder Interop-Zwänge vorliegen und die DH-Parameter sauber gepflegt werden.

TLS 1.3: Verschlankter Handshake und konsequente Modernisierung

TLS 1.3 (RFC 8446) entfernt ganze Klassen historischer Komplexität. Cipher Suites definieren nur noch AEAD und Hash für HKDF; Schlüsselaustausch ist fest auf (EC)DHE ausgerichtet, womit Vorwärtsgeheimnis praktisch Standard wird. Viele Altlasten sind gestrichen, darunter RSA-Key-Exchange, statische DH-Varianten sowie eine Reihe anfälliger oder schwer abzusichernder Optionen. Der Handshake wird in der Regel auf 1-RTT reduziert; optionale 0-RTT-Daten existieren, bringen aber Replay-Risiken mit sich und eignen sich nur für streng idempotente Anfragen und kontrollierte Einsatzszenarien.

Eine zentrale Änderung ist die klare Trennung und Absicherung der Aushandlung: Der ehemals frei kombinierbare Mix aus Cipher Suite, Hash und Schlüsselaustausch wird durch ein engeres, leichter auditierbares Modell ersetzt. Außerdem sorgt ein definierter Downgrade-Schutzmechanismus (u. a. über Signalisierung im Server Random bei bestimmten Downgrades) dafür, dass erzwungene Abwärtsverhandlungen auffallen, sofern beide Seiten TLS 1.3 korrekt unterstützen.

Typische Browserwarnungen und Diagnose-Signale bei veralteten Versionen

Wenn Clients TLS 1.0/1.1 nicht mehr akzeptieren oder ein Server nur noch schwache Parameter anbietet, äußert sich das in klaren Fehlmustern. Moderne Browser brechen die Verbindung oft schon vor dem Laden der Seite ab; im Hintergrund stehen häufig fehlende gemeinsame Protokollversionen, nicht akzeptierte Signaturalgorithmen oder Cipher-Suite-Mismatches. Auch Zwischenkomponenten wie Proxies und Load Balancer können als „TLS-Terminator“ auftreten und dabei veraltete Profile erzwingen, obwohl Backend-Server korrekt konfiguriert sind.

• Protokoll-Mismatch: Client lehnt Serverangebot ab, wenn nur TLSv1.0 oder TLSv1.1 verfügbar ist; häufig sichtbar als „unsupported protocol“ in Browser- oder Client-Logs.
• Cipher-Suite-Mismatch: Server bietet nur CBC/Legacy-Suiten an, während der Client nur AEAD akzeptiert; Diagnose oft über handshake_failure bzw. fehlende „shared cipher“ in Debug-Ausgaben.
• Schlüsselaustausch nicht akzeptiert: Aktiviertes RSA-Key-Exchange oder zu schwache DHE-Parameter führen zu Ablehnung durch Policies; in TLS-Scannern fällt dies als fehlendes Forward Secrecy oder als schwache DH-Gruppe auf.
• Zertifikats-/Signatur-Policy: Ungeeignete Signaturalgorithmen oder Ketten (z. B. unzureichende Hash-/Key-Policy) verursachen Abbrüche unabhängig von der TLS-Version; in der Praxis kollidiert das oft mit restriktiven Unternehmens-Truststores.

Best-Practice-Sicherheitslage: Versionen gezielt zulassen, Downgrades vermeiden

Aus sicherheitstechnischer Sicht gilt TLS 1.3 als bevorzugte Zielkonfiguration, TLS 1.2 als kompatible Ergänzung. TLS 1.0 und TLS 1.1 sollten nicht mehr angeboten werden, da sie regelmäßig Compliance-Anforderungen verletzen und operative Risiken erzeugen. Innerhalb von TLS 1.2 entscheidet die konkrete Cipher-Suite- und Key-Exchange-Auswahl über das reale Niveau: (EC)DHE plus AEAD ist der Erwartungswert; RSA-Key-Exchange und CBC-basierte Suiten erhöhen das Risiko und verkomplizieren die Bewertung.

Beim Übergang zu TLS 1.3 verschiebt sich der Schwerpunkt von der „langen Cipher-Liste“ hin zu sauberen Defaults und konsequenter Deaktivierung von Legacy-Pfaden. Dort, wo 0-RTT technisch attraktiv erscheint, muss der Umgang mit Replay (Applikationslogik, Cache- und Authentisierungssemantik, Rate-Limits) ausdrücklich mitgedacht werden; andernfalls bleibt 0-RTT deaktiviert. Eine robuste Sicherheitslage entsteht weniger durch maximale Auswahl, sondern durch eine kleine Menge explizit erlaubter Versionen und Algorithmen, die gängige Clients sicher treffen und gleichzeitig Angriffsflächen minimieren.

Cipher Suites und kryptografische Bausteine: Key Exchange, Signaturen, Hash/PRF, (AE)AD, Kurven und typische Fallstricke

Cipher Suites beschreiben die konkreten kryptografischen Bausteine, die ein TLS-Handshake und der nachfolgende Datentransport verwenden. Je nach Protokollversion steckt die vollständige Kryptografie in der Suite (v. a. TLS 1.2 und älter) oder wird weitgehend vom Protokoll fest vorgegeben (TLS 1.3), während die Suite dort primär den AEAD-Algorithmus und die Hash-Funktion für HKDF signalisiert. Für die Bewertung einer Konfiguration zählt daher nicht nur „starkes AES“, sondern das Zusammenspiel aus Schlüsselaustausch, Authentisierung, Hash/PRF, symmetrischer Verschlüsselung und Betriebsmodus sowie die Parameterwahl bei elliptischen Kurven.

Namensschema und Bausteine: Was eine Cipher Suite tatsächlich festlegt

Bei TLS 1.2 kodiert der Suite-Name typischerweise (1) das Key-Exchange-Verfahren, (2) den Signaturalgorithmus bzw. den Zertifikatstyp (historisch oft „RSA“ als Zertifikatstyp), (3) den symmetrischen Algorithmus samt Modus und (4) den Hash für HMAC/PRF. Beispiel: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 steht für ECDHE als (ephemeren) Schlüsselaustausch, ein RSA-basiertes Serverzertifikat für die Authentisierung, AES-128 im GCM-Modus als AEAD und SHA-256 für PRF/HMAC.

Bei TLS 1.3 sind Key Exchange und Signaturen entkoppelt von der Suite. Die Cipher Suite benennt nur AEAD und den Hash für HKDF (z. B. TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_256_GCM_SHA384). Welche Gruppe/Kurve (z. B. X25519 oder P-256) für (EC)DHE genutzt wird und welcher Signaturalgorithmus (z. B. RSA-PSS oder ECDSA) zum Einsatz kommt, wird über separate Extensions ausgehandelt.

Key Exchange und Forward Secrecy: ECDHE, DHE, statisches RSA und Parameterhygiene

Schlüsselaustausch entscheidet darüber, ob kompromittierte Langzeitschlüssel (z. B. private Keys des Serverzertifikats) rückwirkend aufgezeichneten Traffic entschlüsseln können. Ephemere Diffie-Hellman-Verfahren (ECDHE, DHE) liefern Forward Secrecy, weil Sitzungsschlüssel aus kurzfristigen Geheimnissen abgeleitet werden. Der historische RSA-Key-Exchange (Suite enthält RSA ohne DHE/ECDHE) gilt in modernen Konfigurationen als nicht akzeptabel und ist in TLS 1.3 nicht mehr vorhanden.

Bei DHE hängt die Sicherheit stark an den DH-Parametern. Zu kleine oder wiederverwendete Gruppen schwächen den Handshake; außerdem kostet DHE im Vergleich zu ECDHE deutlich mehr CPU. In der Praxis dominiert ECDHE mit gut unterstützten Kurven. Für ECDHE sind die Gruppen-/Kurvenwahl und die Implementierung der Aushandlung relevant: X25519 bietet robuste Parameterwahl und gute Performance; NIST P-256 bleibt aus Kompatibilitätsgründen verbreitet (und ist in vielen Compliance-Profilen der „kleinste gemeinsame Nenner“).

• Forward Secrecy sicherstellen: Ausschließlich Suiten mit ECDHE (TLS 1.2) bzw. TLS 1.3 aktivieren; statischen RSA-Key-Exchange (z. B. TLS_RSA_WITH_AES_128_GCM_SHA256) nicht anbieten.
• DHE-Parameter vermeiden oder sauber pflegen: Wenn DHE aus Kompatibilitätsgründen angeboten wird, müssen ausreichend starke Gruppen und konsistente Parameter verwendet werden; „Default-DH-Params“ alter Distributionen sind ein typischer Risikofaktor.
• Gruppenprioritäten prüfen: Für ECDHE sinnvolle Reihenfolge der Supported Groups setzen (z. B. X25519 vor P-256), ohne exotische oder schwach unterstützte Gruppen zu aktivieren.

Signaturen, Zertifikatstypen und typische Kompatibilitätskanten

Die Serverauthentisierung erfolgt über Zertifikate und die Signatur im Handshake. Bei TLS 1.2 wird das Zusammenspiel aus Zertifikatstyp und Suite-Namen häufig missverstanden: Ein ..._RSA_... in der Suite bezeichnet meist das Zertifikat/Signaturverfahren (Server besitzt ein RSA-Zertifikat), nicht den Key-Exchange. ECDHE bleibt auch mit RSA-Zertifikat ECDHE. In TLS 1.3 wählen Clients und Server die Signaturalgorithmen über „Signature Schemes“; RSA-PSS ist der Standard für moderne RSA-Setups, während ECDSA mit P-256/P-384 verbreitet bleibt.

Häufige Fallstricke entstehen, wenn Zertifikatsketten nicht sauber ausgeliefert werden oder wenn Signaturalgorithmen angeboten werden, die Clients nicht akzeptieren. SHA-1-basierte Signaturen sind in aktuellen Browsern und Betriebssystemen für öffentliche PKI praktisch ausgeschlossen. Ebenso kann ein reines ECDSA-Setup in speziellen Legacy-Umgebungen scheitern; daher werden in der Praxis oft RSA-Zertifikate oder Dual-Stack-Strategien eingesetzt, sofern die TLS-Implementierung mehrere Zertifikate/Chains abhängig vom ClientHello unterstützen kann.

Hash/PRF und AEAD: Warum SHA-256 nicht „die Verschlüsselung“ ist

Hash-Funktionen erfüllen in TLS mehrere Rollen: In TLS 1.2 steuern sie die PRF für die Schlüsselableitung und HMAC in Nicht-AEAD-Suiten; in TLS 1.3 bestimmen sie zusammen mit HKDF die gesamte Schlüsselhierarchie. Der Hash ist damit sicherheitskritisch, aber er verschlüsselt keine Nutzdaten. Die eigentliche Vertraulichkeit und Integrität im Record-Layer liefern AEAD-Verfahren wie AES-GCM oder ChaCha20-Poly1305.

AES-GCM ist in Hardware-unterstützten Umgebungen oft sehr schnell, reagiert aber empfindlich auf Nonce-/IV-Fehlgebrauch; korrekt implementierte TLS-Stacks vermeiden das durch streng definierte Nonce-Konstruktionen. ChaCha20-Poly1305 ist besonders auf Systemen ohne AES-Beschleunigung performant und gilt als robuste Alternative. Dagegen sind CBC-basierte Suiten in TLS 1.2 historisch problembehaftet und sollten in modernen Browser- und Serverlandschaften nicht mehr benötigt werden; wo sie ausnahmsweise für Altgeräte aktiviert bleiben, müssen sie streng nachrangig und mit korrekten Mitigations im Stack betrachtet werden.

• TLS 1.3-Suiten fokussieren: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256 decken typische Anforderungen ab; zusätzliche Varianten erhöhen Komplexität ohne Sicherheitsgewinn.
• CBC- und Legacy-HMAC reduzieren: Suiten mit _CBC_ sowie veraltete Hash-Kombinationen (insbesondere SHA-1/MD5 in sehr alten Stacks) nicht anbieten; wenn technische Zwänge bestehen, nur in separaten Endpunkten und mit klarer Risikoakzeptanz.
• Reihenfolge nicht überschätzen: Bei TLS 1.3 bestimmt in der Regel der Client die Suiteauswahl aus der Servermenge; bei TLS 1.2 kann Serverpräferenz relevant sein und sollte in Serverkonfigurationen kontrolliert werden.

Kurven, Gruppen und „Hidden Defaults“: Wenn starke Suiten dennoch schwach werden

Selbst bei ausschließlich modernen Suiten kann eine Konfiguration durch Parameterdefaults angreifbar oder unnötig inkompatibel werden. Typisch sind unklare ECDHE-Gruppenprioritäten, aktivierte Sondergruppen ohne Client-Support oder DHE-Parameter, die aus alten Templates übernommen wurden. Zusätzlich wirkt sich aus, ob der Server 0-RTT (Early Data) in TLS 1.3 zulässt; Early Data kann Replay-Risiken für nicht idempotente Requests erzeugen und gehört eher in spezifische, bewusst designte Szenarien als in generische Web-Setups.

Praktisch relevant ist außerdem die Trennung zwischen „Cipher Suite“ und „Zertifikats-/Signaturalgorithmus“: Ein Server kann perfekte TLS-1.3-Suiten anbieten, aber mit einer unpassenden Zertifikatskette (fehlende Intermediate CAs, falsche SANs) oder einem nicht akzeptierten Signaturalgorithmus dennoch Fehlerbilder erzeugen, die in Browsern als generische TLS-Probleme erscheinen.

Praxis: Tabellen, Browserwarnungen und Best-Practice-Konfigurationen für Nginx/Apache/IIS inklusive Migrationspfaden

Lesbare Ist-Analyse: Protokolle, Cipher Suites und Serverpräferenzen konsistent erfassen

In der Praxis scheitert eine TLS-Härtung selten an der Theorie, sondern an uneinheitlichen Messpunkten: Reverse Proxies, Load Balancer und Applikationsserver liefern oft unterschiedliche TLS-Parameter aus. Für belastbare Entscheidungen sollten stets drei Ebenen getrennt betrachtet werden: (1) angebotene Protokollversionen, (2) angebotene Cipher Suites (inklusive Gruppen/Curves bei ECDHE) und (3) die effektive Auswahlregel, also ob der Server die Reihenfolge vorgibt oder der Client.

Für eine reproduzierbare Erfassung empfiehlt sich eine Kombination aus aktiven Tests (Handshake gegen den Endpunkt) und Konfigurationssicht (tatsächlich geladene Dateien/Policies). Ein häufiger Befund: TLS 1.3 ist aktiviert, aber TLS 1.2 bleibt mit schwachen Suites offen; oder der Server unterstützt zwar moderne ECDHE-Suites, bevorzugt aber aufgrund der Reihenfolge dennoch weniger geeignete Varianten. Zusätzlich muss klar sein, ob HTTP/2 oder HTTP/3 verwendet wird, da bestimmte TLS-Parameter (z. B. ALPN) indirekt auf Fehlkonfigurationen hinweisen können.

• OpenSSL-Handshake (Version erzwingen): openssl s_client -connect example.tld:443 -servername example.tld -tls1_2
openssl s_client -connect example.tld:443 -servername example.tld -tls1_3
• Cipher-Suite-Aushandlung nachvollziehen: openssl s_client -connect example.tld:443 -servername example.tld -tls1_2 -cipher 'ECDHE:!aNULL:!eNULL'
• Zertifikatskette und SNI prüfen: openssl s_client -connect example.tld:443 -servername example.tld -showcerts
• HTTP/2-ALPN sichtbar machen: openssl s_client -connect example.tld:443 -servername example.tld -alpn h2,http/1.1

Tabellarische Leitplanken: sichere Parameter nach TLS-Version und Eignung

Die folgende Übersicht dient als praxisnaher Referenzrahmen für Webserver-Endpunkte im Internetbetrieb. Sie trennt TLS 1.3 (Cipher Suites fest im Protokoll definiert) von TLS 1.2 (Suite-Auswahl vollständig serverseitig konfigurierbar). Bei TLS 1.2 gilt: ECDHE für Forward Secrecy, AEAD (AES-GCM oder ChaCha20-Poly1305) für Authenticated Encryption, RSA-Schlüsselaustausch vermeiden. Wo ChaCha20 verfügbar ist, wird es vor allem auf Geräten ohne AES-NI relevant.

Typische Browserwarnungen und ihre technischen Ursachen

Browser abstrahieren TLS-Fehler stark; hinter einer Warnseite stehen meist wenige, klar abgrenzbare Ursachen. In Incident-Situationen hilft eine Zuordnung von Fehlermeldung zu Handshake-Phase: Zertifikatsvalidierung (Chain/Name/Time), Protokoll-/Suite-Negotiation oder Policy-Verstöße (z. B. HSTS). Besonders tückisch sind Änderungen an Zwischenzertifikaten oder fehlende Intermediates nach einem Zertifikatswechsel; viele Clients haben keine identische Cache-Lage.

• „NET::ERR_CERT_AUTHORITY_INVALID“: Unvollständige Kette oder nicht vertrauenswürdige CA; Kettenausgabe prüfen mit openssl s_client -connect example.tld:443 -servername example.tld -showcerts.
• „NET::ERR_CERT_COMMON_NAME_INVALID“: SAN/CN passt nicht zum Hostnamen oder falsches Zertifikat ohne SNI-Auswertung; Gegenprobe mit openssl s_client -connect example.tld:443 -servername example.tld.
• „NET::ERR_CERT_DATE_INVALID“: abgelaufenes Zertifikat oder Client-Uhrzeit falsch; Serverseitig Gültigkeit sichtbar mit openssl x509 -in cert.pem -noout -dates.
• „ERR_SSL_VERSION_OR_CIPHER_MISMATCH“: Client und Server finden keinen gemeinsamen Nenner (z. B. nur TLS 1.0/1.1 oder nur veraltete Suites); reproduzierbar mit openssl s_client -connect example.tld:443 -tls1_2 und gezielter Suite-Vorgabe über -cipher.
• HSTS-Block (kein Override möglich): Zertifikatsfehler auf einer Domain mit aktivem HSTS; Korrektur erfordert gültige Kette/Name, nicht nur das „Akzeptieren“ im Browser.

Best-Practice-Konfigurationen: Nginx, Apache httpd und IIS (TLS 1.2/1.3)

Die Konfiguration muss zur TLS-Implementierung der Plattform passen. TLS 1.3-Cipher-Suites werden bei Nginx/Apache je nach Build über OpenSSL gesteuert und sind in vielen Setups nicht über dieselben Direktiven wie TLS 1.2 verwaltbar. Für TLS 1.2 bleibt eine kuratierte Suite-Liste zentral; zusätzlich sollte der Server die Reihenfolge vorgeben, um schwächere, aber noch kompatible Suites nicht versehentlich zu bevorzugen (sofern die jeweilige TLS-Bibliothek/Serverversion Serverpräferenz tatsächlich durchsetzt). OCSP Stapling und eine vollständige Zertifikatskette gehören in produktive Internetprofile, sind aber abhängig von korrekter Resolver- und CA-Responder-Erreichbarkeit.

• Nginx (Protokolle, Reihenfolge, TLS 1.2 Suites): ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
• Nginx (OCSP Stapling, wenn eingesetzt): ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 9.9.9.9 valid=300s;
• Apache httpd (TLS 1.2/1.3, Suite-Policy): SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder on
• Apache httpd (Zertifikatskette, je nach Distribution/Version): SSLCertificateFile /path/to/cert.pem
SSLCertificateKeyFile /path/to/privkey.pem
SSLCertificateChainFile /path/to/chain.pem
• IIS / SChannel (Protokolle via Registry, Beispiel TLS 1.2 aktiv): HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server\Enabled
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server\DisabledByDefault
• IIS / SChannel (Cipher Suites per Gruppenrichtlinie): gpedit.msc → Computerkonfiguration → Administrative Vorlagen → Netzwerk → SSL-Konfigurationseinstellungen → SSL-Cipher Suites-Reihenfolge

Bei IIS bestimmt SChannel die tatsächlich nutzbaren Cipher Suites; die Webserver-Konfiguration allein genügt nicht. In Windows-Umgebungen sollten Protokolle und Suites zentral per GPO oder Configuration Management verwaltet werden, um Drift zwischen Servern zu vermeiden. Für TLS 1.3 gilt zusätzlich: Verfügbarkeit und Details hängen von Windows-Version und Patchstand sowie dem eingesetzten HTTP-Stack (HTTP.sys) ab; eine Validierung per externem Handshake-Test bleibt daher obligatorisch.

Migrationspfade: von Legacy zu modernen Profilen ohne Ausfälle

Eine Migration sollte in Stufen erfolgen, damit Kompatibilitätsabbrüche messbar bleiben. Bewährt hat sich eine Telemetrie-Phase (Zugriffslogs, Client-Mix, Supportfälle) gefolgt von einer kontrollierten Deaktivierung veralteter Protokolle. Kritisch ist die Reihenfolge: zuerst schwache Cipher Suites entfernen (insbesondere RSA-Key-Exchange, 3DES, CBC), danach TLS 1.1 und TLS 1.0 deaktivieren. TLS 1.3 kann parallel aktiviert werden, sofern Middleware (WAF, TLS-Terminatoren) den Traffic korrekt verarbeitet.

• Stufe 1 (Aufräumen ohne Protokollbruch): RSA-Key-Exchange entfernen, nur AEAD-Suites zulassen; in Nginx/Apache über ssl_ciphers/SSLCipherSuite, in IIS über SSL-Cipher Suites-Reihenfolge.
• Stufe 2 (TLS 1.0/1.1 beenden): Protokolle reduzieren auf TLSv1.2 und TLSv1.3; bei Apache SSLProtocol -all +TLSv1.2 +TLSv1.3, bei Nginx ssl_protocols TLSv1.2 TLSv1.3;, bei IIS über ...SCHANNEL\Protocols\TLS 1.0/TLS 1.1 deaktivieren.
• Stufe 3 (TLS 1.3 priorisieren): TLS 1.3 aktiviert lassen, TLS 1.2 Suite-Liste minimal halten; Regressionstests mit openssl s_client und zusätzlich mit mindestens einem nicht-OpenSSL-Client (z. B. systemeigene TLS-Stacks).
• Stufe 4 (Betrieb absichern): Change-Fenster, Rollback-Plan, Monitoring auf Handshake-Fehler (HTTP-Status allein genügt nicht); Log-Auswertung auf TLS-Alerts und plötzliche Abbrüche nach Konfigurationswechseln.