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 sich Client und Server gegenseitig authentifizieren, indem überprüft wird, ob beide ein gültiges Zertifikat haben, das von einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) ausgestellt wurde. Im Gegensatz zu Standard-TLS, bei dem nur der Server authentifiziert wird, müssen bei mTLS sowohl der Client als auch der Server Zertifikate vorlegen, um die Identität beider Parteien zu bestätigen, bevor die Kommunikation hergestellt wird.

mTLS ist auf der Ziel-HTTPS-Proxy-Ressource 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

mTLS verwendet die Public-Key-Infrastruktur (PKI), 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 Features:

• Prüfen, ob der Client, der das Zertifikat vorlegt, den privaten Schlüssel hat.

• Clientzertifikate mit einem der Clientvalidierungsmodi validieren.

• Clientzertifikate werden anhand eines hochgeladenen PKI-Ankers (Root-Zertifikat) validiert. Sie können mehrere Anker separat hinzufü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 die Verwendung von 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

Wenn Sie Zertifikate für mTLS konfigurieren, müssen sie die folgenden Anforderungen erfüllen:

• Moderne Kryptografietools bilden die Grundlage der mTLS-Authentifizierung. Zertifikate müssen für den Schlüsselaustausch entweder RSA- oder ECDSA-Algorithmen verwenden.

  Hinweis: Hash-Algorithmen müssen SHA-256 oder eine stärkere kryptografische Hash-Funktion verwenden. Hash-Algorithmen wie SHA-1 werden nur unterstützt, wenn der Client-Validierungsmodus ALLOW_VALIDATION_RELAXATIONS mit der Lockerung ALLOW_SHA1_HASHING konfiguriert ist. Dadurch können Clientzertifikatketten validiert werden, die mit Legacy-SHA-1-Message-Digests signiert sind. Hash-Algorithmen wie MD4 und MD5 werden nicht unterstützt.

• Für Clientzertifikate (untergeordnete Zertifikate):

  • Die Erweiterung Grundlegende Einschränkungen darf nicht CA=true enthalten.

  • Die Erweiterung Erweiterte Schlüsselverwendung muss clientAuth enthalten.

    Hinweis: Wenn Sie den Clientvalidierungsmodus ALLOW_VALIDATION_RELAXATIONS mit der Lockerung ALLOW_MISSING_EKU verwenden, überspringt der Load Balancer diese Anforderung. Wenn das Zertifikat jedoch eine EKU-Erweiterung hat, die einen anderen Zweck (z. B. serverAuth), aber nicht clientAuth auflistet, wird die Verbindung abgelehnt.

  • Die Erweiterung Erweiterte Schlüsselverwendung darf nicht die Felder codeSigning, timeStamping oder OCSPSigning enthalten.

  • Das Zertifikat darf nicht abgelaufen sein.

    Hinweis: Wenn Sie den Clientvalidierungsmodus ALLOW_VALIDATION_RELAXATIONS mit der Lockerung ALLOW_EXPIRED_LEAF_CERTIFICATE verwenden, überspringt der Load Balancer diese Anforderung.

  • Das Clientzertifikat darf kein selbst signiertes Zertifikat sein.

• Für Stamm- und Zwischenzertifikate:

  • Die Erweiterung Grundlegende Einschränkungen muss CA=true enthalten.

  • Die Erweiterung Schlüsselverwendung muss auf keyCertSign festgelegt 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 Trust Store 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 Trust-Anchor herstellt.

Im Folgenden finden Sie eine kurze Übersicht ü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 Trust-Anchor herzustellen. Weitere Informationen finden Sie unter Vertrauenskonfigurationen.

  Wenn Sie ein selbst signiertes, abgelaufenes oder anderweitig ungültiges Zertifikat verwenden müssen oder keinen Zugriff auf die Root- und Zwischenzertifikate haben, können Sie dieses Zertifikat optional der Vertrauenskonfiguration im Feld allowlistedCertificates hinzufügen. Sie benötigen keinen Trust Store, um ein Zertifikat einer Zulassungsliste hinzuzufügen.

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

