mTLS
Die wichtigsten Befehle zum Merken
curl --cert … --key …— eine Clientidentität bei TLS vorlegen.openssl x509— ein Zertifikat ohne privaten Schlüssel untersuchen.
Befehle und Optionen
| Option | Bedeutung |
|---|---|
-in client.crt -noout |
Dieses Zertifikat ohne Ausgabe seiner Kodierung lesen. |
-subject -issuer -dates |
Subject, Aussteller und Gültigkeitszeit anzeigen. |
-i --max-time 10 |
HTTP-Header ergänzen und auf zehn Sekunden begrenzen. |
--cacert lab-ca.crt |
Den Server anhand der Lab-CA prüfen. |
--cert client.crt --key client.key |
Clientzertifikat und zugehörigen privaten Schlüssel angeben. |
Verwende Lab-Zugangsdaten. Ein verschlüsselter Schlüssel kann lokal nach seiner Passphrase fragen. Schreibe diese nicht in den Befehl.
Die entscheidenden Konzepte
1. Gegenseitiges TLS authentifiziert beide Seiten
Gewöhnliches HTTPS authentifiziert meist den Server gegenüber dem Client. Mutual TLS (mTLS) ergänzt Clientzertifikatsauthentifizierung, sodass auch der Server seinen Peer auf TLS-Ebene authentifizieren kann.
Das eignet sich für Dienstkommunikation oder verwaltete Geräte. Es bedeutet nicht zwingend eine menschliche Anmeldung. Beide Richtungen müssen auch nicht dieselbe ausstellende CA verwenden.
2. Das Zertifikat allein ist noch kein Besitznachweis
Ein Zertifikat ist öffentlich. Die Authentifizierung verlangt zusätzlich den Besitz des passenden privaten Schlüssels. Das Kopieren eines fremden Zertifikats ohne Schlüssel reicht daher nicht zur Anmeldung als dessen Identität.
Gültigkeit, Verwendungszweck und Kette müssen zur Empfängerrichtlinie passen. Das Lesen des Subjects untersucht nur Metadaten. Es prüft weder die vollständige Vertrauensbeziehung noch die spätere Serverakzeptanz.
3. Server- und Clientvertrauen laufen entgegengesetzt
Der Client prüft Server und Hostnamen gegen seinen Vertrauensspeicher. Der Server prüft das Clientzertifikat getrennt gegen seine akzeptierten Aussteller und Richtlinien.
Curl konfiguriert mit --cacert die Serverprüfung. Das teilt dem Server nicht mit, dem Client zu vertrauen. Ein gültiges Serverzertifikat und ein abgelehntes Clientzertifikat können im selben Verbindungsversuch auftreten.
4. Authentifizierung benötigt weiterhin Autorisierung
Nach der Identifikation entscheidet der Dienst, was der Client tun darf. TLS-Akzeptanz gibt nicht automatisch Zugriff auf jede Route und jedes Objekt.
Terminiert ein Proxy mTLS, erhält das Backend die Identität möglicherweise über vertrauenswürdige Weiterleitung statt eigener Client-TLS-Prüfung. Rotation, Ablauf und Widerruf müssen zu dieser Grenze und zur Identitätszuordnung der Anwendung passen.
Ein kleines Beispiel
Optional: Verwende das angegebene vorhandene lokale Lab samt Dateien. Das Beispiel baut keine CA auf und verändert keinen Server.
openssl x509 -in client.crt -noout -subject -issuer -dates
curl -i --max-time 10 --cacert lab-ca.crt https://localhost:8443/
curl -i --max-time 10 --cacert lab-ca.crt --cert client.crt --key client.key https://localhost:8443/Lies zuerst Subject, Aussteller und Gültigkeit. Das beweist keine Akzeptanz. Vergleiche dann Anfragen ohne und mit Clientzertifikat. Die erste kann schon bei TLS abgelehnt werden und deshalb keinen HTTP-Status liefern.
Die zweite kann mit akzeptierter Identität TLS abschließen und trotzdem einen HTTP-Autorisierungsfehler erhalten. Meldungen hängen von TLS-Version und Server ab. Fehlende Datei oder Listener sind Voraussetzungenfehler, keine Authentifizierungsbefunde.
Die Serverprüfung bleibt aktiv. Es werden keine Zugangsdaten erzeugt oder außerhalb dieses lokalen Labs verwendet. Aufräumen ist nicht erforderlich.
Merke dir: mTLS beweist den Besitz akzeptierter Client- und Serveridentitäten. Anwendungsrichtlinien bestimmen deren Rechte.