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 (Vorschau)
• Regionaler interner Application Load Balancer (Vorschau)
• Regionenübergreifender interner Application Load Balancer (Vorschau)

Architektur

Die folgenden Ressourcen sind erforderlich, damit Load-Balancer das Deployment einer mTLS-Authentifizierung unterstützen:

• Eine TLS-Serverressource (ServerTLSPolicy). Hiermit können Sie den serverseitigen TLS-Modus und die Ressource TrustConfig angeben, die bei der Validierung von Clientzertifikaten verwendet werden sollen. Server-TLS-Richtlinien unterstützen die mTLS-Authentifizierung. 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 auf der Zulassungsliste in das TrustConfig hochladen. Ein Zertifikat auf der Zulassungsliste gilt immer als gültig, solange das Zertifikat geparst werden kann, ein Nachweis für den Besitz eines privaten Schlüssels hergestellt wurde und die Einschränkungen für das SAN-Feld des Zertifikats erfüllt sind. Abgelaufene Zertifikate gelten auch als gültig, wenn sie auf die Zulassungsliste gesetzt werden.

• 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.

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

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

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

• Architektur (externe Application Load Balancer)
• Architektur und Ressourcen (interne Application Load Balancer)

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 HTTP-Fehlermeldungen für statusDetails. Diese Fehler werden in Cloud Logging protokolliert und in der folgenden Tabelle beschrieben.

Hinweis: Diese Fehler werden für regionenübergreifende interne Application Load Balancer, regionale externe Application Load Balancer oder regionale interne Application Load Balancer nicht protokolliert.

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 HTTP-Fehlermeldungen für statusDetails. Diese Fehler werden in Cloud Logging protokolliert und in der folgenden Tabelle beschrieben.

Hinweis: Diese Fehler werden für regionenübergreifende interne Application Load Balancer, regionale externe Application Load Balancer oder regionale interne Application Load Balancer nicht protokolliert.

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:

1. 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 und keine Informationen protokolliert werden.
2. 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.
3. Wenn die Vertrauenskette erfolgreich überprüft wird, wird die Anfrage mit allen für den Endpunkt konfigurierten benutzerdefinierten mTLS-Headern an das Backend weitergeleitet.
4. Wenn die Verifizierung 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 (Blatt):
  • 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.
  • Es darf nicht abgelaufen sein.
  • Das Clientzertifikat darf kein selbst signiertes Zertifikat sein.
• Für Root- 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.
  • Es 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-Anchor und 100 Zwischenzertifikate und 500 Zertifikate auf der Zulassungsliste enthält. 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.

Nächste Schritte

• Gegenseitiges TLS mit vom Nutzer bereitgestellten Zertifikaten einrichten

• Gegenseitiges TLS mit privater CA einrichten

• Variablen, die im Headerwert vorkommen können

• Gegenseitiges TLS für einen globalen externen Anwendungs-Load-Balancer einrichten

• Gegenseitiges TLS für einen klassischen Anwendungs-Load-Balancer einrichten

• Gegenseitiges TLS für einen internen Application Load Balancer einrichten

• Gegenseitiges TLS für regionalen externen Application Load Balancer einrichten