Mutual TLS einfach erklärt: Client-Zertifikate statt Passwort

Bei einer normalen HTTPS-Verbindung weist sich nur der Server aus: Er zeigt sein Zertifikat, der Browser prüft es. Wer der Besucher ist, klärt die Website danach mit Passwort oder Passkey. Bei Mutual TLS (mTLS, gegenseitiges TLS) zeigt auch der Client ein Zertifikat, und der Server prüft es, bevor überhaupt Daten fließen. Dieser Artikel erklärt den Unterschied im Verbindungsaufbau, typische Einsatzgebiete von Schnittstellen bis WLAN, warum Client-Zertifikate heute aus einer eigenen CA kommen sollten, und zeigt ein Beispiel mit nginx und curl.

Normales TLS: nur der Server zeigt seinen Ausweis

Beim TLS-Verbindungsaufbau schickt der Server sein Zertifikat und beweist mit einer Signatur, dass er den passenden privaten Schlüssel besitzt. Der Browser prüft die Kette bis zu einer vertrauenswürdigen Root und den Domainnamen. Den Ablauf beschreibt wie funktioniert HTTPS. Der Client bleibt dabei anonym; Anmeldung und Berechtigung regelt die Anwendung, etwa mit Passwort und zweitem Faktor; siehe Zwei-Faktor-Authentisierung.

Mutual TLS: beide Seiten weisen sich aus

Bei mTLS fordert der Server im Handshake zusätzlich ein Client-Zertifikat an (Nachricht CertificateRequest). Der Client antwortet mit:

Certificate: seinem Zertifikat samt Kette,
CertificateVerify: einer Signatur über den bisherigen Handshake, erzeugt mit seinem privaten Schlüssel. Damit beweist er, dass er das Zertifikat nicht nur kopiert hat.

Der Server prüft das Client-Zertifikat gegen die CAs, denen er für Clients vertraut, meist eine einzige eigene CA, und kontrolliert Gültigkeit und gegebenenfalls Sperrstatus. Fällt die Prüfung durch, bricht die Verbindung ab, bevor eine einzige Anfrage die Anwendung erreicht. In TLS 1.3 wird das Client-Zertifikat verschlüsselt übertragen; in TLS 1.2 war es für Mithörer noch lesbar. Wie Signaturen funktionieren, erklärt digitale Signatur.

Zwei Spalten: Bei normalem TLS weist sich nur der Server aus, bei Mutual TLS fordert der Server ein Zertifikat an und der Client antwortet mit Zertifikat und Signatur. — Der Unterschied im Verbindungsaufbau.

Wo mTLS eingesetzt wird

Schnittstellen zwischen Firmen und Diensten: Zahlungsanbieter, Banken und Behörden sichern JSON.">APIs mit Client-Zertifikaten ab. In der EU weisen sich Zahlungsdienstleister gegenüber Banken nach der Zahlungsdiensterichtlinie PSD2 mit qualifizierten Zertifikaten aus. Zu Schnittstellen siehe was ist eine API.
Microservices und Service Mesh: In Kubernetes-Umgebungen sorgen Werkzeuge wie Istio oder Linkerd automatisch dafür, dass jeder Dienst ein kurzlebiges Zertifikat bekommt und nur mit mTLS mit anderen Diensten spricht.
Geräte im Internet der Dinge: Sensoren, Ladesäulen oder Smart Meter melden sich mit einem Zertifikat bei ihrer Cloud an, das oft schon in der Fabrik aufgespielt wird.
Firmen-WLAN: Beim Verfahren EAP-TLS nach IEEE 802.1X meldet sich ein Laptop mit einem Zertifikat statt mit einem Passwort am WLAN an; siehe WLAN-Verschlüsselung.
VPN und Zero Trust: VPN-Zugänge und Zero-Trust-Systeme lassen nur Geräte mit gültigem Firmenzertifikat herein.

Sechs Kacheln: Schnittstellen, Service Mesh, Geräte im Internet der Dinge, Firmen-WLAN mit EAP-TLS, VPN und Zero Trust. — Typische Einsatzgebiete von Client-Zertifikaten.

Woher die Client-Zertifikate kommen

Früher enthielten viele öffentliche Website-Zertifikate auch die Verwendung „TLS-Client-Authentifizierung“. Das ist vorbei: Das Chrome-Root-Programm verlangt, dass öffentliche Hierarchien nur noch Server-Zertifikate ausstellen: Neue Zwischenzertifikate dürfen seit dem 15. Juni 2026 nur noch den Server-Zweck tragen, neue Website-Zertifikate ab dem 15. März 2027. Viele CAs haben die Client-Verwendung schon vorher gestrichen; Let’s Encrypt hat sie am 11. Februar 2026 aus seinen Standardzertifikaten entfernt und das Sonderprofil dafür am 8. Juli 2026 eingestellt.

