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:

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.

Gegenseitiges TLS mit globalen externen Application Load Balancer-Komponenten.
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.

Gegenseitiges TLS mit regionalen internen Application Load Balancer-Komponenten.
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:

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:

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

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.

Nächste Schritte