TLS: Protokoll, Zertifikatsprüfung und Betrieb

Transport Layer Security (TLS) schützt eine einzelne Verbindung zwischen zwei Endpunkten. Zuerst einigen sich Client und Server auf kryptografische Verfahren und Schlüssel, danach laufen SMTP, LDAP, HTTP oder ein anderes Anwendungsprotokoll durch diesen geschützten Kanal. TLS verhindert auf dieser Verbindung Mitlesen und unbemerkte Änderungen und authentisiert mindestens den Server. Es bestätigt aber weder den Absender einer E-Mail noch garantiert es, dass der nächste SMTP-Hop ebenfalls TLS verwendet (RFC 9846, Abschnitt 1, RFC 3207, Abschnitt 6).

Im Betrieb müssen deshalb mehrere Prüfungen nacheinander gelingen: Der richtige Host und Port müssen erreichbar sein, Client und Server brauchen gemeinsame TLS-Parameter, die Zertifikatskette muss zu einem vertrauten Anker führen und der angesprochene Name muss im Zertifikat stehen. Erst danach beginnt das eigentliche Anwendungsprotokoll. Der Artikel folgt genau diesem Ablauf und zeigt an jeder Stelle, was ein Administrator beobachten, konfigurieren und sichern muss.

Position im Protokollstapel

Im üblichen Serverbetrieb sitzt TLS zwischen TCP und dem Anwendungsprotokoll. TCP liefert den geordneten Datenstrom; TLS schützt ihn; SMTP, LDAP, IMAP oder HTTP legen fest, wann TLS startet und welcher Servername erwartet wird. Diese Einbettung erklärt, weshalb ein offener Port noch keinen erfolgreichen TLS-Test darstellt und ein erfolgreicher Handshake noch keinen funktionierenden Mail- oder Verzeichnisdienst beweist (RFC 9846, Abschnitt 1).

QUIC ist eine wichtige Ausnahme vom klassischen «TLS über TCP»-Bild: Es verwendet den TLS-1.3-Handshake, aber nicht den TLS Record Layer; QUIC schützt seine eigenen Pakete mit aus TLS abgeleiteten Schlüsseln (RFC 9001). Für die hier betrachteten Mail- und Verzeichnisprotokolle bleibt der TCP-basierte TLS-Kanal das relevante Modell.

Architektur: Handshake, Record Layer und Alerts

TLS erledigt zwei Aufgaben nacheinander. Im Handshake Protocol handeln die Gegenstellen Parameter aus, authentisieren sich und erzeugen gemeinsames Schlüsselmaterial. Danach zerlegt das Record Protocol die Nutzdaten in geschützte Records. Alerts melden Protokollfehler oder einen geordneten Abschluss; bei einem abrupten Netz- oder Prozessfehler kann die TCP-Verbindung allerdings auch ohne verwertbaren Alert enden (RFC 9846, Abschnitte 4 bis 6).

Diese Trennung ist im Betrieb entscheidend. Ein Zertifikatsfehler gehört zur Authentisierungsphase des Handshakes. Ein bad_record_mac oder decrypt_error betrifft kryptografische Verarbeitung. Ein Timeout ohne ServerHello deutet dagegen häufig auf Protokollverwechslung, Filterung, einen falschen Port oder einen Server hin, der zunächst einen Klartextdialog und ein STARTTLS-Kommando erwartet.

TLS-1.3-Handshake Schritt für Schritt

Der vollständige TLS-1.3-Handshake lässt sich als Gespräch lesen: Der Client macht ein Angebot, der Server wählt daraus aus, weist seine Identität nach und beide Seiten bestätigen das bisherige Protokoll. Bereits nach dem ServerHello sind die weiteren Handshake-Nachrichten geschützt. Mit den beidseitigen Finished-Nachrichten steht schliesslich fest, dass beide Parteien dasselbe Transkript und dieselben Geheimnisse besitzen (RFC 9846, Abschnitt 2).

Der Ablauf im Detail:

