Gegenseitige TLS-Authentifizierung

Bei der HTTPS-Kommunikation funktioniert die Authentifizierung normalerweise nur in eine Richtung: der Client überprüft die Identität des Servers.

Verwenden Sie für Anwendungen, die den Load-Balancer zum Authentifizieren der Identität von Clients benötigen, die eine Verbindung zu ihm herstellen, gegenseitiges TLS (mTLS).

Bei mTLS fordert der Load-Balancer an, dass der Client während des TLS-Handshakes mit dem Load-Balancer ein Zertifikat sendet, um sich zu authentifizieren. Sie können einen Trust Store konfigurieren, mit dem der Load-Balancer die Vertrauenskette des Clientzertifikats validiert.

Die folgenden Application Load Balancer unterstützen mTLS:

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

Architektur

Die folgenden Ressourcen sind für Load Balancer erforderlich, um die Bereitstellung einer mTLS-Authentifizierung zu unterstützen:

Eine Clientauthentifizierungsressource (auch als ServerTLSPolicy bezeichnet). Hier können Sie den serverseitigen TLS-Modus und die TrustConfig-Ressource angeben, die bei der Validierung von Clientzertifikaten verwendet werden soll. Sie können alle Parameter für die mTLS-Authentifizierung in den Server-TLS-Richtlinien angeben. Server-TLS-Richtlinien können an die Ziel-HTTPS-Proxy-Ressource angehängt werden.
TrustConfig einer Ressource Eine Zertifikatmanager-Ressource. TrustConfig enthält eine einzelne Trust Store-Ressource, mit der Clientzertifikate validiert werden. Weitere Informationen finden Sie unter Vertrauenskonfigurationen verwalten.

Sie können Zertifikate, die einer Zulassungsliste hinzugefügt wurden, in den TrustConfig hochladen. Ein Zertifikat, das einer Zulassungsliste hinzugefügt wird, gilt immer als gültig, solange das Zertifikat geparst werden kann, ein Nachweis für den Besitz des privaten Schlüssels vorhanden ist und die Einschränkungen für das SAN-Feld des Zertifikats erfüllt sind. Abgelaufene Zertifikate gelten auch als gültig, wenn sie sich in einer Zulassungsliste befinden.
Ein Trust Store. Enthält die Zertifikate von Trust Anchor und Zwischenzertifikat der Zertifizierungsstelle (Certificate Authority, CA), die zur Validierung der Clientzertifikatskette verwendet werden. Eine CA wird verwendet, um vertrauenswürdige Zertifikate für den Client auszustellen. Die CA wird durch das vertrauenswürdige Root-Zertifikat des Load Balancers oder die Zwischen-CA-Zertifikate identifiziert.

Sie können die folgenden Arten von Clientzertifikaten in den Trust Store hochladen:
- Zertifikate, die von Drittanbieter-CAs Ihrer Wahl ausgestellt wurden.
- Zertifikate, die von privaten CAs in Ihrer Kontrolle ausgestellt wurden, wie unter Gegenseitiges TLS mit einer privaten CA einrichten beschrieben.
- Signierte Zertifikate, wie unter Gegenseitiges TLS mit vom Nutzer bereitgestellten Zertifikaten einrichten beschrieben.

Die folgende Abbildung zeigt mTLS-Komponenten:

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, bei dem es sich um einen internen Application Load Balancer handelt, der globale Komponenten verwendet.

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, bei dem es sich um einen externen Application Load Balancer handelt, der regionale Komponenten verwendet.

Weitere Informationen zu den Komponenten einer Bereitstellung von Application Load Balancer finden Sie in den folgenden Abschnitten:

Features

Mit den von mTLS für Load-Balancer unterstützten Features können Sie Folgendes tun:

