TLS-Verschlüsselung ist keine Authentifizierung — mTLS ist das, was beweist, wer der Client ist.
Eine Standard-TLS-Verbindung verschlüsselt Traffic, beweist aber in den meisten Szenarien nicht, wer der Client tatsächlich ist. Passwörter, API-Keys, IP-Allowlists und Token-basierte Kontrollen fügen Sicherheitsschichten hinzu, können aber geteilt, durchgesickert, kopiert oder im falschen Kontext verwendet werden. mTLS hingegen verifiziert, dass der Client den privaten Schlüssel besitzt, und erzeugt damit ein stärkeres Identitätssignal auf Verbindungsebene.
In B2B-APIs, Zahlungsflüssen, Gesundheitsdaten-Sharing, IoT-Geräte-Traffic und Verwaltungsschnittstellen-Zugang ist dieser Unterschied kritisch. Jeder Partner, jedes Gerät oder jeder Administrator kommt mit seinem eigenen Zertifikat; Zertifikatslaufzeit, CA-Kette, CN, Fingerabdruck und Verifikationsergebnis sind alle auditierbar. Das unabhängige Parsen dieser Informationen durch jede Anwendung erhöht jedoch die operative Komplexität.
Bei traditionellen mTLS-Deployments sind CA-Bundle-Verwaltung, Verify-Modus-Auswahl, Fehlercodes, Zertifikatsfeld-Extraktion und die Weiterleitung dieser Informationen an die Anwendung fragmentierte Anliegen. Eine Umgebung erfordert möglicherweise ein obligatorisches Zertifikat, während eine andere während eines Übergangs optional-Modus benötigt. Legacy-CA-Ketten, Test-Zertifikate und Partner-Migrationen erfordern alle eine feine Balance zwischen strenger Validierung und kontrollierter Toleranz.
Der richtige Ansatz besteht darin, mTLS als Service-Profil zu verwalten. Verify-Modus, CA-Datei, CA-Fehlerstrategie, Weiterleitung von Zertifikatsfeldern an das Backend und AAM Conditional-Access-Richtlinien sollten alle im selben Modell zusammenleben.
TR7 TLS / mTLS Client-Zertifikat-Authentifizierung liefert dieses Modell: Es hebt das Client-Zertifikat aus der verbindungsebenen Kontrolle heraus und verwandelt es gleichermaßen in ein nutzbares Identitätsobjekt für Backend-Dienste und Zugriffsrichtlinien.
Unser Ansatz
TR7 wendet mTLS-Verifizierung gemeinsam mit per-Service-Verify-Modus, CA-Verwaltung, Zertifikatsfeld-Weiterleitung und AAM-Zugriffsrichtlinie in einem einzigen kohärenten Modell an.
Drei Verify-Modi decken verschiedene Migrations- und Sicherheitsstufen ab
Mit none-, optional- und required-Modi kann jeder Dienst seine eigene mTLS-Richtlinie anwenden. Zertifikate können obligatorisch gemacht, während einer Transition optional gehalten oder für einen bestimmten Dienst ganz deaktiviert werden.
Zertifikatsfelder werden als HTTP-Header an das Backend weitergeleitet
Verifikationscode, SHA1-Fingerabdruck, CN und zusätzliche Zertifikatsfelder können auf HTTP-Header abgebildet werden. Das Backend liest Identitätsinformationen direkt, ohne das Zertifikat selbst parsen zu müssen.
Backend und Verwaltungsschicht verwenden Zertifikatsdaten nativ
Zertifikats-Header können in Felder wie present, verified, verify, sha1 und cn geparst werden. Selbst wenn die Verifizierung fehlschlägt, können Zertifikatsdaten auf kontrollierte Weise protokolliert und an die Entscheidungs-Engine übergeben werden.
CA-Fehlerstrategie trennt Migrations- von Produktionsverhalten
CA-Validierungsfehler können ganz abgelehnt, während eines Übergangs toleriert oder nur für bestimmte Fehlercodes gelockert werden. So können Staging-, Partner-Migrations- und Produktionsrichtlinien im selben mTLS-Modell koexistieren.
Fähigkeiten
TLS / mTLS Client-Zertifikat-Authentifizierung verifiziert, parst, protokolliert und teilt das Client-Zertifikat mit dem Backend — alles am Edge.
Per-Service-mTLS-Richtlinie wird mit none-, optional- und required-Modi gesetzt
TR7 verwaltet das Client-Zertifikat-Authentifizierungsverhalten unabhängig für jeden Dienst. Im none-Modus wird kein Zertifikat angefordert. Im optional-Modus wird ein Zertifikat geparst, wenn es präsentiert wird; wenn es fehlt, kann die Verbindung fortgesetzt werden. Im required-Modus wird jede Verbindung ohne Zertifikat abgelehnt. Diese Struktur bietet strenge Sicherheit in der Produktion, Flexibilität beim Staging und gestaffelten Rollout während der Migration. Verschiedene Dienste auf derselben Plattform können unterschiedliche mTLS-Anforderungen durchsetzen.
Jeder Dienst kann gegen sein eigenes CA-Bundle verifizieren
TR7 kann Client-Zertifikate gegen per-Service-CA-Dateien validieren. Die CA-Kette von Partner A kann auf einem Dienst verwendet werden, während die Kette von Partner B auf einem anderen angewendet wird. Diese Trennung ermöglicht es, verschiedene Geschäftspartner oder Gerätegruppen in Isolation auf demselben ADC zu verwalten, ohne auf eine einzige globale CA-Liste angewiesen zu sein. Ein separater Trust-Root wird pro Dienst definiert.
Zertifikats-Verifikationsergebnis wird als klarer Header an das Backend weitergeleitet
TR7 kann den Verifikationsstatus des Client-Zertifikats über Header wie x-ssl-verify an das Backend liefern. Erfolgreiche Verifizierung, Fehlen des Zertifikats oder ein spezifischer Verifikationsfehler ist für die Anwendung sichtbar. Das Backend kann Entscheidungen basierend auf dem mTLS-Status der Verbindung treffen, ohne sich mit dem TLS-Stack oder Zertifikats-Parsing befassen zu müssen.
CN und SHA1-Fingerabdruck übertragen Client-Identität zur Anwendung
TR7 kann Common Name und SHA1-Fingerabdruck aus dem Client-Zertifikat extrahieren und als Header an das Backend weiterleiten. Der CN kann als Partner-, Geräte-, Benutzer- oder Dienstbezeichner dienen. Der SHA1-Fingerabdruck bietet einen praktischen Schlüssel für Allowlisting-, Auditing-, Matching- oder Fast-Revoke-Szenarien. Fingerabdrücke werden normalisiert, sodass verschiedene Formatierungsstile nicht zu verschiedenen Identitätswerten führen.
CA-Fehlerstrategie bietet kontrollierte Toleranz während Übergängen
caErrorStrategy ermöglicht verschiedene Reaktionen auf CA-Validierungsfehler. ignoreAll kann alle CA-Fehler in temporären Debug- oder Migrationsszenarien tolerieren; manualIgnoreList begrenzt Toleranz auf bestimmte Validierungsfehlercodes. In der Produktion kann diese Flexibilität deaktiviert werden, um Zero-Toleranz durchzusetzen. Das Modell schafft eine kontrollierte Balance zwischen strenger Sicherheit und realem Migrationsbedarf.
ADC kann mTLS gegenüber dem Backend als Client aufbauen
TR7 fordert nicht nur Zertifikate von eingehenden Clients — es kann beim Verbinden mit einem Backend-Dienst auch selbst ein Client-Zertifikat präsentieren. Die backend-seitige Verbindung kann mit verify required, einer CA-Datei und einem ADC-Client-Zertifikat konfiguriert werden. Dies ermöglicht unabhängige TLS-Vertrauensrichtlinien sowohl auf dem Client-zu-TR7- als auch dem TR7-zu-Backend-Abschnitt. Traffic kann am Edge inspiziert werden, während die interne Verbindung vollständig gesichert bleibt.
AAM Conditional-Access-Richtlinien kombinieren sich mit Zertifikatsidentität
Ein Client-Zertifikat ist ein starkes Identitätssignal, muss aber nicht die vollständige Zugriffsentscheidung alleine tragen. TR7 kann Zertifikatsdaten als einen Eingang zu AAM Conditional-Access-Richtlinien verwenden. Zertifikat, IP-Adresse, Gerätestatus, Benutzergruppe, Tageszeit und MFA-Status können alle zusammen ausgewertet werden. mTLS wird zu einem Bestandteil einer umfassenderen Zero-Trust-Zugriffsentscheidung.
mTLS, WAAP und DDoS-Schutz operieren auf demselben Traffic-Pfad
Eine erfolgreiche Zertifikats-Verifizierung macht eine Anfrage nicht automatisch sicher — Inhalts- und Volumenkontrollen laufen weiter. TR7 führt die mTLS-Identitätsschicht neben WAAP, DDoS- und Bot-Verhaltensanalyse aus. mTLS legt fest, wer der Client ist; WAAP bewertet, was die Anfrage tut; die DDoS-Schicht bewertet das Traffic-Volumen. Alle drei Kontrollen können gemeinsam vor demselben Dienst operieren.
Optional-Modus ermöglicht API-Key-Fallback und schrittweise Partner-Migration
Im optional-Modus werden Partner, die ein Zertifikat präsentieren, mit mTLS-Identität verarbeitet, während Clients, deren Zertifikatsmigration noch nicht abgeschlossen ist, auf einen alternativen Authentifizierungsmechanismus ausweichen können. Dieses Muster ermöglicht es großen B2B-Migrationen, sicher auszurollen, ohne alle Partner am selben Tag auf mTLS zu zwingen. Das Backend kann basierend auf dem Vorhandensein des x-ssl-verify-Headers zwischen zertifikatsbasierten und API-Key-basierten Flows entscheiden. Sobald die Migration abgeschlossen ist, kann der Dienst in den required-Modus versetzt werden.
Detaillierte TLS- und Zertifikats-Logs stärken den Audit-Trail
Bei mTLS-Verbindungen können Felder wie Zertifikats-Subject, Aussteller, Gültigkeitsfenster, Verifikationsergebnis und Fingerabdruck protokolliert werden. In einem SIEM wird klar, welcher Partner mit welchem Zertifikat auf welchen Dienst zugegriffen hat. Ereignisse wie abgelaufene, selbstsignierte oder Aussteller-Fehler können separat analysiert werden. Diese Records erzeugen einen starken Audit-Trail für Compliance, Incident-Untersuchungen und Partner-Auditing.
Operative Tiefe
mTLS-Betrieb wird von Anfang bis Ende abgedeckt: Bind-Verhalten, Verify-Codes, headerbasierte Zertifikatserkennung, Fingerabdruck-Normalisierung, CA-Datei-Scoping und SNI/Host-Validierung.
Bind-Verifikationsverhalten
Verify none, optional oder required Verhalten wird am Service-Eintragspunkt gesetzt. Im required-Modus wird eine Client-Verbindung ohne Zertifikat abgelehnt. Im optional-Modus wird ein Zertifikat geparst, wenn es vorhanden ist; wenn es fehlt, kann die Anfrage zu einem alternativen Richtlinienflow fortgesetzt werden.
Verify-Codes
Das Zertifikats-Verifikationsergebnis kann als numerischer Fehlercode ausgedrückt werden. Null steht für erfolgreiche Verifizierung; andere Werte geben Bedingungen an wie Aussteller nicht gefunden, Zertifikat abgelaufen, Zertifikat noch nicht gültig oder selbstsigniertes Zertifikat. Dieser Wert kann als Header an das Backend weitergeleitet werden.
Zertifikatserkennung via Header
Wenn x-ssl-verify leer ist oder anzeigt, dass kein Zertifikat verwendet wurde, wird der Client so behandelt, als hätte er kein Zertifikat präsentiert. Ein Wert von 0 bedeutet, das Zertifikat wurde erfolgreich verifiziert. Jeder andere Wert bedeutet, Zertifikatsdaten können vorhanden sein, aber die Verifizierung ist fehlgeschlagen — dies kann in Logs und Richtlinienentscheidungen separat behandelt werden.
SHA1-Fingerabdruck-Normalisierung
Fingerabdruckwerte können mit gemischter Groß-/Kleinschreibung und Doppelpunkt-getrennter Formatierung ankommen. TR7 normalisiert den Wert, sodass Vergleichs- und Allowlist-Operationen konsistent funktionieren. Dasselbe Zertifikat wird nicht aufgrund eines Formatierungsunterschieds als eine andere Identität behandelt.
CA-Datei-Scoping
Jeder Dienst kann sein eigenes CA-Bundle verwenden, was es ermöglicht, Trust-Roots über Partner, Gerätegruppen und interne Dienste zu isolieren. CA-Änderungen sollten mit Blick auf den Service-Impact geplant und auditiert werden.
SNI- und Host-Validierung
Bei Diensten, die mTLS verwenden, kann SNI- und Host-Validierung zusätzlich zur Zertifikats-Verifizierung aktiviert werden. Wenn Zertifikat, SNI und Host gemeinsam ausgewertet werden, werden Anfrage-Identität, Ziel-Domain und HTTP-Routing-Intent alle in Kombination validiert. Dieses Modell hilft, das Risiko von Domain-Fronting-ähnlichem Missbrauch zu reduzieren.
Wann zu verwenden
Zertifikatsbasierte Identität für B2B-API-Partner
Jeder Partner verbindet sich mit einem einzigartigen Client-Zertifikat mit der API. TR7 protokolliert CN- und SHA1-Fingerabdruckwerte, leitet sie an das Backend weiter und macht per-Partner-Audit- und Rate-Limit-Entscheidungen unkomplizierter.
IoT-Geräte-Onboarding und Telemetrie-Verifizierung
Jedes Gerät kann sich mit einem einzigartigen, im Werk geladenen Zertifikat mit TR7 verbinden. Die Seriennummer des Geräts wird im CN-Feld übertragen, und Fingerabdruck-Allowlisting macht Widerrufs- und Zugriffsbeschränkungs-Flows schneller verwaltbar.
Provider-Identitätsverifizierung beim Gesundheitsdaten-Sharing
Gesundheitsorganisationen können mTLS beim Teilen von Daten mit Provider-Systemen verwenden, um auf Verbindungsebene zu authentifizieren. Wenn ein Zertifikat abläuft oder die Verifizierung fehlschlägt, kann der Zugang automatisch ohne manuelle Eingriffe unterbrochen werden.
Verwaltungsschnittstellen-Zugang mit mTLS und MFA
Systemadministratoren können sich mit einem Client-Zertifikat mit der TR7-Verwaltungsschnittstelle verbinden. In Kombination mit MFA und Gerätestatus durch AAM werden ein einzelner Laptop, ein bestimmtes Zertifikat und eine verifizierte Administratoridentität alle zusammen bestätigt.
Häufig gestellte Fragen
Was ist der Unterschied zwischen den mTLS-Verify-Modi?
Wie werden Zertifikatsinformationen an das Backend weitergeleitet?
Wann sollte die CA-Fehlerstrategie verwendet werden?
Kann TR7 sein eigenes Zertifikat beim Verbinden mit dem Backend präsentieren?
Können mTLS, WAAP und DDoS-Schutz zusammenarbeiten?
Wie kombinieren sich AAM Conditional-Access-Richtlinien mit mTLS?
mTLS zu Ihrer Service-Identitätsschicht hinzufügen
Das Client-Zertifikat am Edge verifizieren, an das Backend weiterleiten und mit AAM-Richtlinie kombinieren. Lassen Sie uns ein Live-Setup auf Ihren eigenen Diensten durchgehen.