---
title: "mTLS vs TLS erklärt: Zwei Identitäten, eine Verbindung"
description: "mTLS und TLS verständlich erklärt: Handshake, Zertifikatsvertrauen, Autorisierung und Proxy-Grenzen, mit einem reproduzierbaren lokalen Beispiel und acht geprüften Ergebnissen."
author: Aleksei Aleinikov
date: 2026-11-04
lang: de
tags: [mtls, tls, mutual-tls, authentication, api-security, certificates, zero-trust]
canonical: https://www.alekseialeinikov.com/de/blog/topics/security/mtls-vs-tls-erklaert
source: alekseialeinikov.com
---

# mTLS vs TLS erklärt: Zwei Identitäten, eine Verbindung

Der Client prüft das Zertifikat, die Verbindung ist verschlüsselt und die API zeigt ein beruhigendes Schloss. Wer dort anruft, weiß die API deshalb noch nicht. Ein Unbekannter kann dieselbe gewöhnliche HTTPS-Verbindung aufbauen und denselben Endpunkt anfragen. Die Anwendung muss entscheiden, wie sie mit der Anfrage umgeht.

**Mutual TLS ergänzt eine zweite Identitätsprüfung: Auch der Client muss sich gegenüber dem Server ausweisen.** Das schafft eine nützliche Grenze für Dienste, Geräte und Partner-APIs. Danach folgt allerdings noch eine Entscheidung: Ein Client kann ein vollständig gültiges Zertifikat präsentieren, mTLS erfolgreich abschließen und trotzdem ein `403 Forbidden` verdienen. Dieser Artikel verfolgt diese Unterscheidung vom Handshake bis zu einem lauffähigen lokalen Beispiel.