Bestätigen, dass der private Schlüssel des vom Kunden bereitgestellten Zertifikats ausgestellt wurde.
Clientzertifikate in einem von zwei Modi verifizieren:
- Anfragen werden abgelehnt, wenn die Clientzertifikatskette nicht mit einem Trust Store validiert werden kann.
- Alle Anfragen an das Back-End übergeben, auch wenn sie kein Clientzertifikat bereitstellen.
Clientzertifikat für einen hochgeladenen PKI-Anker validieren Das Hinzufügen mehrerer PKI-Anker separat unterstützen, um eine Migration ohne Ausfallzeiten von einer alten PKI zu einer neuen zu erleichtern.
Zusätzliche Zwischenzertifikate angeben, die zur Erstellung des Validierungspfads für bestimmte PKI-Anker verwendet werden sollen. Mit den Zwischenzertifikaten können Sie mTLS mit Clients verwenden, die nicht die vollständige Zertifikatskette durchlaufen.
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 Anfrageheader an das Backend übergeben.
Das Validierungsergebnis und alle Validierungsfehler mithilfe benutzerdefinierter Anfrageheader an das Backend übergeben.

Eine ausführlichere Beschreibung der Validierung finden Sie weiter unten auf dieser Seite im Abschnitt Schritte zur Validierung des Clientzertifikats.

Validierungsmodi des MTLS-Clients

Wenn der Client dem Load-Balancer ein ungültiges oder kein Zertifikat präsentiert, gibt clientValidationMode an, wie die Clientverbindung verarbeitet wird.

Die clientValidationMode-Werte sind:

ALLOW_INVALID_OR_MISSING_CLIENT_CERT lässt die Verbindung vom Client zu, auch wenn die Validierung der Zertifikatskette des Clientzertifikats fehlgeschlagen ist oder kein Clientzertifikat angezeigt wurde. Der Nachweis über den Besitz des privaten Schlüssels wird immer bei Vorlage des Clientzertifikats geprüft.

Sie können in diesem Modus benutzerdefinierte Header-Variablen verwenden, um dem Backend anzuzeigen, ob der Client ein Zertifikat bereitgestellt hat, ob die Zertifikatsprüfung erfolgreich war und andere Informationen aus dem Zertifikat extrahiert wurden.
REJECT_INVALID lehnt die Verbindung ab, wenn ein Client kein Zertifikat bereitstellt oder die Zertifikatsprüfung fehlgeschlagen ist.

Sie können Logs für die Validierung des mTLS-Clientzertifikats aufrufen, wenn das Logging für den Backend-Dienst aktiviert ist.

Benutzerdefinierte Headerwerte, die an das Backend übergeben werden

In der folgenden Tabelle sind alle Werte der benutzerdefinierten gegenseitigen TLS-Header-Variablen aufgeführt, die immer an das Backend übergeben werden (Anfragetyp „Anfrage an Backend übergeben“). Benutzerdefinierte Header werden an das Backend übergeben, wenn clientValidationMode auf ALLOW_INVALID_OR_MISSING_CLIENT_CERT gesetzt ist oder das Clientzertifikat die Zertifikatsprüfung besteht.

Status des Clientzertifikats	clientValidationMode	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 ein 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 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 kein `Extended Key Usage (EKU)`, das `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 Zertifikat-Hash 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 Zertifizierungsprüfung zum Zertifikatsprüfung.	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>`

In Logs protokollierte Fehler für geschlossenen Verbindungen

Die folgenden Fehler führen zu einer geschlossenen Clientverbindung, wenn clientValidationMode auf ALLOW_INVALID_OR_MISSING_CLIENT_CERT oder REJECT_INVALID gesetzt ist. Weitere Informationen finden Sie unter Logging und Monitoring für regionale externe Application Load Balancer und Logging und Monitoring für interne Application Load Balancer. Diese Fehler werden in Cloud Logging protokolliert und in der folgenden Tabelle beschrieben.