• Trust Store. Enthält die Trust-Anchor- und Zwischenzertifizierungsstellen-Zertifikate, die zum Erstellen 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 des Load Balancers (Root-Zertifikat) 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 wurden.
  • Zertifikate, die von privaten Zertifizierungsstellen in Ihrer Kontrolle ausgestellt wurden, wie unter Gegenseitiges TLS mit einer privaten Zertifizierungsstelle 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 für die Clientauthentifizierung (ServerTLSPolicy) ist an die Ziel-HTTPS-Proxy-Ressource angehängt.

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

global

Das folgende Diagramm zeigt die Komponenten der Bereitstellung eines externen Application Load Balancers. Diese Architektur gilt auch für den regionenübergreifenden internen Application Load Balancer, der ein interner Application Load Balancer ist, der globale Komponenten verwendet.

Gegenseitiges TLS mit globalen externen Application Load Balancer-Komponenten (zum Vergrößern klicken).

regional

Das folgende Diagramm zeigt die Komponenten der Bereitstellung eines regionalen internen Application Load Balancers. Diese Architektur gilt auch für den regionalen externen Application Load Balancer, einen externen Application Load Balancer, der regionale Komponenten verwendet.

Gegenseitiges TLS mit Komponenten des regionalen internen Application Load Balancers (zum Vergrößern klicken)

Modi für Clientvalidierung

Das Attribut clientValidationMode der Ressource zur Clientauthentifizierung (ServerTLSPolicy) gibt an, wie der Load Balancer die Clientverbindung verarbeitet. Der Modus bestimmt, ob ungültige oder fehlende Clientzertifikate strikt abgelehnt werden (REJECT_INVALID), mit Ausnahme bestimmter gelockerter X.509-Prüfungen abgelehnt werden (ALLOW_VALIDATION_RELAXATIONS) oder an das Backend weitergeleitet werden (ALLOW_INVALID_OR_MISSING_CLIENT_CERT).

Die verschiedenen Clientvalidierungsmodi sind:

• Ungültige oder fehlende Clientzertifikate zulassen (ALLOW_INVALID_OR_MISSING_CLIENT_CERT)
• Ungültige Clientzertifikate ablehnen (REJECT_INVALID)
• Lockerungen der Validierung zulassen (ALLOW_VALIDATION_RELAXATIONS)

Ungültiges oder fehlendes Clientzertifikat zulassen

Im Modus ALLOW_INVALID_OR_MISSING_CLIENT_CERT wird die Verbindung vom Client auch dann zugelassen, wenn die Validierung des Clientzertifikats fehlschlägt oder der Client kein Zertifikat vorlegt. 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 oder nicht.

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 ein ungültiges oder fehlendes Clientzertifikat zulässt.

Ungültiges Clientzertifikat ablehnen

Im Modus REJECT_INVALID wird die Verbindung 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 zum Trust-Anchor herstellen kann.

Lockerungen der Validierung zulassen

Im Modus ALLOW_VALIDATION_RELAXATIONS wird die Validierung von Clientzertifikaten erzwungen, aber es sind Lockerungen bei bestimmten Validierungsprüfungen möglich, z. B. während einer Migration, wenn ältere Clientzertifikate nicht alle strengen Zertifikatsanforderungen erfüllen. Wenn Sie eine vorhandene ServerTLSPolicy-Ressource im Modus REJECT_INVALID haben, können Sie sie auf den Modus ALLOW_VALIDATION_RELAXATIONS aktualisieren und die Liste der Validierungslockerungen angeben, die Sie zulassen möchten.

Sie können im Feld clientValidationRelaxations einen oder mehrere der folgenden Werte angeben:

• ALLOW_MISSING_EKU: Ermöglicht es, die Erweiterung Extended Key Usage (EKU) im Clientzertifikat wegzulassen.

  ALLOW_MISSING_EKU lässt nur Zertifikate zu, die überhaupt keine EKU-Erweiterung haben. Eine vorhandene EKU-Erweiterung mit dem falschen Zweck wird nicht ignoriert. Wenn die EKU-Erweiterung im Clientzertifikat vorhanden ist, muss sie weiterhin den Schlüsselzweck clientAuth (OID 1.3.6.1.5.5.7.3.2) enthalten, wie in den Zertifikatsanforderungen angegeben. Wenn das Zertifikat eine EKU-Erweiterung hat, die einen anderen Zweck (z. B. serverAuth), aber nicht clientAuth auflistet, wird die Verbindung abgelehnt.

  Achtung: Das Aktivieren von ALLOW_MISSING_EKU ist riskant, wenn Sie eine Root-Zertifizierungsstelle verwenden, die Zertifikate für mehrere Zwecke ausstellt. Ohne EKU-Erzwingung kann ein Zertifikat, das für einen anderen Zweck als die Authentifizierung vorgesehen ist (z. B. S/MIME oder reine Serverauthentifizierung), für die mTLS-Clientauthentifizierung akzeptiert werden. Verwenden Sie diese Lockerung nur, wenn Sie eine dedizierte private Zertifizierungsstelle zum Ausstellen von Zertifikaten für die Clientauthentifizierung verwenden.