Für mTLS ist das ohnehin die bessere Lösung: Client-Zertifikate kommen aus einer eigenen, privaten CA. Der Server vertraut dann nur dieser CA und nicht jeder öffentlichen CA der Welt, und die Organisation bestimmt selbst Laufzeiten, Namen und Sperrung. Wie man eine solche CA betreibt, zeigt ein späterer Artikel dieser Reihe; die Grundlagen der Zertifikatsantragstellung stehen in Schlüsselpaar und CSR erstellen.

Vier Schritte: Let's Encrypt entfernt die Client-Verwendung am 11. Februar 2026, Chrome verlangt für neue Zwischenzertifikate ab 15. Juni 2026 den reinen Server-Zweck, das Sonderprofil endet am 8. Juli 2026, ab 15. März 2027 gilt der Server-Zweck für jedes neue Website-Zertifikat. — Das Ende der Client-Verwendung bei öffentlichen Zertifikaten.

mTLS einrichten: ein Beispiel mit nginx und curl

In nginx genügen zwei Zeilen im server-Block, um nur noch Clients mit einem Zertifikat der eigenen CA zuzulassen:

ssl_client_certificate /etc/nginx/client-ca.pem;
ssl_verify_client on;

Die Variable $ssl_client_s_dn enthält danach den Namen aus dem Client-Zertifikat und kann an die Anwendung weitergegeben werden, etwa um zu entscheiden, welcher Partner was darf. Ein Client verbindet sich mit curl so:

curl --cert client.pem --key client.key https://api.beispiel.de/status

Ohne Zertifikat antwortet nginx mit dem Fehler 400 und dem Hinweis „No required SSL certificate was sent“. Wichtig: Läuft vor dem Server ein Lastverteiler oder CDN, das die TLS-Verbindung beendet, muss dort die Client-Prüfung stattfinden, sonst sieht der eigentliche Server kein Client-Zertifikat.

Vor- und Nachteile

Vorteile:

Kein Passwort, das gestohlen, erraten oder auf einer Phishing-Seite eingegeben werden kann.
Schutz vor dem ersten Byte: Unbekannte Clients erreichen die Anwendung gar nicht.
Starke Identität für Maschinen, die kein Mensch bedient.

Nachteile:

Verteilung und Erneuerung: Jeder Client braucht ein Zertifikat, das rechtzeitig erneuert und bei Verlust gesperrt werden muss. Ohne Automatisierung wird das schnell unübersichtlich.
Bedienung im Browser: Für Menschen ist die Auswahl eines Zertifikats im Browser umständlich; für Endkunden haben sich Passkeys durchgesetzt.
Fehlersuche: Scheitert der Handshake, sind die Meldungen oft wenig aussagekräftig.

Häufige Fragen

Brauche ich mTLS für meine Website? Für öffentliche Websites nicht. mTLS lohnt sich für Schnittstellen, interne Dienste und Geräte, deren Gegenstellen bekannt sind.

Ist mTLS dasselbe wie ein Passkey? Nein, aber verwandt: Beide beweisen den Besitz eines privaten Schlüssels. Passkeys arbeiten in der Anwendung und sind an die Website gebunden, mTLS arbeitet in der TLS-Verbindung.

Kann ich ein Let’s-Encrypt-Zertifikat als Client-Zertifikat nutzen? Nicht mehr. Let’s Encrypt stellt seit Juli 2026 keine Zertifikate mit Client-Verwendung mehr aus.

Wie sperre ich ein verlorenes Client-Zertifikat? Über die Sperrliste der eigenen CA, die der Server regelmäßig lädt, in nginx mit ssl_crl. Kurze Laufzeiten begrenzen den Schaden zusätzlich.

Fazit

Bei Mutual TLS weisen sich beide Seiten mit Zertifikaten aus, und der Server lässt nur bekannte Clients überhaupt durch. Das eignet sich für Schnittstellen, Microservices, Geräte und Firmen-WLAN. Die Client-Zertifikate kommen heute aus einer eigenen CA, weil öffentliche CAs keine Client-Zertifikate mehr ausstellen. Mehr in der Übersicht Verschlüsselung und IT-Sicherheit.