Implementierungsmuster für Mutual TLS (mTLS)

Standard-TLS authentifiziert über ein Zertifikat nur den Server gegenüber dem Client. Mutual TLS (mTLS) erweitert dies: Beide Parteien legen Zertifikate vor und überprüfen sie. Der Client legt ein Clientzertifikat vor, nachdem der Server es angefordert hat (über CertificateRequest im TLS-Handshake). Der Server überprüft das Clientzertifikat anhand einer vertrauenswürdigen CA. mTLS bildet die Grundlage für Zero-Trust-Netzwerke: Statt sich auf die Sicherheit des Netzwerkperimeters zu verlassen, authentifizieren sich Services bei jeder Verbindung kryptografisch gegenseitig. Service Meshes wie Istio, Linkerd und Consul Connect implementieren mTLS transparent zwischen Microservices.

Der mTLS-Handshake erweitert TLS 1.3 wie folgt: Nach ServerHello sowie dem Serverzertifikat und Finished sendet der Server eine CertificateRequest-Nachricht, in der er akzeptierte Zertifizierungsstellen und Signaturalgorithmen angibt. Der Client antwortet mit seinem Certificate (der Zertifikatskette des Clients) und CertificateVerify (einer Signatur über das Transkript, die mit dem privaten Schlüssel des Clients erzeugt wurde). Der Server überprüft die Zertifikatskette des Clients anhand seines Speichers vertrauenswürdiger CAs und validiert die CertificateVerify-Signatur. Wenn beide Prüfungen erfolgreich sind, ist die Verbindung gegenseitig authentifiziert. Der Client kann keine CertificateVerify fälschen, ohne über den privaten Schlüssel zu verfügen, der zum Zertifikat gehört.

In Service-Mesh-Umgebungen werden Clientzertifikate typischerweise von einer internen CA ausgestellt. Istio verwendet SPIFFE (Secure Production Identity Framework for Everyone) SVIDs: Jede Workload erhält ein Zertifikat mit einem SPIFFE-URI-SAN (Subject Alternative Name) wie spiffe://cluster.local/ns/default/sa/payment-service. Diese Zertifikate sind kurzlebig (24 Stunden) und werden automatisch von der Mesh-Control-Plane (istiod) regelmäßig erneuert. Bei benutzerseitigem mTLS (z. B. für Unternehmens-VPNs oder API-Clients) können Zertifikate von einer Unternehmens-CA mit längeren Gültigkeitsdauern ausgestellt und über MDM (Mobile Device Management) an die Geräte der Mitarbeitenden verteilt werden.

Die mTLS-Überprüfung auf der Serverseite umfasst mehrere Schritte: (1) Kettenvalidierung — überprüfen, dass die Zertifikatskette des Clients zu einer vertrauenswürdigen Root-CA im Client-CA-Speicher des Servers führt. (2) Prüfung der Gültigkeitsdauer — sicherstellen, dass das Zertifikat weder abgelaufen noch derzeit ungültig ist. (3) Prüfung auf Widerruf — über OCSP oder CRL überprüfen, dass das Zertifikat nicht widerrufen wurde. (4) Abgleich von SAN/CN — den Identitätsanspruch aus dem Zertifikats-SAN (SPIFFE-URI, DNS-Name oder E-Mail-Adresse) auslesen. (5) Autorisierung — überprüfen, ob die authentifizierte Identität zum Zugriff auf die angeforderte Ressource berechtigt ist. Die Schritte 4 und 5 erfordern Anwendungslogik, die über die grundlegende TLS-Konfiguration hinausgeht.

Kurzlebige Zertifikate machen einen expliziten Widerruf überflüssig: Läuft ein Zertifikat nach 24 Stunden ab, ist das Zeitfenster für einen Missbrauch begrenzt. Für die Rotation ist Folgendes erforderlich: (1) Vorabrotation — ein neues Zertifikat ausstellen, bevor das alte abläuft (Rotation bei 80 % der Gültigkeitsdauer). (2) Austausch ohne Ausfallzeit — der Service muss während des Übergangsfensters sowohl alte als auch neue Zertifikate akzeptieren. (3) Graceful Reload — der TLS-Stack muss Zugangsdaten neu laden können, ohne bestehende Verbindungen zu trennen (nginx: nginx -s reload; Envoy: dynamische Aktualisierung von xDS-Zertifikaten). Die SPIFFE Workload API (implementiert durch SPIRE) automatisiert die Bereitstellung und Rotation von Zertifikaten über eine Unix-Domain-Socket-API.

Istio implementiert mTLS transparent über in jeden Pod injizierte Envoy-Sidecar-Proxys. Die Control Plane (istiod) fungiert als CA und verwendet ein Zwischenzertifikat, das von der Root-CA des Mesh signiert wurde. Der Sidecar jedes Pods erhält über die SDS-(Secret Discovery Service-)API einen SPIFFE SVID. PeerAuthentication-Richtlinien konfigurieren den mTLS-Modus: STRICT (mTLS erforderlich), PERMISSIVE (mTLS und Klartext werden akzeptiert, für die Migration) oder DISABLE. AuthorizationPolicy-Ressourcen legen fest, welche Services miteinander kommunizieren dürfen; dies wird anhand der SPIFFE-Identität im Clientzertifikat geprüft. So wird Zero Trust innerhalb des Clusters ohne Änderungen am Anwendungscode umgesetzt.