1. Der ClientHello bietet unter anderem unterstützte TLS-Versionen, Cipher Suites, Signaturalgorithmen und kryptografische Gruppen an. Ein key_share enthält gewöhnlich bereits den ephemeren öffentlichen Anteil des Clients. SNI kann den gewünschten Servernamen, ALPN mögliche Anwendungsprotokolle transportieren.
2. Der ServerHello wählt Version, Cipher Suite und Key Share. Aus Client- und Serveranteil entsteht das gemeinsame (EC)DHE-Geheimnis. Gibt es keine passende vorab gesendete Gruppe, kann der Server mit HelloRetryRequest einen neuen ClientHello verlangen.
3. EncryptedExtensions bestätigt weitere ausgehandelte Erweiterungen. Fordert der Server ein Clientzertifikat, folgt zusätzlich CertificateRequest.
4. Certificate transportiert das Leaf-Zertifikat und normalerweise die für den Client nötigen Intermediate-Zertifikate. CertificateVerify signiert das Handshake-Transkript mit dem zum Leaf-Zertifikat gehörenden privaten Schlüssel. Damit beweist der Server Schlüsselbesitz; das Zertifikat allein beweist ihn nicht.
5. Finished ist ein MAC über das bisherige Transkript und bestätigt die abgeleiteten Handshake-Geheimnisse. Der Client validiert Parameter, Zertifikatspfad und Dienstidentität und sendet anschliessend sein Finished, bei angeforderter gegenseitiger Authentisierung zusätzlich Certificate und CertificateVerify.
6. Für Anwendungsdaten werden getrennte Traffic Secrets abgeleitet. Spätere NewSessionTicket-Nachrichten erlauben eine PSK-basierte Wiederaufnahme, ohne dass der Server das ursprüngliche Zertifikat in jedem Folge-Handshake erneut senden muss.

Die beobachtete Zahl der Round Trips hängt deshalb von DNS, TCP, vollständigem oder wiederaufgenommenem TLS-Handshake, HelloRetryRequest und der Anwendung ab. Ein Packet Capture muss diese Phasen getrennt messen; «TLS war langsam» ist ohne diese Aufteilung keine Diagnose.

Schlüsselplan und Record Layer

Aus dem vereinbarten (EC)DHE- oder PSK-Material erzeugt TLS 1.3 nicht einen einzigen Sitzungsschlüssel, sondern mit HKDF mehrere getrennte Geheimnisse. Handshake, Anwendungsdaten, Exporte und spätere Wiederaufnahme verwenden eigenes Material; zusätzlich besitzen Client und Server für jede Richtung getrennte Schlüssel und Initialisierungsvektoren. Diese Aufteilung ist für Analyse und Incident Response wichtig, weil ein offengelegter Record-Schlüssel nicht automatisch alle Phasen und Richtungen entschlüsselt (RFC 9846, Abschnitt 7.1).

Der Record Layer verwendet ausschliesslich Authenticated Encryption with Associated Data (AEAD). Die Cipher Suite benennt in TLS 1.3 den AEAD-Algorithmus und den Hash für HKDF; Zertifikatstyp, Signaturalgorithmus und Key-Exchange-Gruppe werden separat ausgehandelt. Das ist anders als bei TLS 1.2, wo Namen wie TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 mehrere Entscheidungen in einer Suite bündeln.

0-RTT spart bei einer Wiederaufnahme einen Round Trip, besitzt aber schwächere Replay-Eigenschaften. Ein Server muss daher anwendungsabhängig entscheiden, welche frühen Daten er akzeptiert. Für zustandsverändernde Admin-, Mail- oder Verzeichnisoperationen darf geringe Latenz nicht mit Replay-Sicherheit verwechselt werden (RFC 9846, Abschnitte 2.3 und 8).

X.509-Zertifikat und privater Schlüssel

Ein X.509-Zertifikat ist die signierte Beschreibung eines öffentlichen Schlüssels. Es nennt unter anderem Aussteller, Gültigkeitszeitraum, erlaubte Verwendungen und die Namen, für die der Schlüssel eingesetzt werden darf. Der dazugehörige private Schlüssel ist nicht Bestandteil des Zertifikats und muss beim Betreiber geschützt bleiben. RFC 5280 definiert das dafür verwendete PKIX-Profil mit Feldern wie Key Usage, Extended Key Usage, Basic Constraints und Subject Alternative Name (RFC 5280, Abschnitt 4).

