mTLS – Mutual TLS
Abkürzung: mTLS
mTLS ist kein eigenes Protokoll, sondern eine Betriebsart von TLS. Die Fähigkeit steckt seit der ersten Fassung in der Norm; sie wird im Publikumsverkehr nur fast nie genutzt.
Der Unterschied zum gewöhnlichen TLS
Im Normalfall ist die Authentifizierung einseitig: Der Server belegt seine Identität, der Client bleibt anonym. Wer der Client ist, klärt sich danach innerhalb der verschlüsselten Verbindung — über Anmeldedaten, ein Token oder einen API-Schlüssel.
Bei mTLS verlangt der Server schon im Handshake einen Nachweis. Ein Client ohne gültiges Zertifikat kommt nicht bis zur Anwendung; er wird auf Protokollebene abgewiesen. Das verschiebt die Zugangskontrolle unter die Anwendung — ein Angriff auf die Anmeldemaske setzt voraus, die Maske überhaupt zu erreichen.
Der Ablauf
Der Server schickt nach seinem eigenen Zertifikat eine CertificateRequest und nennt darin, welche Zertifizierungsstellen er akzeptiert. Der Client antwortet mit zwei Nachrichten:
Certificate enthält sein Zertifikat samt Kette.
CertificateVerify enthält eine Signatur über den bisherigen Handshake, gebildet mit dem privaten Schlüssel.
Die zweite Nachricht ist die entscheidende. Ein Zertifikat ist öffentlich und ließe sich kopieren; die Signatur belegt, dass der Client den dazugehörigen privaten Schlüssel wirklich besitzt. Da sie über den konkreten Handshake geht, lässt sie sich auch nicht wiederverwenden.
Eigene Zertifizierungsstelle statt öffentlicher
Für Serverzertifikate nimmt man eine öffentliche Stelle, weil beliebige Clients sie prüfen können müssen. Bei Clientzertifikaten ist es umgekehrt richtig, eine eigene Stelle zu betreiben.
Der Grund ist einfach: Würde der Server jedes Zertifikat einer öffentlichen Stelle akzeptieren, käme jeder herein, der sich dort eines ausstellen lässt. Die eigene Stelle stellt nur für die eigenen Clients aus, und die Liste akzeptierter Aussteller wird entsprechend eng gesetzt.
Authentifizierung ist keine Berechtigung
Hier liegt der häufigste Fehler in mTLS-Aufbauten. Der Server prüft die Kette, stellt fest, dass das Zertifikat von der eigenen Stelle signiert ist — und lässt durch.
Damit hat jeder Client dieselben Rechte wie jeder andere. Ein Gerät, dessen Zertifikat für einen Lesezugriff gedacht war, kann schreiben. Nötig ist deshalb ein zweiter Schritt: Der Server liest den Subject-Namen oder eine Erweiterung aus dem Zertifikat und gleicht ihn gegen eine Liste zugelassener Clients und deren Rechte ab.
Dazu gehört die Sperrprüfung. Ein ausgeschiedenes Gerät behält sein Zertifikat bis zum Ablauf — ohne Sperrliste oder einen Abgleich gegen eine aktuelle Freigabeliste bleibt es gültig.
Wo mTLS eingesetzt wird
Zwischen Diensten. In verteilten Systemen authentifizieren sich Dienste gegenseitig, häufig durch eine Infrastrukturschicht, die Zertifikate automatisch ausstellt und mit kurzer Laufzeit erneuert.
An Programmierschnittstellen. Statt eines Schlüssels im Header weist sich der aufrufende Client mit einem Zertifikat aus. Im Zahlungsverkehr ist das regulatorisch vorgegeben.
Bei Geräten im Feld. Sensoren und Steuerungen erhalten bei der Herstellung ein Zertifikat, das ihre Identität über die gesamte Lebensdauer trägt.
In VPN-Zugängen. Dieselbe Mechanik, nur unterhalb der Anwendung.
Der eigentliche Aufwand
Dass mTLS im Publikumsverkehr nicht vorkommt, liegt nicht an der Technik, sondern am Betrieb. Jeder Client braucht ein Zertifikat und einen privaten Schlüssel, die ausgerollt, geschützt, vor Ablauf erneuert und bei Verlust gesperrt werden müssen.
Bei einer Handvoll Diensten ist das überschaubar. Bei tausenden Endnutzern wird daraus ein eigenes Verwaltungsproblem — zumal ein verlorener privater Schlüssel auf einem Endgerät nicht nur den Zugang kostet, sondern eine Neuausstellung erzwingt.
Der verbreitete Ausweg sind kurze Laufzeiten mit automatischer Erneuerung: Ein Zertifikat, das nach Stunden abläuft, braucht keine Sperrung.
Abgrenzung
Ein API-Schlüssel oder Bearer-Token wird mitgeschickt und ist damit kopierbar — wer ihn abfängt, kann ihn verwenden. Bei mTLS verlässt der private Schlüssel das Gerät nicht; übertragen wird nur eine Signatur über den konkreten Handshake.
Eine HMAC-Signatur über die Anfrage leistet Ähnliches auf Anwendungsebene, setzt aber ein gemeinsames Geheimnis voraus und schützt die Verbindung selbst nicht.