Gegenseitiges TLS – Übersicht

Mutual TLS (mTLS) ist ein Branchenstandardprotokoll für die gegenseitige Authentifizierung zwischen einem Client und einem Server. Es sorgt dafür, dass sowohl der Client als auch der Server sich gegenseitig authentifizieren, indem überprüft wird, ob jeder ein gültiges Zertifikat besitzt, das von einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) ausgestellt wurde. Im Gegensatz zu Standard-TLS, bei dem nur der Server authentifiziert wird, erfordert mTLS, dass Client und Server Zertifikate präsentieren, um die Identitäten beider Parteien zu bestätigen, bevor eine Kommunikation hergestellt wird.

mTLS ist für die Ziel-HTTPS-Proxyressource aller Application Load Balancer konfiguriert:

• Globaler externer Application Load Balancer
• Klassischer Application Load Balancer
• Regionaler externer Application Load Balancer
• Regionaler interner Application Load Balancer
• Regionsübergreifender interner Application Load Balancer

Bei mTLS wird die Public-Key-Infrastruktur (PKI) verwendet, um die Identität der Entitäten zu authentifizieren, die über das Netzwerk kommunizieren. Die Infrastruktur umfasst drei Komponenten: einen Client, einen Server und eine Zertifizierungsstelle (Certificate Authority, CA). mTLS für Load Balancer unterstützt die folgenden Funktionen:

• Bestätigen, dass der Client, der das Zertifikat präsentiert, den zugehörigen privaten Schlüssel besitzt.

• Clientzertifikate in einem der beiden Modi validieren:

  • Ungültige Zertifikate ablehnen: Erzwingt eine strenge Authentifizierung, indem Anfragen abgelehnt werden, wenn die Clientzertifikatkette nicht validiert werden kann.

  • Ungültige oder fehlende Zertifikate zulassen: Bietet Flexibilität, da alle Anfragen an das Backend weitergeleitet werden, auch wenn ein Clientzertifikat fehlt oder ungültig ist.

• Clientzertifikate werden anhand eines hochgeladenen PKI-Ankers (Stammzertifikat) validiert. Es besteht die Möglichkeit, mehrere Anker separat hinzuzufügen, um eine nahtlose Migration von einer alten zu einer neuen PKI ohne Ausfallzeiten zu ermöglichen.

• Zusätzliche Zwischenzertifikate angeben, die zur Erstellung des Validierungspfads für Clientzertifikate für bestimmte PKI-Anker (Root-Zertifikate) verwendet werden sollen. Diese Zwischenzertifikate ermöglichen mTLS mit Clients, die nicht die vollständige Zertifikatskette bereitstellen.

• Einen Fingerabdruck des Zertifikats generieren und diesen als benutzerdefinierten Anfrageheader an das Backend übergeben.

• Ausgewählte Felder, die aus dem Zertifikat extrahiert wurden, mithilfe benutzerdefinierter Header an das Backend übergeben.

• Das Validierungsergebnis und alle Validierungsfehler mithilfe benutzerdefinierter Header an das Backend übergeben.

Zertifikatsanforderungen

Achten Sie beim Konfigurieren von Zertifikaten für mTLS darauf, dass sie die folgenden Anforderungen erfüllen:

• Moderne Kryptografietools bilden die Grundlage der mTLS-Authentifizierung. Zertifikate müssen entweder RSA- oder ECDSA-Algorithmen für den Schlüsselaustausch verwenden. Für Hashing-Algorithmen muss SHA-256 oder eine stärkere kryptografische Hash-Funktion verwendet werden. Hash-Algorithmen wie MD4, MD5 und SHA-1 werden nicht unterstützt.
• Für Clientzertifikate (Blattzertifikate):
  • Die Erweiterung Grundeinschränkungen darf nicht CA=true enthalten.
  • Die Erweiterung Erweiterte Schlüsselverwendung muss clientAuth enthalten.
  • Die Erweiterung Erweiterte Schlüsselverwendung darf nicht die Felder codeSigning, timeStamping oder OCSPSigning enthalten.
  • Das Zertifikat darf nicht abgelaufen sein.
  • Das Clientzertifikat darf kein selbst signiertes Zertifikat sein.