X.509 wird binär mit ASN.1 DER codiert. Die häufig sichtbaren Zeilen BEGIN CERTIFICATE und END CERTIFICATE sind eine Base64-basierte Textumhüllung, die RFC 7468 beschreibt. Ein PKCS #12-Container kann dagegen privaten Schlüssel, Zertifikatskette und weitere Attribute gemeinsam transportieren (RFC 7468, RFC 7292). Dateiendungen wie .cer, .crt, .pem, .p12 oder .pfx sind Konventionen, aber kein verlässlicher Beweis für Inhalt oder Encoding.

Wichtige Erweiterungen haben unterschiedliche Aufgaben:

Zertifikatspfad und Vertrauensgrenze

Mit seinem Leaf-Zertifikat sendet ein Server normalerweise die nötigen Intermediate-Zertifikate. Der Client versucht daraus einen Pfad zu einer Root-CA zu bauen, der er bereits lokal vertraut. Genau dieser letzte Punkt entscheidet: Eine vom Server mitgelieferte Root-CA wird nicht allein dadurch vertrauenswürdig. Der Truststore des tatsächlich verbindenden Prozesses legt fest, welche Vertrauensanker gelten (RFC 5280, Abschnitt 6).

Pfadbau und Pfadvalidierung sind mehr als drei einfache Häkchen. Der Client muss unter anderem Signaturen, Gültigkeitsintervalle, Basic Constraints, Path Length, Name Constraints, Key Usage, Extended Key Usage, kritische Erweiterungen, Richtlinien und gegebenenfalls Widerruf prüfen. Anschliessend folgt die protokollspezifische Dienstidentität. Verschiedene Clients können aus demselben Leaf-Zertifikat unterschiedliche gültige Pfade konstruieren, weil ihre Truststores, AIA-Nachladung, Cross-Signatures und Algorithmusregeln abweichen.

Der Begriff Truststore bezeichnet deshalb keinen universellen Ort. Eine Windows-Anwendung kann Schannel und den Windows-Zertifikatspeicher verwenden, eine Java-Anwendung JSSE mit eigener cacerts- oder Applikationsdatei, ein Container ein eingebautes CA-Bundle und eine Appliance einen proprietären Store. Selbst auf demselben Host können zwei Prozesse dem gleichen Server unterschiedlich vertrauen. Bei jeder Störung muss der tatsächlich validierende Prozess und dessen Truststore identifiziert werden.

Widerruf ist eine zusätzliche Policyentscheidung. CRLs verteilen signierte Listen widerrufener Zertifikate; OCSP beantwortet Statusanfragen für einzelne Zertifikate. Ob ein Client prüft, wie er bei Timeout reagiert und ob er OCSP Stapling nutzt, hängt von Bibliothek und Anwendung ab (RFC 5280, Abschnitt 5, RFC 6960). «Zertifikat ist zeitlich gültig» bedeutet daher nicht automatisch «Zertifikat wird von diesem Client akzeptiert».

Dienstidentität: SAN, Referenz-ID und SNI

Nachdem der Pfad akzeptiert wurde, prüft der Client den Namen des Dienstes. Ausgangspunkt ist die Referenzidentität, meist der konfigurierte Hostname oder der Hostanteil einer URL. Sie muss zu einem passend typisierten Eintrag im Subject Alternative Name des Leaf-Zertifikats passen. Für DNS-Namen gilt dNSName, für direkt konfigurierte IP-Adressen iPAddress; der frei formulierte Common Name ist keine moderne Ausweichlösung. Wildcards dürfen nur das vollständige linke Label ersetzen (RFC 9525, Abschnitte 4 und 6).

Server Name Indication (SNI) ist davon zu trennen. Der Client sendet den gewünschten Servernamen im ClientHello, damit ein gemeinsamer Listener das passende Zertifikat und die passende virtuelle Konfiguration wählen kann. SNI sagt dem Server, was der Client erreichen will; es ersetzt weder den SAN-Vergleich noch die Pfadvalidierung (RFC 6066, Abschnitt 3). Ein Test ohne SNI kann deshalb das Default-Zertifikat zeigen, obwohl der produktive Client ein anderes erhält.

Application-Layer Protocol Negotiation (ALPN) lässt Client und Server ein höheres Protokoll innerhalb des TLS-Handshakes auswählen. Es ist vor allem für HTTP und QUIC sichtbar, aber konzeptionell ebenfalls keine Zertifikatsprüfung (RFC 7301).

Implizites TLS und STARTTLS

