mTLS

mTLS (Mutual TLS, auch Mutual Transport Layer Security) ist eine Erweiterung des TLS-Protokolls, bei der sich nicht nur der Server gegenüber dem Client authentifiziert, sondern auch der Client gegenüber dem Server. Bei einer normalen HTTPS-Verbindung prüft nur der Browser, ob das SSL-Zertifikat des Servers gültig ist. Bei mTLS weisen sich beide Seiten per Zertifikat aus — daher der Name "gegenseitige Authentifizierung".

Wie funktioniert mTLS?

mTLS erweitert den TLS-Handshake um einen zusätzlichen Schritt: Der Server fordert ein Client-Zertifikat an und prüft es.

1. Client verbindet sich: Der Client baut eine TLS-Verbindung zum Server auf.
2. Server authentifiziert sich: Der Server sendet sein SSL-Zertifikat. Der Client prüft es gegen vertrauenswürdige Zertifizierungsstellen — wie bei jeder HTTPS-Verbindung.
3. Server fordert Client-Zertifikat: Der Server sendet eine "Certificate Request"-Nachricht und teilt mit, welche Zertifizierungsstellen er akzeptiert.
4. Client authentifiziert sich: Der Client sendet sein Client-Zertifikat. Der Server prüft es gegen seine Liste vertrauenswürdiger CAs oder gegen eine Private PKI.
5. Verbindung steht: Erst wenn beide Zertifikate gültig sind, wird die verschlüsselte Verbindung aufgebaut.

Was unterscheidet mTLS von normalem TLS?

Der Unterschied liegt in der Richtung der Authentifizierung.

Wo wird mTLS eingesetzt?

mTLS kommt überall dort zum Einsatz, wo einfache Passwort-Authentifizierung nicht ausreicht und beide Kommunikationspartner zweifelsfrei identifiziert werden müssen.

• Microservices und APIs: In Kubernetes-Clustern und Service-Mesh-Architekturen (z.B. Istio, Linkerd) kommunizieren Dienste untereinander per mTLS. Jeder Service hat ein eigenes Zertifikat.
• Zero-Trust-Architekturen: mTLS ist ein Kernbaustein von Zero-Trust: Kein Dienst vertraut einem anderen ohne Zertifikatsnachweis — auch nicht innerhalb des eigenen Netzwerks.
• VPN und Remote-Zugang: Mitarbeiter authentifizieren sich per Client-Zertifikat am Firmennetzwerk. Sicherer als Passwort allein.
• IoT und Geräte-Kommunikation: Sensoren und Steuerungen weisen sich per Geräte-Zertifikat am Zentralsystem aus.
• Finanzbranche: Banken nutzen mTLS für die sichere Kommunikation zwischen Zahlungssystemen (PSD2 verlangt zertifikatsbasierte Authentifizierung).
• Cloud-Infrastruktur: Verbindungen zwischen Cloud-Diensten und On-Premise-Systemen werden per mTLS abgesichert.

Was braucht man für mTLS?

Für mTLS benötigen beide Seiten — Server und Client — je ein gültiges Zertifikat.

• Server-Zertifikat: Ein SSL-Zertifikat, wie es für jede HTTPS-Website benötigt wird. Kann ein DV-Zertifikat, OV-Zertifikat oder Wildcard-Zertifikat sein.
• Client-Zertifikat: Ein digitales Zertifikat für den Nutzer oder das Gerät. Wird entweder von einer öffentlichen CA oder über eine Private PKI ausgestellt. Anleitungen zur Einrichtung finden Sie unter Client-Zertifikate einrichten.
• Zertifizierungsstelle (CA): Beide Zertifikate müssen von einer CA ausgestellt sein, der die Gegenseite vertraut. Für interne Systeme reicht eine Private PKI.
• Server-Konfiguration: Der Webserver (Apache, Nginx, etc.) muss so konfiguriert werden, dass er Client-Zertifikate anfordert und prüft.

Welche Vorteile bietet mTLS?

mTLS eliminiert mehrere Schwachstellen klassischer Authentifizierungsmethoden.

• Phishing-resistent: Zertifikate können nicht durch Social Engineering abgefangen werden — im Gegensatz zu Passwörtern.
• Keine Passwörter: Kein Vergessen, kein Zurücksetzen, keine Brute-Force-Angriffe.
• Starke Identität: Jedes Zertifikat ist kryptografisch eindeutig und an eine Identität gebunden.
• Verschlüsselung inklusive: Die TLS-Verbindung ist gleichzeitig verschlüsselt — Authentifizierung und Verschlüsselung in einem Schritt.
• Automatisierbar: Zertifikate können über ACME oder SCEP automatisch ausgestellt und erneuert werden.

Welche Einschränkungen hat mTLS?

mTLS ist sicherer als passwortbasierte Verfahren, bringt aber zusätzlichen Verwaltungsaufwand mit sich.

• Zertifikatsmanagement: Jeder Client braucht ein eigenes Zertifikat. Bei hunderten oder tausenden Geräten ist eine automatisierte PKI notwendig.
• Ablauf und Erneuerung: Zertifikate haben ein Ablaufdatum. Ohne automatische Erneuerung verlieren Clients den Zugang.
• Nicht für öffentliche Websites: mTLS eignet sich nicht für Websites mit anonymen Besuchern — dort fehlt das Client-Zertifikat. Für öffentliche Websites reicht ein normales SSL-Zertifikat.
• Debugging: Fehler bei der Zertifikatsvalidierung können schwieriger zu diagnostizieren sein als fehlgeschlagene Logins.

Fazit

mTLS (Mutual TLS) erweitert die Standard-TLS-Verschlüsselung um eine gegenseitige Authentifizierung: Nicht nur der Server, sondern auch der Client weist sich per Zertifikat aus. Das macht mTLS zum Standard für API-Sicherheit, Microservices, Zero-Trust-Architekturen und überall dort, wo Passwörter nicht sicher genug sind. Voraussetzung ist ein SSL-Zertifikat auf Serverseite und ein Client-Zertifikat auf Clientseite — beides lässt sich über eine eigene oder verwaltete PKI bereitstellen.