• ALLOW_SHA1_HASHING: Ermöglicht die Validierung von Clientzertifikatketten, die mit Legacy-SHA-1-Message-Digests signiert sind.

  Achtung: Das Zulassen von SHA-1-Nachrichten-Digests ist unsicher. Verwenden Sie diese Lockerung nur vorübergehend, um Legacy-Clients während der Migrationsphasen zu unterstützen.

• ALLOW_EXPIRED_LEAF_CERTIFICATE: Ermöglicht die Validierung eines abgelaufenen untergeordneten Clientzertifikats. Der Load Balancer validiert das abgelaufene untergeordnete Clientzertifikat so, als wäre die aktuelle Zeit eine Sekunde vor dem Ende des Gültigkeitszeitraums (notAfter minus eine Sekunde). Dadurch besteht das untergeordnete Clientzertifikat die Ablaufprüfung. Diese Lockerung gilt ausschließlich für das untergeordnete Clientzertifikat und nicht für Zwischen- oder Root-Zertifikate in der Kette. Noch nicht gültige untergeordnete Clientzertifikate (bei denen die aktuelle Zeit vor dem Zeitstempel notBefore liegt) werden weiterhin abgelehnt.

  Achtung: Das Zulassen abgelaufener untergeordneter Clientzertifikate ist unsicher. Verwenden Sie diese Lockerung nur vorübergehend, um Legacy-Clients während der Migrationsphasen zu unterstützen.

Der Modus ALLOW_VALIDATION_RELAXATIONS erfordert ein Clientzertifikat und validiert die Zertifikatskette anhand der konfigurierten TrustConfig-Ressource. Dabei werden die spezifischen Validierungslockerungen angewendet, die Sie im Feld clientValidationRelaxations angeben.

Wenn Sie ALLOW_VALIDATION_RELAXATIONS auswählen, müssen Sie mindestens eine Lockerung der Validierung angeben. Wenn Sie mehrere Lockerungen auswählen, werden alle ausgewählten Lockerungen gleichzeitig angewendet. Solange der Client ein Zertifikat bereitstellt, das nach Anwendung der ausgewählten Lockerungen gültig ist, akzeptiert der Load Balancer die Verbindung. Wenn Sie beispielsweise ALLOW_MISSING_EKU und ALLOW_SHA1_HASHING konfigurieren, akzeptiert der Load Balancer Verbindungen von Clients, die ansonsten gültige Zertifikate vorweisen, die die EKU-Erweiterung (Extended Key Usage) weglassen und SHA-1-Hashing verwenden.

Wenn ein Client kein Zertifikat bereitstellt oder die Zertifikatsvalidierung aus einem Grund fehlschlägt, der nicht durch die konfigurierten Lockerungen abgedeckt ist, beendet der Load Balancer die Verbindung und protokolliert den Fehler in Cloud Logging.

Google Cloud empfiehlt, Validierungslockerungen nur als vorübergehende Lösung während Zertifikatsmigrationen zu verwenden. Die Verwendung von ALLOW_VALIDATION_RELAXATIONS ist sicherer als die Verwendung von ALLOW_INVALID_OR_MISSING_CLIENT_CERT, da der Load Balancer weiterhin alle anderen Validierungsprüfungen erzwingt und keine benutzerdefinierte Validierungslogik auf Ihrem Backend erfordert.

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 Trust-Anchor (Root-Zertifikat) und Zwischenzertifikate enthält, die als Root of Trust dienen.

2. Verknüpfen Sie die Konfiguration der Vertrauensstellung mit der Ressource für die Clientauthentifizierung (ServerTLSPolicy), die den Clientvalidierungsmodus definiert.