• Für Root- und Zwischenzertifikate:
  • Die Erweiterung Basic Constraints muss CA=true enthalten.
  • Die Erweiterung Schlüsselverwendung muss auf keyCertSign gesetzt sein.
  • Die Erweiterung Erweiterte Schlüsselverwendung sollte das Feld clientAuth enthalten.
  • Das Zertifikat darf nicht abgelaufen sein.

Architektur einer mTLS-Bereitstellung

Mit mTLS können Sie eine Vertrauenskonfigurationsressource konfigurieren, die einen Truststore enthält. Der Trust Store enthält einen Trust-Anchor (Root-Zertifikat) und optional ein oder mehrere Zwischenzertifikate. Wenn der Load Balancer ein Clientzertifikat empfängt, validiert er es, indem er eine Vertrauenskette vom Clientzertifikat zurück zum konfigurierten Vertrauensanker herstellt.

Im Folgenden finden Sie einen kurzen Überblick über die verschiedenen Ressourcen, die Sie konfigurieren müssen, um mTLS für den Load Balancer einzurichten:

• Konfiguration der Vertrauensstellung: Enthält eine einzelne Trust Store-Ressource, die wiederum einen Trust-Anchor (Root-Zertifikat) und optional ein oder mehrere Zwischenzertifikate enthält. Die Konfiguration der Vertrauensstellung wird verwendet, um eine Vertrauenskette zwischen dem Clientzertifikat und dem Vertrauensanker herzustellen. Weitere Informationen finden Sie unter Vertrauenskonfigurationen.

  Optional können Sie ein selbst signiertes, abgelaufenes oder anderweitig ungültiges Zertifikat oder ein Zertifikat, für das Sie keinen Zugriff auf die Root- und Zwischenzertifikate haben, der Trust-Konfiguration im Feld allowlistedCertificates hinzufügen. Sie benötigen keinen Trust Store, um ein Zertifikat einer Zulassungsliste hinzuzufügen.

  Wenn Sie ein Zertifikat auf die Zulassungsliste setzen, gilt es immer als gültig, solange es geparst werden kann, der Besitz des privaten Schlüssels nachgewiesen wird und die Einschränkungen für das SAN-Feld des Zertifikats erfüllt sind.

• Trust Store Enthält den Trust-Anker und die Zertifikate der Zwischenzertifizierungsstelle (Certificate Authority, CA), die zum Einrichten einer Vertrauenskette und zum Validieren des Clientzertifikats verwendet werden. Eine CA wird verwendet, um vertrauenswürdige Zertifikate für den Client auszustellen. Die CA wird durch den Trust-Anchor (Root-Zertifikat) des Load Balancers oder die Zwischen-CA-Zertifikate identifiziert.

  Sie können die folgenden Arten von Root- und Zwischenzertifikaten in den Trust Store hochladen:

  • Zertifikate, die von Drittanbieter-Zertifizierungsstellen Ihrer Wahl ausgestellt werden.
  • Zertifikate, die von privaten Zertifizierungsstellen ausgestellt werden, die Sie kontrollieren, wie unter Gegenseitiges TLS mit privater CA einrichten beschrieben.
  • Vom Nutzer bereitgestellte Zertifikate, wie unter Gegenseitiges TLS mit vom Nutzer bereitgestellten Zertifikaten einrichten beschrieben.