Wann der Handshake beginnt, bestimmt das Anwendungsprotokoll. Bei implizitem TLS folgt der ClientHello unmittelbar auf den TCP-Aufbau. Bei STARTTLS sprechen beide Seiten zuerst Klartext und wechseln erst nach einem protokollspezifischen Befehl auf TLS. Wer einen ClientHello direkt an einen STARTTLS-Port sendet, verwendet deshalb zwar TLS, aber am falschen Punkt des Dialogs.

Die Portzuordnungen stammen aus der IANA Service Name and Port Number Registry; die Semantik ergibt sich aus dem jeweiligen Anwendungsstandard. Port 465 ist daher nicht pauschal «SMTPS für Server-zu-Server-Zustellung», sondern der registrierte Implicit-TLS-Pfad für Submission.

SMTP STARTTLS definiert einen besonders wichtigen Zustandswechsel. Vor dem Upgrade sind EHLO-Antwort und STARTTLS-Angebot manipulierbar. Nach dem Handshake müssen beide Seiten vorher gelerntes SMTP-Wissen verwerfen, und der Client sendet erneut EHLO (RFC 3207, Abschnitt 4.2). Für LDAP ist StartTLS eine Extended Operation innerhalb der LDAP-Session; sie ist nicht dasselbe wie ein neuer TCP-Port (RFC 4511, Abschnitt 4.14).

TLS-Policy bei SMTP

Bei SMTP auf Port 25 ist TLS häufig opportunistisch: Der sendende MTA verschlüsselt, wenn die Gegenstelle STARTTLS anbietet und die lokale Richtlinie den Handshake akzeptiert. Ohne zusätzliche Policy kann ein Angreifer das Angebot entfernen oder den Handshake stören. Dann muss der Absender-MTA entscheiden, ob er unverschlüsselt zustellt, später erneut versucht oder endgültig abbricht. RFC 3207 macht damit klar, dass ein geschützter SMTP-Hop kein Ende-zu-Ende-Schutz der Nachricht ist.

Zwei Mechanismen können die Empfängerdomain und die TLS-Anforderung stärker binden:

• DANE for SMTP veröffentlicht TLSA-Daten unter DNSSEC und leitet die zu prüfende Identität aus dem MX-Pfad ab. Ein validierender Resolver und eine intakte DNSSEC-Kette werden damit Teil der Vertrauensbasis (RFC 7672).
• MTA-STS veröffentlicht eine Richtlinie über DNS und HTTPS. Sie nennt zulässige MX-Muster und verlangt PKIX-validiertes TLS während der Policy-Lebensdauer (RFC 8461). SMTP TLS Reporting meldet aggregierte Erfolgs- und Fehlerbilder dieser Richtlinien (RFC 8460).

Diese Modelle sind nicht austauschbar. DANE verankert die Aussage in DNSSEC und TLSA; MTA-STS verwendet Web-PKIX und eine per HTTPS bezogene Policy. Ein Admin muss deshalb neben Zertifikat und Cipher auch DNS, MX-Auswahl, Policycache und Berichtskanal beobachten.

Gegenseitige TLS-Authentisierung

Mutual TLS (mTLS) ergänzt den normalen Servernachweis um ein Clientzertifikat. Der Server fordert es mit CertificateRequest an; der Client sendet seine Kette und beweist mit CertificateVerify den Besitz des privaten Schlüssels. Danach prüft der Server Pfad, Gültigkeit, Extended Key Usage und seine lokale Zuordnung. Das Zertifikat identifiziert zunächst einen Schlüsselinhaber. Welche Anwendungskonto-, LDAP- oder SMTP-Relayrechte daraus entstehen, entscheidet weiterhin die Anwendung.

In heterogenen Umgebungen entstehen häufig asymmetrische Trust-Probleme: Der Client vertraut der Server-CA, der Server aber nicht der Client-CA; der Server fordert nur bestimmte Issuer an; das Clientzertifikat besitzt nur serverAuth; oder ein Load Balancer beendet TLS und reicht keine verifizierte Clientidentität an das Backend weiter. Ein erfolgreicher serverauthentisierter Handshake ist daher kein Beleg für funktionierendes mTLS.

Schlüssel-, Zertifikats- und Erneuerungsbetrieb