![mTLS vs TLS: Zwei Identitätspässe vor einer getrennten Zugangsschranke verdeutlichen gegenseitige Authentifizierung und die anschließende Autorisierung.](https://www.alekseialeinikov.com/blog/mtls-vs-tls.webp)

## Was ist mTLS?

**mTLS ist TLS mit gegenseitiger Zertifikatsauthentifizierung, kein eigenständiges Transportprotokoll.** Beim vertrauten zertifikatsbasierten HTTPS authentifiziert der Client den Server. Bei mTLS fordert der Server zusätzlich ein Client-Zertifikat an und prüft, ob der Client den dazugehörigen privaten Schlüssel besitzt. So verwendet [RFC 8705, Abschnitt 1.2](https://www.rfc-editor.org/rfc/rfc8705.html#section-1.2) den Begriff.

Die Eingrenzung ist wichtig: TLS kennt auch PSK- und Wiederaufnahmemodi. „TLS authentifiziert nur den Server“ beschreibt gewöhnliches zertifikatsbasiertes HTTPS sinnvoll, umfasst aber nicht jeden möglichen TLS-Handshake.

## mTLS vs TLS: die wichtigsten Unterschiede

| Frage | Gewöhnliches TLS mit Server-Authentifizierung | mTLS |
|---|---|---|
| Authentifiziert der Client den Server? | Ja | Ja |
| Authentifiziert TLS den Client per Zertifikat? | Nein | Ja, wenn verlangt und erfolgreich geprüft |
| Braucht der Client ein eigenes Zertifikat und einen privaten Schlüssel? | Nein | Ja |
| Werden Anwendungsdaten verschlüsselt? | Ja | Ja |
| Ist die Verschlüsselung automatisch stärker? | Nein | Keine zusätzliche Verschlüsselungsschicht |
| Wer entscheidet, ob `/orders` erlaubt ist? | Anwendung oder Gateway-Richtlinie | Anwendung oder Gateway-Richtlinie |
| Was muss der Betrieb verwalten? | Server-Zugangsdaten und Vertrauen | Beide Seiten, Vertrauensanker und Client-Richtlinien |

Eine passende Analogie ist ein Anruf bei einem Unternehmen, dessen Nummer geprüft wurde. Man weiß, wen man erreicht hat; die Person am anderen Ende hat die Identität des Anrufers noch nicht festgestellt. mTLS ergänzt diese Gegenprüfung. Eine Erstattung genehmigen darf der Anrufer deshalb noch lange nicht.

### mTLS vs HTTPS: Kann eine HTTPS-API mTLS verwenden?

Ja. HTTPS ist HTTP-Kommunikation über TLS; so beschreibt es [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#section-4.2.2). Ein HTTPS-Endpunkt kann zusätzlich Client-Zertifikate verlangen: Das ist HTTPS mit mTLS. Es sind keine konkurrierenden Alternativen. Das zusätzliche Zertifikat stellt die Identität des aufrufenden Clients fest. Die Anwendung kann weiterhin eine Session oder ein Access Token verlangen und Zugriffsrechte prüfen.

## TLS-1.3-Handshake: Das Zertifikat ist nur die halbe Prüfung

Ein Zertifikat ist öffentlich. Wer `client.crt` kopiert, kann sich damit allein noch nicht als dieser Client anmelden. Den fehlenden Nachweis liefert der private Schlüssel: **CertificateVerify signiert Handshake-Material** und bindet den Schlüsselbesitz an diese Verbindung.

![mTLS vs TLS Handshake: Beide Abläufe authentifizieren den Server; mTLS ergänzt CertificateRequest, Client Certificate und Client CertificateVerify vor dem Client Finished.](https://www.alekseialeinikov.com/blog/mtls-vs-tls-handshake.webp "Verkürzter vollständiger TLS-1.3-Handshake. Der zusätzliche Client-Nachweis wird innerhalb des verschlüsselten Handshakes übertragen.")

Bei einem vollständigen zertifikatsbasierten TLS-1.3-Handshake:

1. `ClientHello` und `ServerHello` legen Parameter und Schlüsselaustausch fest.
2. Der Server sendet seine verschlüsselten Handshake-Nachrichten einschließlich Zertifikat, Nachweis und `Finished`. Für mTLS kommt `CertificateRequest` hinzu.
3. Der Client prüft den Server. Falls angefordert, sendet er sein Zertifikat und `CertificateVerify`, danach `Finished`.
4. Der Server prüft den Client, bevor er ihn entsprechend seiner Client-Authentifizierungsrichtlinie zulässt.

TLS 1.3 verschlüsselt den Austausch des Client-Zertifikats. In einem typischen initialen TLS-1.2-Handshake war dieses Zertifikat für einen passiven Beobachter sichtbar. Hat der Client kein geeignetes Zertifikat, sendet er eine leere Zertifikatsnachricht. Der Server kann abbrechen oder ohne Zertifikatsauthentifizierung fortfahren. **Verpflichtendes mTLS muss den nicht authentifizierten Fall tatsächlich zurückweisen.**

Die aktuelle TLS-1.3-Spezifikation ist Eric Rescorlas [RFC 9846](https://datatracker.ietf.org/doc/rfc9846/), veröffentlicht im Juli 2026 als Nachfolger von RFC 8446. Die Protokollversion bleibt TLS 1.3. Die Veröffentlichung bedeutet nicht, dass jede Bibliothek bereits jede Überarbeitung umgesetzt hat.

Die Grafik zeigt einen vollständigen Handshake. Wiederaufnahme und 0-RTT sind gesonderte Fälle; für Early Data darf keine neue Client-Zertifikatsprüfung vorausgesetzt werden. Early Data lässt sich außerdem erneut abspielen. Bei einer sensiblen API bleibt die Funktion sinnvollerweise deaktiviert, solange die Anwendung nicht bewusst ein geeignetes Replay-sicheres Verfahren implementiert.

## Drei Prüfungen, die getrennt bleiben müssen

Zwei Dienste heißen `checkout` und `reporting`. Beide besitzen Zertifikate desselben vertrauenswürdigen Ausstellers. Bestellungen übermitteln darf ausschließlich `checkout`.

| Prüfung | Frage | Beispiel eines Fehlers |
|---|---|---|
| Zertifikatsvalidierung | Erfüllt der Nachweis die konfigurierten Regeln für Vertrauen, Gültigkeit und Verwendungszweck? | Unbekannter Aussteller, abgelaufenes Zertifikat, falsche EKU |
| Peer-Identität | Welche Identität oder welcher konkrete Nachweis wurde belegt? | Zertifikat gehört zu `reporting`, nicht zu `checkout` |
| Autorisierung | Darf dieser Peer diese Operation auf dieser Ressource ausführen? | Authentifiziertes `reporting` ruft einen Checkout-Endpunkt auf |

![mTLS Autorisierung: Zertifikatsprüfung, Peer-Identität und Zugriffsrecht sind drei Schranken; ein vertrauenswürdiger Reporting-Client besteht TLS und erhält bei der Orders-Richtlinie HTTP 403.](https://www.alekseialeinikov.com/blog/mtls-vs-tls-authorization.webp "Einem Aussteller zu vertrauen bedeutet nicht, jedes von ihm ausgestellte Zertifikat für jede Aktion zu autorisieren.")

Ein Aussteller kann berechtigt Zertifikate für Hunderte Workloads signieren. Alle davon als Administratoren zu behandeln wäre ein Fehler der Anwendungsrichtlinie, selbst bei vollständig korrekter Kryptografie. Die Identität im Zertifikat braucht zudem eine vereinbarte Bedeutung: einen erwarteten SAN, einen registrierten Nachweis oder eine Workload-Identität unter kontrolliertem Aussteller und Trust Domain. Ein plausibler Common Name aus irgendeinem Zertifikat genügt nicht.

Die Behauptung „mTLS blockiert bösartige API-Anfragen“ ist deshalb zu weit gefasst. mTLS kann Clients zurückweisen, die seine Zertifikatsrichtlinie nicht erfüllen. Ein kompromittierter Client mit gültigem Schlüssel kann weiterhin schädliche Anfragen senden. Eingabeprüfung, Autorisierung, Rate Limits und Begrenzung der Auswirkungen bleiben nötig.

> [!KEY]
> Ein gültiges Zertifikat beantwortet eine Vertrauensfrage. Ob dieser Client die Bestellung eines anderen Kunden lesen darf, ist eine eigene Entscheidung.

## Ein lokales mTLS-Beispiel mit acht geprüften Ergebnissen

Das [vollständige Beispiel](https://www.alekseialeinikov.com/examples/mtls-vs-tls/demo.mjs) verwendet Node.js-Bordmittel und die installierte OpenSSL-CLI. Es erzeugt getrennte temporäre Server- und Client-CAs, stellt Testzertifikate aus, bindet ausschließlich an `127.0.0.1`, prüft die Fälle und löscht anschließend die temporären Schlüssel. npm-Abhängigkeiten oder Produktionszugangsdaten werden nicht benötigt.

Quelltext herunterladen, prüfen und in einem leeren Arbeitsverzeichnis ausführen:

```bash
node --version
openssl version
node demo.mjs
```

Die entscheidende Serverkonfiguration ist kurz:

```js title="demo.mjs — TLS-Prüfung"
const server = https.createServer({
  key: serverKey,
  cert: serverCertificate,
  ca: clientCa,
  requestCert: true,
  rejectUnauthorized: true,
  minVersion: 'TLSv1.3',
  maxVersion: 'TLSv1.3',
}, handler);
```

`requestCert` fordert den Client-Nachweis an. `rejectUnauthorized` macht fehlgeschlagene Prüfungen zum Abbruchgrund. Mit `ca` vertraut dieser Server einem bestimmten Client-Aussteller; der Client vertraut separat der Server-CA und prüft den Servernamen. Das sind zwei unabhängige Vertrauensrichtungen. [Node.js-TLS-Optionen](https://nodejs.org/api/tls.html#tlscreateserveroptions-secureconnectionlistener).

Der Handler trifft anschließend eine bewusst enge Autorisierungsentscheidung:

```js title="demo.mjs — Autorisierung der Anwendung"
const allowed = new X509Certificate(approvedClientPem).fingerprint256;

function handler(req, res) {
  const permitted = req.method === 'GET' && req.url === '/orders' &&
    req.socket.authorized &&
    req.socket.getPeerCertificate().fingerprint256 === allowed;
  res.writeHead(permitted ? 200 : 403);
  res.end(permitted ? 'orders accepted\n' : 'access denied\n');
}
```

Das Laborbeispiel hinterlegt genau ein Leaf-Zertifikat, damit die zweite Entscheidung sichtbar bleibt. Es ist kein allgemeines Identitätsverzeichnis: Bei Erneuerung muss der Fingerprint angepasst werden. Produktive Workload-Richtlinien ordnen üblicherweise einer etablierten Identität Rechte zu, statt einzelne Leaf-Fingerprints von Hand zu pflegen.

Folgende Ergebnisse wurden am 4. November 2026 mit Node.js 24.22.2 und 26.13.0 sowie OpenSSL CLI 4.1.0 reproduziert:

| Fall | Beobachtetes Ergebnis | Abbruchstelle |
|---|---|---|
| Freigegebener Client, korrekter Servername | HTTP `200` | Anfrage akzeptiert |
| Freigegebener Client fordert `/admin` an | HTTP `403` | Ressourcenrichtlinie der Anwendung |
| Kein Client-Zertifikat | Verbindung abgewiesen | TLS-Client-Authentifizierung |
| Zertifikat einer nicht vertrauten Client-CA | Verbindung abgewiesen | TLS-Zertifikatsvalidierung |
| Vertrauenswürdiger Aussteller, aber nur `serverAuth`-EKU | Verbindung abgewiesen | TLS-Prüfung des Verwendungszwecks |
| Gültiges Client-Zertifikat außerhalb der Anwendungs-Allowlist | HTTP `403` | Autorisierung der Anwendung |
| Derselbe nicht freigegebene Client ergänzt einen gefälschten `Client-Cert`-Header | HTTP `403` | Anwendung prüft weiterhin den TLS-Peer statt des Headers |
| Freigegebener Client verwendet den falschen Servernamen | Verbindung abgewiesen | Server-Identitätsprüfung des Clients |

Erfolgreiche und mit `403` abgewiesene Anfragen verwendeten TLS 1.3. Bei den zurückgewiesenen Verbindungen gab es keine Anwendungsantwort. Fehlertexte unterscheiden sich zwischen Laufzeiten: Bei einigen serverseitigen Validierungsfehlern sah der Client beispielsweise `ECONNRESET`, während der Server einen TLS-Prüffehler meldete. Das Skript prüft diese Fehler und wertet keinen beliebigen Timeout als Erfolg.

Das sind Funktionsprüfungen, **kein Durchsatz-Benchmark**. Sie zeigen den Unterschied zwischen gescheitertem Handshake und verweigerter authentifizierter Anfrage. Der Header-Test verwendet einen direkten Server, der solche Header ignoriert; er simuliert oder zertifiziert keine produktive Proxy-Konfiguration.

## Die Reverse-Proxy-Falle: Wo endet mTLS?

Ein Load Balancer verändert die Vertrauensgrenze. Schließt der Client mTLS am Edge ab, hat das Edge-System den Client authentifiziert. Eine neue TLS-Verbindung vom Edge zur Anwendung belegt etwas über diesen zweiten Peer. Die ursprüngliche Client-Identität wird dabei nicht automatisch übertragen.

![mTLS Reverse Proxy und Vertrauensgrenze: Der Client authentifiziert sich am Edge, eine getrennte geschützte Verbindung führt zur Anwendung; direkte Zugriffe und gefälschte Zertifikatsheader müssen blockiert werden.](https://www.alekseialeinikov.com/blog/mtls-vs-tls-proxy.webp "TLS-Terminierung erzeugt eine Identitätsübergabe. Die Anwendung muss deren Absender und Verarbeitungsregeln vertrauen können.")

Eine Anwendung, die `Client-Cert: admin` von jedem erreichbaren Aufrufer akzeptiert, hat einen kryptografischen Schlüsselnachweis durch eine vom Absender kontrollierte Zeichenfolge ersetzt.

Für die Übergabe gibt es eine IETF-Spezifikation: **RFC 9440, Client-Cert HTTP Header Field**, veröffentlicht 2023 als Informational RFC. Sie definiert `Client-Cert` und `Client-Cert-Chain`, macht beliebige Header aber nicht vertrauenswürdig. Der Proxy entfernt oder überschreibt eingehende Instanzen, validiert den Client nach seiner Richtlinie und setzt die geprüften Zertifikatsinformationen ein. Der Origin braucht eine vertrauenswürdige Beziehung zu diesem Proxy und Schutz vor dessen Umgehung. [RFC 9440, Verarbeitungsregeln und Sicherheitsaspekte](https://www.rfc-editor.org/rfc/rfc9440.html#section-2.4).

Für den Betrieb müssen drei Eigenschaften zusammenkommen:

- Die Anwendung ist über den vorgesehenen Proxy-Pfad erreichbar; alternative Eingänge können keine Identität einschleusen.
- Verbindung und Peer zwischen Proxy und Origin sind angemessen geschützt und authentifiziert.
- Identitätsheader stammen aus dem validierten Verbindungszustand des Proxys; vom Client gelieferte Werte werden entfernt oder abgewiesen.

„HTTPS auf beiden Strecken“ allein stellt das nicht sicher. Weitergabeformat und Vertrauenseinstellungen des gewählten Produkts müssen geprüft werden. Konventionen für `X-Forwarded-Client-Cert` sind nicht mit der Kodierung aus RFC 9440 austauschbar.

## mTLS vs OAuth und JWT: unterschiedliche Aufgaben

mTLS kann die Identität des aufrufenden Dienstes feststellen. OAuth kann delegierte Rechte beschreiben, ein JWT Benutzer- oder Berechtigungsinformationen transportieren. Wenn ein Checkout-Dienst im Auftrag eines Kunden eine Bestellung auslöst, sind beide Fragen relevant: **Welcher Dienst hat sich verbunden, und was darf diese Anfrage für diesen Kunden ausführen?** Die Tokenprüfung erklärt der [JWT-Artikel](https://www.alekseialeinikov.com/de/blog/topics/security/jwt-erklaert-json-web-token).

mTLS am Token-Endpunkt allein macht nicht jedes Access Token diebstahlresistent. RFC 8705 definiert **zertifikatsgebundene Access Tokens**. Der Ressourcenserver muss die Bindung an das Zertifikat seiner Verbindung prüfen; die JWT-Darstellung nutzt dafür `cnf.x5t#S256`. Client-Authentifizierung am Token-Endpunkt und Bindung des ausgestellten Tokens sind getrennte Funktionen. Zertifikatswechsel müssen mit gebundenen Tokens abgestimmt werden. [RFC 8705, Abschnitte 3 und 6.3](https://www.rfc-editor.org/rfc/rfc8705.html#section-3).

Für eine öffentliche Browseranwendung ist gewöhnliches HTTPS mit geeigneter Session- oder OAuth-Verarbeitung oft der praktische Ausgangspunkt. Verwaltete Geräte und Maschinenclients passen besser zur Zertifikatsverteilung. Bei Webhooks kann die Transportidentität die Signatur des Anbieters ergänzen; dazu [Webhook-Authentifizierung und zuverlässige Zustellung](https://www.alekseialeinikov.com/de/blog/topics/architecture/webhooks-erklaert-signatur-retries-idempotenz).

## Zertifikatsbetrieb: Was das Handshake-Bild ausblendet

Bei der CA beginnt die Identitätskette. Festgelegt werden muss, wer sich registrieren darf, welcher Workload oder Partner welche Identität erhält und welchen Ausstellern die Gegenseite vertrauen darf. Ein gemeinsames, sehr breites Trust Bundle für alle Umgebungen erleichtert die Annahme gültiger Nachweise am falschen Ort.

Eine brauchbare Betriebsliste ist konkret:

| Entscheidung | Betriebsfrage |
|---|---|
| Enrollment | Welcher Nachweis berechtigt einen Workload zu dieser Identität? |
| Verwendungszweck | Erlaubt das Leaf-Zertifikat die vorgesehene Client- oder Server-Authentifizierung? |
| Schlüsselaufbewahrung | Welcher Prozess erreicht den privaten Schlüssel, und was geschieht bei Diebstahl? |
| Rotation | Lassen sich Ersatzschlüssel, Zertifikat und Trust Bundle ohne Ausfall verteilen? |
| Sofortiger Zugriffsentzug | Wie wird eine Identität jetzt gestoppt, einschließlich aktiver Verbindungen und Wiederaufnahme? |
| Autorisierung | Welche Identität darf welche Methode auf welcher Ressource ausführen? |

Kurze Laufzeiten begrenzen das Zeitfenster eines Missbrauchs. Sie sperren gestohlene Nachweise nicht sofort. Das Ablaufdatum eines Zertifikats ist außerdem kein Timer, der zwangsläufig eine bereits bestehende Anwendungssitzung beendet. Neben Erneuerungsalarmen braucht es Zugriffsentzug und eine Strategie für bestehende Verbindungen.

SPIFFE gibt Workload-Identitäten eine definierte Form; ein X.509-SVID enthält eine SPIFFE ID innerhalb einer Trust Domain. Das hilft, wenn Workloads kurzlebiger als Maschinen sind. Ein vertrauenswürdiges Ausstellungs- und Prüfverfahren bleibt nötig. [SPIFFE-Konzepte](https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/).

Bei Istio steuert **PeerAuthentication**, ob Peers mTLS verwenden müssen. `PERMISSIVE` akzeptiert mTLS und Klartext, `STRICT` verlangt mTLS im jeweiligen Geltungsbereich. **AuthorizationPolicy** legt die Zugriffsregeln fest. Strikte Peer-Authentifizierung allein ist keine Checkout-Allowlist. [PeerAuthentication](https://istio.io/latest/docs/reference/config/security/peer_authentication/), [AuthorizationPolicy](https://istio.io/latest/docs/reference/config/security/authorization-policy/). Der [Vergleich Cilium vs Calico](https://www.alekseialeinikov.com/de/blog/topics/devops/cilium-vs-calico-kubernetes-cni-vergleich) ordnet dies neben Netzwerkverschlüsselung und Netzwerkrichtlinien ein.

## Eine Änderung, die bestehende Zertifikatskonfigurationen treffen kann

Let's Encrypt hat die Ausstellung mit **clientAuth-EKU** am 8. Juli 2026 beendet; aus dem Standardprofil `classic` war die EKU bereits am 11. Februar entfernt worden. Die Serverzertifikate eignen sich weiterhin zur Server-Authentifizierung. Wer dieselben Zertifikate als Client-Nachweise verwendet hat, braucht dafür geeigneten Ersatz. [Ankündigung und aktualisierter Zeitplan von Let's Encrypt](https://letsencrypt.org/2025/05/14/ending-tls-client-authentication).

Daraus folgt kein Verbot sämtlicher Client-Zertifikate aller CAs. Für interne Dienste ist eine private PKI häufig sinnvoll, weil die Organisation Enrollment und Vertrauen selbst kontrolliert. Server- und Client-Zertifikat dürfen von unterschiedlichen Ausstellern stammen, wie das Beispiel zeigt.

## Welche Konfiguration passt zum System?

| Situation | Ausgangspunkt |
|---|---|
| Öffentliche Website für beliebige Browser | TLS mit Server-Authentifizierung plus Sessions oder OAuth |
| Interne Dienste mit kontrollierten Workload-Identitäten | mTLS plus explizite Dienst- und Anfrageautorisierung |
| Partner-API mit definierter Client-Gruppe | mTLS mit klaren Prozessen für Enrollment, Erneuerung und Vorfälle |
| Delegierter API-Zugriff mit relevantem Token-Diebstahlrisiko | Zertifikatsgebundene Tokens prüfen und Bindung am Ressourcenserver durchsetzen |
| Anwendung hinter einem TLS-terminierenden Edge | Identitätsübergabe entwerfen und prüfen, bevor weitergereichte Angaben vertraut werden |

Die entscheidenden Fragen lauten: **Welche Identität wurde festgestellt, wer vertraut dem Aussteller, wie überlebt die Identität die Terminierung und welche Aktion erlaubt sie?** Endet die Antwort bei „der Handshake war erfolgreich“, ist die Zugriffskontrolle noch nicht fertig entworfen.