• Clientauthentifizierung (auch als ServerTLSPolicy bezeichnet): Gibt den Clientvalidierungsmodus und die Ressource für die Konfiguration der Vertrauensstellung an, die bei der Validierung von Clientzertifikaten verwendet werden soll. Wenn der Client dem Load Balancer ein ungültiges oder kein Zertifikat vorlegt, gibt der Clientvalidierungsmodus an, wie mit der Clientverbindung umgegangen wird. Sie können alle Parameter für die mTLS-Authentifizierung in den Server-TLS-Richtlinien angeben. Die Ressource „Client Authentication“ (ServerTLSPolicy) ist an die Ziel-HTTPS-Proxy-Ressource angehängt.

Die folgenden Diagramme zeigen die verschiedenen mTLS-Komponenten, die an die HTTPS-Zielproxyressource globaler und regionaler Application Load Balancer angehängt sind.

Clientvalidierungsmodus

Wenn der Client dem Load Balancer ein ungültiges oder kein Zertifikat vorlegt, gibt das Attribut clientValidationMode in der Ressource zur Clientauthentifizierung (ServerTLSPolicy) an, wie der Load Balancer die Clientverbindung verarbeitet.

Die Werte des Clientvalidierungsmodus sind:

• ALLOW_INVALID_OR_MISSING_CLIENT_CERT: Ermöglicht die Verbindung vom Client, auch wenn die Validierung des Clientzertifikats fehlgeschlagen ist oder kein Clientzertifikat vorgelegt wurde. In diesem Modus lässt der Load-Balancer die Verbindung vom Client zu und leitet alle Anfragen an das Backend weiter, unabhängig davon, ob eine Vertrauenskette hergestellt werden kann.

  Der Nachweis des Besitzes des privaten Schlüssels wird immer geprüft, wenn das Clientzertifikat vorgelegt wird. Wenn der Client den Besitz des privaten Schlüssels nicht nachweisen kann, wird der TLS-Handshake beendet, auch wenn der Clientvalidierungsmodus ungültige oder fehlende Clientzertifikate zulässt.

• REJECT_INVALID: Die Verbindung wird abgelehnt, wenn ein Client kein Zertifikat bereitstellt oder die Zertifikatsvalidierung fehlgeschlagen ist. In diesem Modus beendet der Load-Balancer die Verbindung vom Client, wenn er keine Vertrauenskette vom Clientzertifikat zurück zum Vertrauensanker herstellen kann.

mTLS auf dem Load Balancer konfigurieren

Im Folgenden finden Sie eine allgemeine Übersicht über die wichtigsten Schritte, die Sie ausführen müssen, um mTLS auf Ihrem Load-Balancer zu konfigurieren:

1. Erstellen Sie eine TrustConfig-Ressource, die den Vertrauensanker (Root-Zertifikat) und Zwischenzertifikate enthält, die als Vertrauensanker dienen.

2. Verknüpfen Sie die Konfiguration der Vertrauensstellung mit der Ressource zur Clientauthentifizierung (ServerTLSPolicy), die den Clientvalidierungsmodus von ALLOW_INVALID_OR_MISSING_CLIENT_CERT oder REJECT_INVALID definiert.

3. Hängen Sie die Ressource für die Clientauthentifizierung (ServerTLSPolicy) an die Ziel-HTTPS-Proxy-Ressource des Load Balancers an.

4. Optional: Sie können benutzerdefinierte mTLS-Header verwenden, um Informationen zur mTLS-Verbindung an einen Backend-Dienst oder eine URL-Zuordnung zu übergeben.

Weitere Informationen zu dieser Einrichtung finden Sie in den folgenden Leitfäden:

• Gegenseitiges TLS mit vom Nutzer bereitgestellten Zertifikaten einrichten
• Gegenseitiges TLS mit privater CA einrichten

Schritte zur Validierung von Clientzertifikaten

Bei der Validierung des Clientzertifikats führt der Load Balancer die folgenden Schritte aus:

