TLS und Zertifikate
Was hinter dem Schloss im Browser steckt: wie zwei Fremde über ein abgehörtes Netz einen gemeinsamen Schlüssel vereinbaren, wie ein Zertifikat beweist, wer am anderen Ende sitzt – und was das Schloss nicht bedeutet.
TLS (Transport Layer Security, früher SSL) legt sich zwischen TCP und eine Anwendung wie HTTP und sorgt für dreierlei: Niemand kann mitlesen (Vertraulichkeit), niemand kann unbemerkt etwas ändern (Integrität), und man spricht wirklich mit dem, mit dem man sprechen will (Authentizität). HTTPS ist einfach HTTP über TLS.
Zwei Ideen tragen das Ganze: Ein Schlüsselaustausch lässt zwei Fremde über ein abgehörtes Netz einen gemeinsamen geheimen Schlüssel vereinbaren. Und ein Zertifikat, unterschrieben von einer Stelle, der der Browser vertraut, beweist, wem der Server gehört.
Wovor TLS schützt
Ohne TLS geht jede Anfrage im Klartext über jedes WLAN, jeden Router, jeden Knoten auf dem Weg. Wer im selben Café-WLAN sitzt oder einen Router kontrolliert, kann Passwörter und Cookies mitlesen. Schlimmer noch: Er kann Antworten verändern – Werbung einschleusen, einen Download austauschen, ein Formular auf seinen eigenen Server umlenken.
Vertraulichkeit
Die Daten sind mit einem gemeinsamen Schlüssel verschlüsselt, meist mit AES oder ChaCha20. Wer mitliest, sieht nur Zeichensalat.
Integrität
Jeder Datensatz trägt eine Prüfsumme, die nur mit dem Schlüssel berechnet werden kann. Ein verändertes Byte fällt sofort auf.
Authentizität
Der Server beweist mit seinem Zertifikat und dem dazugehörigen privaten Schlüssel, dass er zur Domain gehört.
Das Kernproblem: ein Geheimnis vereinbaren, während alle zuhören
Verschlüsseln ist leicht, wenn beide denselben Schlüssel haben. Aber wie kommt man an einen gemeinsamen Schlüssel, wenn man sich noch nie getroffen hat und jemand jedes Wort mithört? Die verblüffende Lösung fanden Whitfield Diffie und Martin Hellman 1976. Man erklärt sie am besten mit Farben: Farben zu mischen ist leicht, eine Mischung wieder zu trennen praktisch unmöglich.
In Wirklichkeit sind die „Farben“ Zahlen, und das „Mischen“ ist eine Rechnung, die in eine Richtung schnell und rückwärts praktisch unmöglich ist – klassisch Potenzieren modulo einer riesigen Primzahl, heute meist das Rechnen auf elliptischen Kurven (etwa X25519). Mit dem gemeinsamen Ergebnis werden dann die eigentlichen Sitzungsschlüssel erzeugt.
Ein wichtiger Bonus: Weil für jede Verbindung neue Geheimzahlen gewürfelt und danach vergessen werden, nützt es einem Angreifer nichts, wenn er heute den Verkehr aufzeichnet und Jahre später den Server knackt. Das heißt Forward Secrecy und ist in TLS 1.3 Pflicht.
Zertifikate: Wer ist am anderen Ende?
Der Farbtrick hat eine Lücke. Eve könnte sich in die Mitte setzen, mit Alice einen Schlüssel vereinbaren und mit Bob einen anderen – und alles umschlüsseln und mitlesen. Das ist der Man-in-the-Middle-Angriff. Alice braucht also einen Beweis, dass sie wirklich mit Bob spricht.
Diesen Beweis liefert ein Zertifikat: ein Dokument, das sagt „Der öffentliche Schlüssel X gehört zur Domain shop.example.com“, gültig von–bis, unterschrieben von einer Zertifizierungsstelle (CA). Im Handshake unterschreibt der Server zusätzlich die Verbindungsdaten mit seinem privaten Schlüssel – das kann nur, wer den passenden Schlüssel zum Zertifikat hat.
Und woher weiß der Browser, dass die Unterschrift der CA echt ist? Sie ist selbst von einer höheren Stelle unterschrieben – bis hinauf zu einer Root-CA, deren Zertifikat fest im Betriebssystem, im Browser oder im JDK hinterlegt ist. Diese Vertrauenskette lässt sich an jeder Stelle brechen. Probier es:
Der Fall mit dem fehlenden Zwischenzertifikat ist in der Praxis der tückischste: Im Browser funktioniert alles, weil der fehlende Teil nachgeladen oder aus früheren Besuchen bekannt ist. Erst ein Java-Programm, curl oder eine App scheitert – und alle schauen ratlos auf den Browser, in dem es doch geht.
Wer stellt Zertifikate aus?
Früher kosteten Zertifikate Geld und Papierkram, deshalb lief ein Großteil des Webs unverschlüsselt. Das änderte 2015 Let's Encrypt: eine gemeinnützige CA, die kostenlos und vollautomatisch Zertifikate ausstellt. Ein Programm auf dem Server beweist über das ACME-Protokoll, dass es die Domain kontrolliert, und erneuert das Zertifikat selbstständig. Heute läuft der allergrößte Teil des Webverkehrs über HTTPS.
Die Laufzeiten werden dabei immer kürzer, damit gestohlene oder falsch ausgestellte Zertifikate schnell nutzlos werden. Seit März 2026 dürfen öffentliche Zertifikate höchstens 200 Tage gelten; bis 2029 sinkt die Grenze schrittweise auf 47 Tage. Ohne Automatisierung ist das nicht mehr zu bewältigen. Zudem landet jedes ausgestellte Zertifikat in öffentlichen Logbüchern (Certificate Transparency) – so fällt auf, wenn eine CA ein Zertifikat für eine fremde Domain ausstellt.
Der TLS-1.3-Handshake
Alles zusammen passiert in einer einzigen Rundreise – im Eintrag TCP/IP ist sie im Zeitdiagramm zu sehen:
- ClientHellounverschlüsselt„Ich kann diese Verfahren, und hier ist schon meine Hälfte des Schlüsselaustauschs – meine Farbmischung.“ Dazu der gewünschte Servername (SNI), damit der Server weiß, welches Zertifikat er zeigen soll.
- ServerHellounverschlüsselt„Wir nehmen dieses Verfahren, hier ist meine Hälfte.“ Ab jetzt haben beide den gemeinsamen Schlüssel.
- Zertifikatschon verschlüsseltDer Server schickt seine Zertifikatskette.
- CertificateVerifyverschlüsseltDer Server unterschreibt den bisherigen Handshake mit seinem privaten Schlüssel – der Beweis, dass er der Inhaber des Zertifikats ist und niemand dazwischensitzt.
- FinishedverschlüsseltBeide bestätigen, dass sie dasselbe gesehen haben. Dann fließen die eigentlichen HTTP-Daten.
Bei einem erneuten Besuch geht es sogar ohne Rundreise (0-RTT): Der Client schickt seine Anfrage gleich mit. Der Haken: Ein Angreifer könnte diese erste Nachricht aufzeichnen und noch einmal abspielen. Server erlauben 0-RTT deshalb nur für Anfragen, die man gefahrlos wiederholen kann.
Eine Variante ist im Firmennetz verbreitet: gegenseitiges TLS (mTLS). Dort zeigt auch der Client ein Zertifikat. So weisen sich Dienste untereinander aus, etwa in Kubernetes mit einem Service-Mesh.
Für Entwickler übersetzt
Java bringt seine eigene Liste vertrauenswürdiger Root-CAs mit, den Truststore cacerts im JDK. Die meisten TLS-Probleme in Java-Anwendungen drehen sich um ihn – typischerweise, wenn eine Firma eine eigene CA für interne Server betreibt, die das JDK nicht kennt.
# Firmen-Root-CA in einen eigenen Truststore aufnehmen (statt das JDK zu verändern)
keytool -importcert -alias firmen-root -file firmen-root.pem \
-keystore truststore.p12 -storetype PKCS12 -storepass geheim
# Anwendung damit starten
java -Djavax.net.ssl.trustStore=truststore.p12 -Djavax.net.ssl.trustStorePassword=geheim -jar app.jar
# Wenn es hakt: den Handshake mitprotokollieren
java -Djavax.net.debug=ssl:handshake -jar app.jar| Begriff | Bedeutung |
|---|---|
| Truststore | Wem ich vertraue: Zertifikate von CAs. Standard: $JAVA_HOME/lib/security/cacerts. |
| Keystore | Wer ich bin: mein eigenes Zertifikat samt privatem Schlüssel – für Server oder für mTLS. |
SSLContext | Bündelt beides für eine Verbindung. Der HttpClient nimmt ohne Angabe den Standard. |
| PKIX path building failed | Java findet keine Kette zu einer vertrauten Root – unbekannte CA oder fehlendes Zwischenzertifikat. |
TrustManager, der jedes Zertifikat akzeptiert, „damit es endlich läuft“. Damit ist die Verbindung zwar verschlüsselt, aber nicht mehr authentisch – jeder Man-in-the-Middle wird durchgewunken. So etwas darf nie in Produktion. Die richtige Lösung ist fast immer, die fehlende CA in einen Truststore aufzunehmen oder die Server-Konfiguration zu reparieren.