Status des Clientzertifikats	Anfrage	In Logs 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 Überprüfen der Zertifikatskette.	Verbindung beenden	`client_cert_validation_internal_error`
Übereinstimmende `TrustConfig` wurden nicht 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`

In Logs protokollierte Fehler mit `REJECT_INVALID`-Validierung

Die folgenden Fehler führen zu einer geschlossenen Verbindung (Anfragetyp „Verbindung beenden”), wenn clientValidationMode auf REJECT_INVALID gesetzt ist. Weitere Informationen finden Sie unter Logging und Monitoring für regionale externe Application Load Balancer und Logging und Monitoring für interne Application Load Balancer. Diese Fehler werden in Cloud Logging protokolliert und in der folgenden Tabelle beschrieben.

Status des Clientzertifikats	In Logs protokollierter Fehler
Die Clientzertifikatskette ist zu lang (mehr als 10 Zwischenzertifikate, die im Clientzertifikat enthalten sind).	`client_cert_chain_exceeded_limit`
Ein Client oder ein 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 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 während des Handshakes das angeforderte Zertifikat nicht bereitgestellt.	`client_cert_not_provided`
Das Clientzertifikat schlägt mit der Ressource `TrustConfig` fehl.	`client_cert_validation_failed`

Schritte zur Validierung des Clientzertifikats

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

Der Load Balancer überprüft die Signatur des Clients, um nachzuweisen, dass der Client den privaten Schlüssel des Clientzertifikats hat. Wenn dieser Schritt fehlschlägt, schlägt der Load Balancer immer den TLS-Handshake fehl, auch wenn Ihre Konfiguration ungültige oder fehlende Clientzertifikate zulässt. Für globale externe Application Load Balancer werden keine Informationen protokolliert, für regionale externe Application Load Balancer und interne Application Load Balancer wird jedoch ein TLS-Fehler im Feld proxyStatus protokolliert.
Wenn die Konfiguration einen TrustAnchor enthält, prüft der Load Balancer eine Vertrauenskette zwischen dem Clientzertifikat und dem konfigurierten TrustAnchor. Der Load Balancer überprüft insbesondere Folgendes:
- Die Client-, Zwischen- und Root-Zertifikate entsprechen den Zertifikatsanforderungen.
- Das Feld "Betreff" in übergeordneten Zertifikaten stimmt mit dem Feld "Problem" in untergeordneten Zertifikaten überein.
- Die Subject Key Identifier (SKID) des übergeordneten Zertifikats entspricht der Authority Key Identifier (AKID) im untergeordneten Zertifikat.
- Der SAN eines untergeordneten Zertifikats verstößt nicht gegen das Feld NameConstraints im übergeordneten Zertifikat.
Wenn die Vertrauenskette erfolgreich überprüft wird, wird die Anfrage mit allen für den Endpunkt konfigurierten benutzerdefinierten mTLS-Headern an das Backend weitergeleitet.
Wenn die Überprüfung der Vertrauenskette fehlschlägt:
- Wenn ClientValidationMode auf REJECT_INVALID gesetzt ist, beendet der Load Balancer die Verbindung und protokolliert den Grund in Cloud Logging.
- Wenn ClientValidationMode auf ALLOW_INVALID_OR_MISSING_CLIENT_CERTIFICATE gesetzt ist, leitet der Load Balancer die Anfrage weiterhin an das Backend weiter. Sie können benutzerdefinierte Anfrageheader verwenden, um dem Backend anzuzeigen, dass die Validierung fehlgeschlagen ist, und um den Grund für den Fehler anzugeben. Für regionenübergreifende interne Application Load Balancer, regionale externe Application Load Balancer oder regionale interne Application Load Balancer können Sie zusätzlich zu benutzerdefinierten Anfrageheadern optionale Felder für mTLS konfigurieren. }, um den Grund für den Fehler zu überprüfen.

Zertifikatsanforderungen

Für Zertifikate müssen entweder RSA- oder ECDSA-Chiffren verwendet werden.
Für Clientzertifikate (untergeordnete Zertifikate):
- Die Erweiterung Grundlegende Einschrä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 Stamm- und Zwischenzertifikate:
- Die Erweiterung Grundlegende Einschränkungen 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.

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 100 Trust-Anchors und 100 Zwischenzertifikate 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 folgende Elemente beschränkt:
- RSA-Schlüssel können von 2.048 bis 4.096 Bit 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.
Selbst signierte Clientzertifikate werden vom Load Balancer immer als ungültig angesehen.