1. Prüfen, ob der Client den privaten Schlüssel besitzt:

   Der Client weist nach, dass er den privaten Schlüssel besitzt, der dem öffentlichen Schlüssel im Zertifikat zugeordnet ist, indem er während des Handshake-Vorgangs eine Signatur generiert. Der Load Balancer überprüft diese Signatur mit dem öffentlichen Schlüssel des Clients. Wenn die Signaturprüfung fehlschlägt, bedeutet das, dass der Client nicht der Inhaber des Zertifikats ist. In diesem Fall wird der TLS-Handshake beendet, auch wenn Ihre Konfiguration ungültige oder fehlende Clientzertifikate zulässt. Für globale externe Application Load Balancer werden keine Fehler protokolliert. Für regionale externe Application Load Balancer und interne Application Load Balancer wird jedoch ein TLS-Fehler im Feld proxyStatus protokolliert.

2. Vertrauenskette prüfen

   Der Load Balancer prüft die Vertrauenskette zwischen dem Clientzertifikat und der konfigurierten Vertrauenskonfiguration. Die Überprüfung umfasst Folgendes:

   • Das Client-, Zwischen- und Stammzertifikat entsprechen den Zertifikatsanforderungen.
   • Das Feld „Subject“ (Betreff) im übergeordneten Zertifikat entspricht dem Feld „Issuer“ (Aussteller) im untergeordneten Zertifikat. Durch diese Überprüfung wird sichergestellt, dass die Identität (Betreff) des übergeordneten Zertifikats mit der Identität übereinstimmt, die im untergeordneten Zertifikat als Aussteller aufgeführt ist.
   • Die Subject Key Identifier (SKID) des übergeordneten Zertifikats entspricht der Authority Key Identifier (AKID) im untergeordneten Zertifikat. Diese Übereinstimmung bestätigt, dass das untergeordnete Zertifikat von der richtigen Stammzertifizierungsstelle ausgestellt wurde und dass es vertrauenswürdig ist, da der öffentliche Schlüssel des Stamms in der AKID referenziert wird, um die Gültigkeit des Zertifikats zu überprüfen.
   • Der alternative Antragstellername (Subject Alternative Name, SAN) eines untergeordneten Zertifikats verstößt nicht gegen das Feld NameConstraints im übergeordneten Zertifikat.

3. Leite die Anfrage an das Backend weiter.

   Wenn die Validierung des Clientzertifikats erfolgreich ist, wird die Anfrage mit benutzerdefinierten mTLS-Headern an das Backend weitergeleitet.

   Wenn die Validierung jedoch fehlschlägt, hängt die ergriffene Maßnahme vom Wert des Clientvalidierungsmodus ab:

   • ALLOW_INVALID_OR_MISSING_CLIENT_CERT: Die Anfrage wird mit benutzerdefinierten mTLS-Headern weitergeleitet, die den Grund für den Validierungsfehler angeben. Für regionenübergreifende interne Application Load Balancer, regionale externe Application Load Balancer und regionale interne Application Load Balancer können Sie zusätzlich zu benutzerdefinierten mTLS-Headern optionale mTLS-Felder konfigurieren, um den Grund für den Fehler zu prüfen.

   • REJECT_INVALID: Die Verbindung wird beendet und die Fehler werden in Cloud Logging protokolliert.

Benutzerdefinierte mTLS-Header, die an das Backend übergeben werden

In der folgenden Tabelle sind die benutzerdefinierten mTLS-Headervariablen aufgeführt, die an das Back-End übergeben werden können, sowohl wenn das Clientzertifikat die Validierung besteht als auch wenn nicht. Wenn die Validierung des Clientzertifikats fehlschlägt, werden Anfragen nur dann an das Backend weitergeleitet, wenn der Clientvalidierungsmodus auf ALLOW_INVALID_OR_MISSING_CLIENT_CERT festgelegt ist.

Diese Variablen können auch in der URL-Zuordnung festgelegt werden.