3. Hängen Sie die Clientauthentifizierungsressource (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 des Clientzertifikats

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 den Besitz des privaten Schlüssels nach, der mit dem öffentlichen Schlüssel im Zertifikat verknüpft ist, indem er während des Handshake-Prozesses eine Signatur generiert. Der Load Balancer überprüft diese Signatur mit dem öffentlichen Schlüssel des Clients. Wenn die Signaturprüfung fehlschlägt, ist der Client nicht der Inhaber des Zertifikats. In diesem Fall wird der TLS-Handshake beendet, auch wenn Ihre Konfiguration ein ungültiges oder fehlendes Clientzertifikat 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 überprüft die Vertrauenskette, indem er das Clientzertifikat mit den in der Vertrauenskonfiguration konfigurierten Zertifikaten abgleicht. Der Clientvalidierungsmodus bestimmt, ob ungültige oder fehlende Clientzertifikate strikt abgelehnt werden (REJECT_INVALID), mit Ausnahme bestimmter gelockerter X.509-Prüfungen abgelehnt werden (ALLOW_VALIDATION_RELAXATIONS) oder an das Backend weitergeleitet werden (ALLOW_INVALID_OR_MISSING_CLIENT_CERT).

   Die Überprüfung umfasst auch Folgendes:

   • Die Client-, Zwischen- und Root-Zertifikate entsprechen den Zertifikatsanforderungen.
   • Das Feld „Subject“ im übergeordneten Zertifikat stimmt mit dem Feld „Issuer“ im untergeordneten Zertifikat überein. Durch diese Überprüfung wird sichergestellt, dass die Identität (Antragsteller) 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 Root-Zertifizierungsstelle ausgestellt wurde und dass es vertrauenswürdig ist, da der öffentliche Schlüssel der Root-Zertifizierungsstelle 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.
   Hinweis: Selbst signierte Clientzertifikate bilden keine gültige Vertrauenskette und werden immer abgelehnt.

3. Anfrage an das Backend weiterleiten

   Wenn die Clientzertifikatvalidierung 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 und ALLOW_VALIDATION_RELAXATIONS: 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 Backend übergeben werden können, wenn das Clientzertifikat die Validierung besteht und wenn sie fehlschlägt. 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 von 2.048 bis 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 Zertifikatshash wird an das Backend 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 Werte für benutzerdefinierte Headervariablen parsen

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

• Auf macOS- und Linux-Systemen kann das Befehlszeilentool base64 verwendet werden, das ein zentrales Dienstprogramm in beiden Betriebssystemen 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 so 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 Balancer bieten detaillierte Logging-Funktionen, mit denen Sie die Clientzertifikatsvalidierung ü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- und ALLOW_VALIDATION_RELAXATIONS-Modus

Wenn die Clientzertifikatsvalidierung fehlschlägt und der Clientvalidierungsmodus auf REJECT_INVALID oder ALLOW_VALIDATION_RELAXATIONS festgelegt 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 von 2.048 bis 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 Erweiterung Extended Key Usage (EKU), 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 konfiguriert 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
Kein passende 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 eine Abfrage ausführen, um Logs für die Validierung des mTLS-Clientzertifikats aufzurufen.

Beschränkungen

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

• Mit Application Load Balancern können Sie eine Vertrauenskonfiguration mit einem einzigen Trust Store hochladen, der höchstens Folgendes enthält: 200 Trust-Anchor und Zwischenzertifikate (die Anzahl der Zwischenzertifikate ist auf 100 begrenzt) und 500 Zertifikate, 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 von 2.048 bis 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 Layer-1-Google Front Ends (GFEs) erzwingen ein nicht konfigurierbares Zeitlimit von 10 Sekunden, damit der Client sein Zertifikat während des TLS-Handshakes vorlegen kann. Bei Spitzenlast kann dieses Zeitlimit kürzer sein. Clients müssen die Zertifikatspräsentation innerhalb dieses Zeitraums abschließen, um eine mTLS-Verbindung herstellen zu können.

Nächste Schritte

• Gegenseitiges TLS mit vom Nutzer bereitgestellten Zertifikaten einrichten

• Gegenseitiges TLS mit privater CA einrichten

• Variablen, die im Headerwert vorkommen können