Wie HTTPS und TLS wirklich funktionieren: Handshake und Zertifikate

Sie fügen ein SSL-Zertifikat hinzu, richten Ihre Domain auf einen Server und das Schloss erscheint. Die meisten Entwickler hören dort auf. Dann scheitert eines Tages ein API-Client mit UNABLE_TO_VERIFY_LEAF_SIGNATURE, eine mobile App lehnt Ihr Zertifikat auf älteren Android-Versionen ab, oder ein Load Balancer beendet TLS und Ihre App sieht alles als reines HTTP. Plötzlich müssen Sie wissen, was tatsächlich zwischen der TCP-Verbindung und der ersten HTTP-Anfrage passiert.

Dieser Artikel führt Sie durch die Funktionsweise von HTTPS und TLS: was der Handshake tut, wie Zertifikate validiert werden, was sich in TLS 1.3 geändert hat und wie Sie die Fehler diagnostizieren, auf die Sie tatsächlich stoßen werden.

Was HTTPS tatsächlich hinzufügt

HTTPS ist HTTP, das über eine TLS-Verbindung gesendet wird. TLS bietet drei Garantien:

• Vertraulichkeit — der Datenverkehr wird mit symmetrischen Schlüsseln verschlüsselt, die während des Handshakes ausgehandelt werden.
• Integrität — jeder Record trägt ein Authentifizierungs-Tag, sodass Manipulationen erkannt werden.
• Authentifizierung — der Server beweist, dass er den privaten Schlüssel für das Zertifikat besitzt, das zum angeforderten Hostnamen passt.

Beachten Sie, was nicht auf dieser Liste steht: Der Client wird standardmäßig nicht authentifiziert. TLS authentifiziert den Server; Ihre Anwendung authentifiziert den Benutzer.

Der TLS 1.2 Handshake, Schritt für Schritt

TLS 1.2 ist auf älteren Infrastrukturen und in vielen Unternehmens-Proxys noch verbreitet, daher lohnt es sich, es zu verstehen. Ein vollständiger Handshake sieht so aus:

1. ClientHello — der Client sendet unterstützte TLS-Versionen, einen Zufallswert, eine Liste von Cipher Suites und (falls zutreffend) den SNI-Hostnamen.
2. ServerHello — der Server wählt eine Version und Cipher Suite, gibt seinen eigenen Zufallswert zurück und sendet seine Zertifikatskette.
3. Schlüsselaustausch — bei ECDHE sendet der Server einen ephemeren öffentlichen Schlüssel; der Client sendet seinen eigenen. Beide leiten dasselbe gemeinsame Geheimnis ab. Der Server signiert das Handshake-Transkript mit dem privaten Schlüssel seines Zertifikats.
4. Finished — beide Seiten senden einen MAC über das Handshake-Transkript, der bestätigt, dass nichts manipuliert wurde.
5. Anwendungsdaten — HTTP-Anfragen und -Antworten fließen verschlüsselt.

Das entscheidende Detail ist der ephemere Schlüsselaustausch. Bei ECDHE wird pro Verbindung ein neues Schlüsselpaar generiert. Selbst wenn ein Angreifer jahrelangen Datenverkehr aufzeichnet und später den privaten Schlüssel des Servers stiehlt, kann er vergangene Sitzungen nicht entschlüsseln. Diese Eigenschaft nennt man Forward Secrecy, und sie ist der Hauptgrund, warum der statische RSA-Schlüsselaustausch veraltet ist.

Wie TLS 1.3 das Spiel verändert hat

TLS 1.3 vereinfacht den Handshake auf einen einzigen Roundtrip und entfernt Legacy-Algorithmen vollständig.

In TLS 1.3 errät der Client die Schlüsselaustauschgruppe und sendet seinen Anteil in der ersten Nachricht, sodass der Server die Schlüsselvereinbarung sofort abschließen kann. Zertifikate werden weiterhin gesendet, sind aber nun verschlüsselt, was bedeutet, dass passive Beobachter nicht mehr sehen können, welcher Hostname ausgeliefert wird — nur der SNI im ClientHello verrät ihn, es sei denn, Encrypted Client Hello wird verwendet.

Die 0-RTT-Wiederaufnahme ermöglicht es einem wiederkehrenden Client, Anwendungsdaten mit dem ersten Flug zu senden. Das ist schnell, aber 0-RTT-Daten sind wiederholbar (replayable), daher niemals für nicht-idempotente Anfragen wie Zahlungen verwenden.

Zertifikate und Kettenvalidierung

Ein Zertifikat bindet einen öffentlichen Schlüssel an einen Hostnamen. Die Validierung ist ein Kettenlauf:

• Der Server sendet sein Leaf-Zertifikat plus Zwischenzertifikate.
• Der Client sucht ein vertrauenswürdiges Root in seinem Speicher und verifiziert dann jede Signatur die Kette hinauf.
• Er prüft den Hostnamen gegen das Feld Subject Alternative Name (SAN) — Common Name wird von modernen Clients ignoriert.
• Er prüft Gültigkeitsdaten und Sperrstatus (CRL oder OCSP, oft gestapelt).

Die häufigste Ursache für unable to verify-Fehler ist ein fehlendes Zwischenzertifikat. Browser kaschieren dies manchmal durch Caching von Zwischenzertifikaten, aber Kommandozeilen-Tools und mobile Apps schlagen hart fehl. Servieren Sie immer die vollständige Kette, Leaf zuerst, dann Zwischenzertifikate — niemals das Root.

Praktisches Debugging mit OpenSSL

Wenn etwas kaputt ist, inspizieren Sie, was der Server tatsächlich sendet, bevor Sie den Client beschuldigen.

# Zeigt die Zertifikatskette, die der Server präsentiert
openssl s_client -connect example.com:443 -servername example.com -showcerts

# Nur TLS 1.3 aushandeln und die gewählte Cipher auflisten
openssl s_client -connect example.com:443 -tls1_3

# Zertifikatsablauf in einer Zeile prüfen
echo | openssl s_client -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -dates -subject -ext subjectAltName

Wenn s_client verify error:num=21:unable to verify the first certificate meldet, ist die Kette unvollständig. Wenn es eine Hostnamen-Fehlanpassung meldet, prüfen Sie die SAN-Liste — Wildcard-Zertifikate decken nur eine Ebene ab, also passt *.example.com auf api.example.com, aber nicht auf a.b.example.com.

Häufige Fehlkonfigurationen

• Mixed Content — eine HTTPS-Seite, die http://-Skripte oder -Bilder lädt. Browser blockieren aktives Mixed Content und upgraden passives Content möglicherweise automatisch.
• TLS wird am Load Balancer beendet — das Backend sieht reines HTTP. Leiten Sie X-Forwarded-Proto weiter und vertrauen Sie ihm nur von bekannten Proxys, sonst generiert Ihre App möglicherweise falsche Redirect-URLs.
• Schwache Protokollversionen aktiviert — TLS 1.0 und 1.1 sollten deaktiviert werden. Zielen Sie nur auf TLS 1.2 und 1.3 ab.
• Kein HSTS — ohne den Strict-Transport-Security-Header kann die erste Anfrage noch heruntergestuft werden. Beginnen Sie mit einer kurzen max-age und erhöhen Sie sie, sobald Sie sicher sind.
• Selbstsignierte Zertifikate in der Produktion — in Ordnung für interne Tests, aber sie gewöhnen Benutzer und Clients daran, Warnungen zu ignorieren.

Eine vernünftige Serverkonfiguration

Für Nginx sieht eine moderne Basis so aus:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;

Lassen Sie den Server in TLS 1.3 die Cipher wählen — die Client-Präferenz ist dort in Ordnung, weil die Suites alle stark sind. Lassen Sie Session-Tickets aus, es sei denn, Sie rotieren die Ticket-Schlüssel, da ein geleakter Ticket-Schlüssel die Wiederaufnahme kompromittieren kann.

FAQ

Verschlüsselt HTTPS den Hostnamen?

Standardmäßig nicht. Die SNI-Erweiterung im ClientHello wird im Klartext gesendet, damit der Server weiß, welches Zertifikat er präsentieren soll. Encrypted Client Hello (ECH) verbirgt ihn, aber die Verbreitung ist noch begrenzt. Der Pfad und die Query-String sind immer verschlüsselt.

Warum funktioniert mein Zertifikat in einem Browser, aber nicht in curl oder einer mobilen App?

Fast immer ein fehlendes Zwischenzertifikat. Browser holen oder cachen Zwischenzertifikate oft selbst, während strengere Clients verlangen, dass der Server die vollständige Kette sendet. Überprüfen Sie dies mit openssl s_client -showcerts.

Ist TLS 1.3 immer schneller als TLS 1.2?

Für neue Verbindungen ja — ein Roundtrip statt zwei. Bei wiederaufgenommenen Verbindungen verringert sich der Unterschied, und 0-RTT kann TLS 1.3 noch schneller machen, auf Kosten des Replay-Risikos bei nicht-idempotenten Anfragen.

Wenn Sie nach einer TLS-Änderung einen Webserver prüfen, zeigt die Log-Analyse oft die tatsächlichen Auswirkungen: fehlerhafte Redirects, unerwartete 4xx-Spitzen oder Clients, die immer noch HTTP ansprechen. Sie können ein Access-Log in den Nginx Log Analyzer laden, um Statuscode-Verteilungen zu sehen und Clients zu erkennen, die das Upgrade auf HTTPS nie abgeschlossen haben.