Status des Clientzertifikats	Clientvalidierungsmodus	Benutzerdefinierte Header
Die Clientzertifikatskette ist zu lang (mehr als 10 Zwischenzertifikate, die im Clientzertifikat enthalten sind).	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_chain_exceeded_limit client_cert_sha256_fingerprint: <cert hash>
Ein Client- oder Zwischenzertifikat hat eine ungültige RSA-Schlüsselgröße. Es wird keine Validierung durchgeführt. RSA-Schlüssel können zwischen 2.048 und 4.096 Bit lang sein.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_invalid_rsa_key_size client_cert_sha256_fingerprint: <cert hash>
Ein Client oder ein Zwischenzertifikat verwendet eine nicht unterstützte elliptische Kurve. Es wird keine Validierung durchgeführt. Gültige Elliptische-Kurven sind P-256 und P-384.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_unsupported_elliptic_curve_key client_cert_sha256_fingerprint: <cert hash>
Ein Client oder ein Zwischenzertifikat verwendet einen Nicht-RSA- und Nicht-ECDSA-Algorithmus. Es wird keine Validierung durchgeführt.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_unsupported_key_algorithm client_cert_sha256_fingerprint: <cert hash>
Die für die Validierung zu verwendende PKI hat mehr als zehn Zwischenzertifikate, die dieselben Subject- und Subject Public-Key-Informationen haben. Es wird keine Validierung durchgeführt.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_pki_too_large client_cert_sha256_fingerprint: <cert hash>
Ein Zwischenzertifikat zur Validierung hatte mehr als 10 Namenseinschränkungen..	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_chain_max_name_constraints_exceeded client_cert_sha256_fingerprint: <cert hash>
Das Clientzertifikat hat keine Extended Key Usage (EKU)-Erweiterung, die clientAuth enthält.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_chain_invalid_eku client_cert_sha256_fingerprint: <cert hash>
Das Zeitlimit wurde beim Prüfen der Zertifikatskette überschritten.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_validation_timed_out client_cert_sha256_fingerprint: <cert hash>
Das Limit für die Tiefe oder Iteration wurde beim Prüfen der Zertifikatskette erreicht. Die maximale Tiefe für eine Zertifikatskette beträgt zehn, einschließlich der Root- und Clientzertifikate. Die maximale Anzahl der Iterationen beträgt 100 (Zertifikate, die zur Validierung der Clientzertifikatskette geprüft werden).	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_validation_search_limit_exceeded client_cert_sha256_fingerprint: <cert hash>
Sie haben mTLS konfiguriert, ohne eine TrustConfig-Ressource einzurichten. Es kann keine Validierung durchgeführt werden, aber der Zertifikathash wird an das Back-End weitergeleitet.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_validation_not_performed client_cert_sha256_fingerprint: <cert hash>
Kein Clientzertifikat.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: false client_cert_chain_verified: false client_cert_error: client_cert_not_provided client_cert_sha256_fingerprint: <empty>
Das Clientzertifikat schlägt für die Validierung der Ressource TrustConfig fehl.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_validation_failed client_cert_sha256_fingerprint: <cert hash>
Das Clientzertifikat besteht die Validierung durch den Zertifikatsprüfer.	Nicht zutreffend	client_cert_present: true client_cert_chain_verified: true client_cert_error: <empty> client_cert_sha256_fingerprint: <cert hash> client_cert_serial_number: <serial_number> client_cert_valid_not_before: <date> client_cert_valid_not_after: <date> client_cert_uri_sans: <list> client_cert_dnsname_sans: <list> client_cert_issuer_dn: <issuer> client_cert_subject_dn: <subject> client_cert_leaf: <certificate> client_cert_chain: <list>

An das Backend übergebene benutzerdefinierte Header-Variablenwerte parsen

Einige Variablenwerte für benutzerdefinierte mTLS-Header sind Base64-codierte Stringdarstellungen von binären Distinguished Encoding Rules (DER)-Zertifikatsdaten. Sie können Base64-codierte Strings mit den Tools oder Softwarebibliotheken Ihrer Wahl decodieren. Hier einige Beispiele:

• Auf macOS- und Linux-Systemen kann das Befehlszeilentool base64 verwendet werden, das in beiden Betriebssystemen enthalten ist. Wenn Sie Base64-codierte Strings mit dem Dienstprogramm base64 decodieren möchten, übergeben Sie den codierten String als Standardeingabe an den Befehl base64 und verwenden Sie das Flag -d, um den String wie folgt zu decodieren:

  echo BASE_64_ENCODED_STRING | base64 -d
  

• Python enthält das base64-Modul, mit dem Base64-codierte Strings so decodiert werden können:

  import base64
  encoded_string=BASE_64_ENCODED_STRING
  decoded_string=base64.b64decode(encoded_string).decode()
  print(decoded_string) # Note that a newline character (\n) is added to the end of the string.
  

Fehlerbehandlung und Logging

Application Load Balancers bieten detaillierte Logging-Funktionen, mit denen Sie die Validierung von Clientzertifikaten überwachen, potenzielle Probleme identifizieren und Verbindungsprobleme beheben können. In diesem Abschnitt werden die verschiedenen Arten von Fehlern beschrieben, die bei der mTLS-Validierung auftreten können, und wie sie protokolliert werden.

In Logs protokollierte Fehler im REJECT_INVALID-Modus

Wenn die Clientzertifikatsprüfung fehlschlägt und der Clientvalidierungsmodus auf REJECT_INVALID gesetzt ist, wird die Verbindung beendet und die Fehler werden in Cloud Logging protokolliert. Diese Fehler werden in der folgenden Tabelle beschrieben.

Status des Clientzertifikats	Protokollierter Fehler
Die Clientzertifikatskette ist zu lang (mehr als 10 Zwischenzertifikate, die im Clientzertifikat enthalten sind).	client_cert_chain_exceeded_limit
Ein Client- oder Zwischenzertifikat hat eine ungültige RSA-Schlüsselgröße. Es wird keine Validierung durchgeführt. RSA-Schlüssel können zwischen 2.048 und 4.096 Bit lang sein.	client_cert_invalid_rsa_key_size
Ein Client oder ein Zwischenzertifikat verwendet eine nicht unterstützte elliptische Kurve. Es wird keine Validierung durchgeführt. Gültige Kurven sind P-256 und P-384.	client_cert_unsupported_elliptic_curve_key
Ein Client- oder Zwischenzertifikat verwendet einen Nicht-RSA- oder Nicht-ECDSA-Algorithmus. Es wird keine Validierung durchgeführt.	client_cert_unsupported_key_algorithm
Die für die Validierung zu verwendende PKI hat mehr als zehn Zwischenzertifikate, die dieselben Subject- und Subject Public-Key-Informationen haben. Es wird keine Validierung durchgeführt.	client_cert_pki_too_large
Ein Zwischenzertifikat zur Validierung hatte mehr als 10 Namenseinschränkungen.	client_cert_chain_max_name_constraints_exceeded
Das Clientzertifikat hat keine Extended Key Usage (EKU)-Erweiterung, die clientAuth enthält.	client_cert_chain_invalid_eku
Das Zeitlimit wurde beim Prüfen der Zertifikatskette überschritten.	client_cert_validation_timed_out
Das Limit für die Tiefe oder Iteration wurde beim Prüfen der Zertifikatskette erreicht. Die maximale Tiefe für eine Zertifikatskette beträgt zehn, einschließlich der Root- und Clientzertifikate. Die maximale Anzahl der Iterationen beträgt 100 (Zertifikate, die zur Validierung der Clientzertifikatskette geprüft werden).	client_cert_validation_search_limit_exceeded
Sie haben mTLS konfiguriert, ohne eine TrustConfig-Ressource einzurichten.	client_cert_validation_not_performed
Der Client hat das angeforderte Zertifikat während des Handshakes nicht bereitgestellt.	client_cert_not_provided
Das Clientzertifikat schlägt für die Validierung der Ressource TrustConfig fehl.	client_cert_validation_failed