Ein Zertifikatswechsel ist mehr als das Ersetzen einer Datei. Schlüssel, Zertifikat, Intermediate-Kette, Listenerbindung und Rolloutzustand müssen zusammenpassen. Ein belastbarer Lebenszyklus umfasst mindestens:

1. Inventar: Dienstname, Port, Startmodell, terminierender Prozess, erwartete SANs, Issuer, Seriennummer, Fingerprint, notBefore/notAfter, Key Store, Truststore und verantwortliche Automation erfassen.
2. Schlüsselerzeugung: neues Schlüsselpaar im vorgesehenen Software-, TPM- oder HSM-Kontext erzeugen. Private Schlüssel bleiben vertraulich und benötigen Schutz, Zugriffskontrolle und je nach Recovery-Modell eine dokumentierte Sicherungs- oder Neu-Ausstellungsstrategie (NIST SP 800-57 Part 1 Rev. 5).
3. Antrag und Ausstellung: CSR mit korrekten Identitäten und Parametern erzeugen; CA-Policy und erforderliche Nachweise erfüllen. ACME standardisiert die automatisierte Bestellung und Erneuerung, garantiert aber noch keine korrekte Dienstbindung (RFC 8555).
4. Installation: Leaf, passendes Intermediate-Bundle und privaten Schlüssel in das vom Prozess tatsächlich gelesene Format bringen. Dateirechte, Passwortzugriff und Key-Pair-Match prüfen.
5. Aktivierung: Dienst reloaden oder Bindung atomar umschalten. Bei Cluster, Load Balancer und mehreren Protokollrollen jeden TLS-Terminator separat behandeln.
6. Validierung: extern und intern mit produktivem SNI, Port und STARTTLS-Modus prüfen; gelieferte Kette, SAN, Gültigkeit, Algorithmus, Policy und Anwendungstest erfassen.
7. Ablösung: altes Zertifikat erst entfernen, wenn alle Knoten das neue ausliefern und keine Abhängigkeit mehr auf Fingerprint oder alten Issuer zeigt. Bei Kompromittierung zusätzlich widerrufen und den privaten Schlüssel als kompromittiert behandeln.

Ein Backup muss zu diesem Modell passen. Ein exportierter öffentlicher Zertifikatsteil stellt keinen Dienst wieder her, wenn privater Schlüssel, Passwort, Providerbindung, ACL oder HSM-Objekt fehlt. Umgekehrt vergrössert jede ungeschützte Kopie des privaten Schlüssels die Angriffsfläche. Root- und Issuing-CA-Recovery, Server-Key-Recovery und schnelle Neuausstellung sind unterschiedliche Verfahren und dürfen nicht unter «Zertifikate sichern» zusammenfallen.

Öffentliche Web-PKI, interne Enterprise-PKI und selbst verwaltete Trust-Anker haben unterschiedliche Issuance- und Laufzeitregeln. Statt einen statischen Maximalwert als Betriebsziel zu verwenden, sollte Monitoring das konkrete notAfter jedes ausgelieferten Zertifikats messen und genügend Zeit für Ausstellung, Rollout, Validierung und Rollback einplanen.

Implementierungs- und Technologiestack

Welcher TLS-Stack tatsächlich arbeitet, hängt vom Prozess ab. Windows-Dienste können Schannel verwenden, Java-Anwendungen JSSE, Unix-Dienste OpenSSL oder GnuTLS und Appliances eine eigene Bibliothek. Damit ändern sich Truststore, unterstützte Verfahren, Diagnosewerkzeuge und Konfigurationsort, obwohl alle Gegenstellen «TLS» sprechen.

Darüber liegt die Anwendungskonfiguration. Ein Mailserver wählt Zertifikat und Policy möglicherweise pro Listener oder SNI-Namen; ein Reverse Proxy terminiert TLS vor dem Backend; ein Java-Produkt bringt ein eigenes JRE samt Truststore mit; ein Container-Image friert ein CA-Bundle zum Buildzeitpunkt ein. Betriebssystemweit «das Zertifikat installiert» ist deshalb ohne Prozess- und Bindungsnachweis keine belastbare Aussage.