Für externe API-Clients bietet mTLS eine stärkere Authentifizierung als API-Schlüssel oder OAuth-Token. Der Client verwahrt einen privaten Schlüssel in einem sicheren Speicher (HSM, Betriebssystem-Schlüsselspeicher oder Softwareschlüssel mit Passphrase). Das Clientzertifikat ist an die erwartete CA des API-Endpunkts gepinnt. Jede API-Anfrage wird auf der TLS-Ebene authentifiziert – ein separater Authorization-Header ist nicht erforderlich. Cloudflare's API Shield, AWS API Gateway client certificates und Googles Cloud service account mTLS implementieren dieses Modell. Ein kompromittierter API-Schlüssel kann von überall aus verwendet werden; bei einem kompromittierten privaten mTLS-Schlüssel muss zusätzlich das Gerät gestohlen werden, auf dem der Client ausgeführt wird.

mTLS-Bereitstellungen stehen vor mehreren betrieblichen Herausforderungen. (1) Zertifikatverteilung – Clientzertifikate müssen sicher an alle Services verteilt werden, insbesondere in dynamischen Umgebungen, in denen Pods hoch- und herunterskaliert werden. (2) Kompromittierung der CA – die interne CA ist ein besonders wertvolles Ziel; bei einer Kompromittierung werden alle Servicezertifikate ungültig. HSM-gestützte CAs und Offline-Root-CAs mindern dieses Risiko. (3) Debugging – verschlüsselter mTLS-Datenverkehr ist für herkömmliche Debugging-Tools undurchsichtig; die Observability des Service Mesh (Jaeger, Kiali) wird benötigt. (4) Kompatibilität mit Middleboxes – TLS-Inspektionsproxys unterbrechen mTLS, sofern sie nicht ausdrücklich so konfiguriert sind, dass sie Clientzertifikate durchreichen. (5) Vorfälle durch abgelaufene Zertifikate – ein Fehler bei der Rotation kann zu vollständigen Ausfällen eines Services führen.

SPIFFE (Secure Production Identity Framework for Everyone) definiert einen Standard für Workload-Identitäten mithilfe von X.509-SVIDs. SPIRE (SPIFFE Runtime Environment) ist die Referenzimplementierung. Der SPIRE Server fungiert als Registrierungsstelle und CA. SPIRE Agents laufen auf jedem Knoten, bestätigen die Workload-Identität mithilfe von Node-Attestors (AWS instance identity, Kubernetes service account JWT, TPM) und Workload-Attestors (Unix PID, Metadaten der Container-Laufzeitumgebung). Die Workload API stellt Workloads SVIDs über einen Unix-Domain-Socket mithilfe einer einfachen gRPC-API bereit. SPIRE lässt sich als Zertifikatsquelle in Envoy, Nginx und die wichtigsten Service Meshes integrieren.

Bei mTLS-Bereitstellungen mit hohen Sicherheitsanforderungen sollten private Schlüssel in Hardware Security Modules (HSMs) und nicht in Softwareschlüsselspeichern liegen. Die TLS-Bibliothek (OpenSSL, BoringSSL) lädt den privaten Schlüssel über die PKCS#11-Schnittstelle, die Signaturvorgänge an das HSM weiterleitet. Der private Schlüssel verlässt die HSM-Grenze niemals im Klartext. Zu den Cloud-HSM-Optionen gehören AWS CloudHSM, Azure Dedicated HSM und Google Cloud HSM. Für gerätebasiertes mTLS (IoT, Unternehmenslaptops) bietet TPM 2.0 eine ähnliche Funktion – der TLS-Clientschlüssel ist an das TPM gebunden, und zum Signieren ist eine TPM-Autorisierung erforderlich. Dadurch wird das Extrahieren des Schlüssels von einem kompromittierten Gerät äußerst schwierig.

Zum Testen von mTLS werden Tools benötigt, die Clientzertifikate vorlegen können. OpenSSL s_client: openssl s_client -connect host:443 -cert client.pem -key client.key -CAfile server-ca.pem. curl: curl --cert client.pem --key client.key --cacert server-ca.pem https://host. Für Tests des Service Mesh zeigt istioctl proxy-config secret pod/name das aktuelle Zertifikat und dessen Ablaufdatum an. Führen Sie kubectl exec in einem Pod aus und verwenden Sie curl für den Sidecar-Admin-Endpunkt (localhost:15000), um aktive Listener und deren mTLS-Konfiguration zu untersuchen. Automatisierte Rotationstests sollten überprüfen, dass Verbindungen während Ereignissen der Zertifikatsrotation stabil bleiben.

Welchen zusätzlichen Schritt fügt mTLS gegenüber Standard-TLS hinzu?

mTLS ergänzt TLS um die Authentifizierung per Clientzertifikat – beide Seiten überprüfen die Zertifikate der jeweils anderen Seite. SPIFFE SVIDs stellen eine standardisierte Workload-Identität über SPIFFE-URIs in den Zertifikats-SANs bereit. Istio implementiert mTLS transparent über Envoy-Sidecars mit den Modi STRICT/PERMISSIVE. Kurzlebige Zertifikate (24 Stunden) machen eine Zertifikatswiderrufung überflüssig und begrenzen das Zeitfenster einer Kompromittierung. SPIRE automatisiert die Ausstellung und Rotation von Zertifikaten über die Workload API. Private mTLS-Schlüssel sollten bei Bereitstellungen mit hohen Sicherheitsanforderungen in HSMs oder TPMs gespeichert werden. Zu den betrieblichen Herausforderungen gehören der Schutz des CA-Schlüssels, die Kompatibilität mit Middleboxes und eine Rotation ohne Ausfallzeit.