In Logs protokollierte Fehler für geschlossenen Verbindungen

Wenn der Clientvalidierungsmodus auf ALLOW_INVALID_OR_MISSING_CLIENT_CERT oder REJECT_INVALID gesetzt ist, führen bestimmte Fehler zu geschlossenen Verbindungen und werden in Cloud Logging protokolliert. Diese Fehler werden in der folgenden Tabelle beschrieben.

Status des Clientzertifikats	Anfrage	Protokollierter Fehler
Das Clientzertifikat stimmt während des Handshakes mit der Signatur nicht überein.	SSL-Handshake beenden	–
Der Dienst kann die Zertifikatskette nicht validieren.	Verbindung beenden	client_cert_validation_unavailable
Interner Fehler beim Validieren der Zertifikatskette.	Verbindung beenden	client_cert_validation_internal_error
Keine passenden TrustConfig gefunden.	Verbindung beenden	client_cert_trust_config_not_found
Die Nutzlast des Clientzertifikats (einschließlich Zwischenzertifikaten) ist zu groß (über 16 KB).	Verbindung beenden	client_cert_exceeded_size_limit

Wenn das Logging für den Backend-Dienst aktiviert ist, können Sie protokollierte Fehler für geschlossene Verbindungen während der mTLS-Clientzertifikatsvalidierung ansehen.

Beschränkungen

• Der Load Balancer führt keine Sperrüberprüfungen für Clientzertifikate durch.

• Mit Application Load Balancers können Sie eine Vertrauenskonfiguration mit einem einzigen Trust Store hochladen, der höchstens 200 Trust-Anker und Zwischenzertifikate (die Anzahl der Zwischenzertifikate ist auf 100 begrenzt) und 500 Zertifikate enthält, die einer Zulassungsliste hinzugefügt werden. Alle Zwischenzertifikate dürfen nicht mehr als drei Zertifikate mit denselben Informationen zum öffentlichen Schlüssel des Subjekts haben. Weitere Informationen finden Sie unter Kontingente und Limits.

• Die maximale Tiefe für eine Zertifikatskette beträgt zehn, einschließlich der Root- und Clientzertifikate. Die maximale Häufigkeit, mit der Zwischenzertifikate beim Aufbau der Vertrauenskette ausgewertet werden können, beträgt 100. Weitere Informationen finden Sie unter Kontingente und Limits.

• Schlüssel der hochgeladenen und vom Kunden übergebenen Zertifikate sind auf Folgendes beschränkt:

  • RSA-Schlüssel können zwischen 2.048 und 4.096 Bit lang sein. Weitere Informationen finden Sie unter Kontingente und Limits.
  • ECDSA-Schlüssel können die P-256- oder P-384-Kurven verwenden.

• Die vom Client empfangene Zertifikatskette ist auf bis zu 16 KB und 10 Zertifikate beschränkt. Weitere Informationen finden Sie unter Kontingente und Limits.

• Root-Zertifikate, die für die Validierung verwendet werden, dürfen nicht mehr als 10 Namenseinschränkungen enthalten. Weitere Informationen finden Sie unter Kontingente und Limits.

• Die Google Front Ends (GFEs) der Schicht 1 erzwingen ein nicht konfigurierbares Zeitlimit von 10 Sekunden für die Präsentation des Clientzertifikats während des TLS-Handshakes. Bei Spitzenlast kann dieses Zeitlimit kürzer sein. Clients müssen die Zertifikatspräsentation innerhalb dieses Zeitrahmens abschließen, um eine mTLS-Verbindung erfolgreich herzustellen.

Nächste Schritte

• Gegenseitiges TLS mit vom Nutzer bereitgestellten Zertifikaten einrichten

• Gegenseitiges TLS mit privater CA einrichten

• Variablen, die im Headerwert vorkommen können