Auch Algorithmusunterstützung ist eine Schnittmenge aus Protokollversion, Bibliothek, Kryptoprovider, Zertifikat, Clientangebot und lokaler Policy. Ein ECDSA-Zertifikat hilft nicht, wenn der Client die Signatur nicht unterstützt; ein TLS-1.3-Cipher-String ändert keine TLS-1.2-Suiten; eine systemweite Schannel-Einstellung steuert keine separat mitgelieferte OpenSSL- oder Java-Laufzeit. BCP 195 bietet die IETF-Sicherheitsleitlinie, die konkrete Aktivierung bleibt aber implementations- und lifecycleabhängig.

Diagnose vom Port bis zur Anwendung

Eine TLS-Diagnose beginnt deshalb nicht beim Zertifikat, sondern beim exakten Verbindungsweg. Zu jedem Test gehören Zielname, aufgelöste Adresse, Port, SNI, STARTTLS-Modus, Clientbibliothek, Truststore, Zeitpunkt und geltende Policy. Nur Tests mit denselben Parametern sind miteinander vergleichbar.

TCP-Erreichbarkeit getrennt prüfen

Test-NetConnection mail.example.ch -Port 25 -InformationLevel Detailed
Test-NetConnection directory.example.ch -Port 636 -InformationLevel Detailed

nc -vz mail.example.ch 25
nc -vz directory.example.ch 636

Test-NetConnection und nc prüfen hier nur Namensauflösung und TCP-Aufbau. Ein erfolgreicher Test sagt noch nichts über TLS-Version, Zertifikat, SNI oder Anwendung aus.

SMTP STARTTLS mit produktivem SNI testen

openssl.exe s_client -connect mail.example.ch:25 -starttls smtp `
  -servername mail.example.ch -verify_hostname mail.example.ch `
  -showcerts -verify_return_error

openssl s_client -connect mail.example.ch:25 -starttls smtp \
  -servername mail.example.ch -verify_hostname mail.example.ch \
  -showcerts -verify_return_error

openssl s_client ist ein Diagnoseclient, kein Beweis für die Policy des produktiven MTA. -starttls smtp führt den Klartextdialog bis zum Upgrade, -servername setzt SNI, -showcerts zeigt die vom Server gesendete Zertifikatsliste und -verify_return_error bricht bei einem Validierungsfehler ab. Für einen vollständigen Identitätstest sollte zusätzlich -verify_hostname mail.example.ch und der tatsächlich verwendete CA-Pfad angegeben werden. OpenSSL ist unter Windows kein eingebauter Systembestandteil; openssl.exe muss aus einer kontrollierten Installation stammen.

LDAP StartTLS und implizites TLS unterscheiden

openssl.exe s_client -connect directory.example.ch:636 `
  -servername directory.example.ch -verify_hostname directory.example.ch `
  -verify_return_error
openssl.exe s_client -connect directory.example.ch:389 -starttls ldap `
  -servername directory.example.ch -verify_hostname directory.example.ch `
  -verify_return_error

openssl s_client -connect directory.example.ch:636 \
  -servername directory.example.ch -verify_hostname directory.example.ch \
  -verify_return_error
openssl s_client -connect directory.example.ch:389 -starttls ldap \
  -servername directory.example.ch -verify_hostname directory.example.ch \
  -verify_return_error

Der erste Aufruf erwartet sofort TLS auf 636, der zweite führt auf 389 die LDAP StartTLS Extended Operation aus. Ein Erfolg des OpenSSL-Tests belegt noch nicht, dass die produktive LDAP-Bibliothek denselben Truststore, dieselbe Widerrufspolicy oder dieselbe Referenzidentität verwendet.

Zertifikatsdatei und Pfad lokal untersuchen

certutil.exe -dump server.cer
certutil.exe -verify -urlfetch -sslpolicy mail.example.ch server.cer
certutil.exe -store My

openssl x509 -in server.pem -noout -subject -issuer -serial -dates \
  -fingerprint -sha256 -ext subjectAltName,extendedKeyUsage
openssl verify -show_chain -CAfile roots.pem \
  -untrusted intermediates.pem server.pem

certutil verwendet für -verify die Windows-Zertifikatslogik und kann mit -sslpolicy einen Servernamen einbeziehen. openssl x509 zeigt Felder eines Zertifikats; openssl verify baut und prüft einen Pfad gegen die explizit angegebenen Trust Anchors und Intermediates. keytool ist für JVM-Key- und Truststores die passende offizielle Verwaltungs- und Inspektionsschnittstelle; ein Test mit OpenSSL ersetzt dessen Sicht nicht.

Fehlerbild einem Prüfschritt zuordnen

Wireshark kann ClientHello, ServerHello, Erweiterungen und Alerts sichtbar machen; ohne Sitzungsschlüssel bleiben Anwendungsdaten und viele TLS-1.3-Handshake-Nachrichten verschlüsselt. Ein Mitschnitt zeigt ausserdem nicht automatisch, welchen Truststore die Anwendung verwendet oder weshalb deren Policy einen Pfad verwirft.

Monitoring und Betriebskriterien

Ein Portcheck und eine Warnung vor dem Ablaufdatum reichen nicht aus. Monitoring sollte denselben Weg prüfen wie ein echter Client: Ziel auswählen, Handshake aufbauen, Zertifikat und Namen validieren und anschliessend das Anwendungsprotokoll erreichen. Dafür sind insbesondere folgende Signale nützlich:

• Zielauswahl und SNI pro Dienst, Listener und Clusterknoten;
• ausgehandeltes Protokoll, Cipher Suite, Gruppe und Signaturalgorithmus;
• Leaf-Fingerprint, Seriennummer, SANs, Issuer sowie notBefore und notAfter;
• tatsächlich gesendete Intermediate-Kette und Pfadvalidierung aus Sicht relevanter Truststores;
• OCSP-/CRL-Erreichbarkeit und das reale Fail-open-/Fail-closed-Verhalten;
• Handshake-Latenz, Resumption-Anteil, Alertklassen und Fehlerquote;
• STARTTLS-Angebot, erfolgreiche Upgrades und Klartext-Fallbacks je SMTP-Ziel;
• MTA-STS-, DANE- und TLS-RPT-Zustand dort, wo diese Policymechanismen eingesetzt werden;
• Gleichstand aller TLS-Terminatoren nach Erneuerung und erfolgreicher Anwendungstest hinter dem TLS-Layer.

Monitoring von innen allein übersieht öffentliche Kette, externes DNS oder Edge-Terminatoren; ein externer Check allein sieht interne Truststores und mTLS nicht. Für Messaging- und Verzeichnisplattformen sind deshalb mindestens ein externer Clientpfad, ein interner Anwendungspfad und eine direkte Prüfung jedes Terminators nötig.

Technische Geschichte

Die Geschichte beginnt mit Netscapes SSL in den 1990er-Jahren. SSL 2.0 wurde später ausdrücklich verboten (RFC 6176); SSL 3.0 ist nur noch als historisches Protokoll dokumentiert und seit RFC 7568 unzulässig. Die IETF entwickelte daraus 1999 TLS 1.0, 2006 TLS 1.1 und 2008 TLS 1.2. RFC 8996 erklärte TLS 1.0 und 1.1 im Jahr 2021 für veraltet. Für Administratoren erklärt diese Abstammung, weshalb alte Produktnamen, Cipher-Syntax und Kompatibilitätsschalter bis heute in Konfigurationen auftauchen.

TLS 1.3 erschien 2018 mit RFC 8446. Es entfernte statischen RSA-Schlüsselaustausch, alte Nicht-AEAD-Verfahren und weitere Legacy-Funktionen, verschlüsselte den Handshake früher und führte den HKDF-basierten Schlüsselplan sowie das PSK-Wiederaufnahmemodell ein. RFC 9846 ersetzte RFC 8446 im Juli 2026 als konsolidierte TLS-1.3-Spezifikation und integrierte bis dahin separat dokumentierte Korrekturen und Anforderungen. Der Protokollwert 1.3 blieb dabei derselbe; geändert wurde das normative Standarddokument (RFC 9846, Abschnitt 1.2).

Parallel entwickelte sich die Identitäts- und Betriebsseite: X.509-PKIX wurde in RFC 5280 konsolidiert, SNI und andere Erweiterungen in RFC 6066, ALPN in RFC 7301, automatisierte Ausstellung in ACME/RFC 8555 und die moderne Dienstidentitätsprüfung in RFC 9525. TLS-Geschichte ist daher nicht nur eine Versionsfolge, sondern die gemeinsame Entwicklung von Kryptografie, Zertifikatspfaden, Anwendungseinbettung und operativer Automatisierung.