Diese Seite wurde von der Cloud Translation API übersetzt.

Gegenseitiges TLS – Übersicht

Mutual TLS (mTLS) ist ein Industriestandardprotokoll für die gegenseitige Authentifizierung zwischen einem Client und einem Server. Sie sorgt dafür, dass sich sowohl Client als auch Server gegenseitig authentifizieren, indem sie überprüft, ob beide ein gültiges Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) haben. 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äten beider Seiten zu bestätigen, bevor eine Kommunikation hergestellt wird.

mTLS ist für die 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

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 (CA). mTLS für Load Balancer unterstützt die folgenden Funktionen:

Prüfen Sie, ob der Kunde, der das Zertifikat vorlegt, den zugehörigen privaten Schlüssel hat.
Clientzertifikate in einem von zwei Modi validieren:
- Ungültige Zertifikate ablehnen: Erzwingt eine strenge Authentifizierung, indem Anfragen abgelehnt werden, wenn die Clientzertifikatskette nicht validiert werden kann.
- Ungültige oder fehlende Zertifikate zulassen: Bietet Flexibilität, da alle Anfragen an das Backend übergeben werden, auch wenn ein Clientzertifikat fehlt oder ungültig ist.
Clientzertifikate anhand eines hochgeladenen PKI-Ankerzertifikats (Stammzertifikat) validieren. Es ist möglich, mehrere Anker separat hinzuzufügen, um eine nahtlose Migration von einer alten PKI zu einer neuen ohne Ausfallzeit zu ermöglichen.
Geben Sie zusätzliche Zwischenzertifikate an, um den Validierungspfad für Clientzertifikate anhand der angegebenen PKI-Anker (Root-Zertifikate) zu erstellen. Mit diesen Zwischenzertifikaten kann mTLS mit Clients verwendet werden, 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 für den Schlüsselaustausch entweder RSA- oder ECDSA-Algorithmen verwenden. Für Hash-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 (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.

Architektur einer mTLS-Bereitstellung

Mit mTLS können Sie eine Vertrauenskonfigurationsressource mit einem Truststore konfigurieren. Der Trust Store enthält einen Trust-Anchor (Root-Zertifikat) und optional ein oder mehrere Zwischenzertifikate. Wenn der Load Balancer ein Clientzertifikat erhält, validiert er es, indem er eine Vertrauenskette vom Clientzertifikat zum konfigurierten Trust Anchor 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:

Vertrauenskonfiguration Enthält eine einzelne Trust Store-Ressource, die wiederum einen Trust-Anchor (Root-Zertifikat) und optional ein oder mehrere Zwischenzertifikate enthält. Mit der Vertrauenskonfiguration wird eine Vertrauenskette zwischen dem Clientzertifikat und dem Trust Anchor hergestellt. Weitere Informationen finden Sie unter Vertrauenskonfigurationen.

Optional: Wenn Sie ein selbst signiertes, abgelaufenes oder anderweitig ungültiges Zertifikat verwenden müssen oder keinen Zugriff auf das Stamm- und Zwischenzertifikat haben, können Sie dieses Zertifikat der Vertrauenskonfiguration im Feld allowlistedCertificates hinzufügen. Sie benötigen keinen Truststore, um ein Zertifikat einer Zulassungsliste hinzuzufügen.

Wenn Sie ein Zertifikat zur Zulassungsliste hinzufügen, gilt es immer als gültig, solange es parsbar ist, der Besitz des privaten Schlüssels nachgewiesen wurde und die Einschränkungen für das SAN-Feld des Zertifikats erfüllt sind.
Trust Store Enthält das Trust Anchor-Zertifikat und die Zertifikate der Zertifizierungsstelle (Certificate Authority, CA), die zum Aufbau einer Vertrauenskette und zur Validierung des Clientzertifikats verwendet werden. Eine Zertifizierungsstelle wird verwendet, um vertrauenswürdige Zertifikate für den Client auszustellen. Die CA wird durch den Trust Anchor (Stammzertifikat) 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 Zertifizierungsstellen Ihrer Wahl ausgestellt wurden.
- Zertifikate, die von privaten Zertifizierungsstellen ausgestellt wurden, die Sie verwalten, 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 ServerTLSPolicy genannt): Gibt den Modus für die Clientüberprüfung und die Konfigurationsressource für die 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 Clientauthentifizierungsressource (ServerTLSPolicy) ist an die Ziel-HTTPS-Proxy-Ressource angehängt.

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

global

Das folgende Diagramm zeigt die Komponenten einer externen Application Load Balancer-Bereitstellung. Diese Architektur gilt auch für den regionenübergreifenden internen Application Load Balancer, einen internen Application Load Balancer, 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, einen externen Application Load Balancer, der regionale Komponenten verwendet.

Clientvalidierungsmodus

Wenn der Client dem Load Balancer ein ungültiges oder kein Zertifikat vorlegt, gibt das Attribut clientValidationMode der Ressource „Client Authentication“ (ServerTLSPolicy, Clientauthentifizierung) an, wie der Load Balancer mit der Clientverbindung umgeht.

Die Werte für den Clientvalidierungsmodus sind:

ALLOW_INVALID_OR_MISSING_CLIENT_CERT: Die Verbindung vom Client wird zugelassen, auch wenn die Validierung des Clientzertifikats fehlgeschlagen ist oder kein Clientzertifikat vorgelegt wurde. In diesem Modus erlaubt der Load Balancer die Verbindung vom Client und leitet alle Anfragen an das Backend weiter, unabhängig davon, ob eine Vertrauenskette hergestellt werden kann oder nicht.

Der Nachweis, dass der private Schlüssel ausgestellt wurde, wird immer geprüft, wenn das Clientzertifikat vorgelegt wird. Wenn der Client nicht nachweisen kann, dass er den privaten Schlüssel besitzt, 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 vorlegt oder die Zertifikatsüberprüfung fehlgeschlagen ist. In diesem Modus beendet der Load Balancer die Verbindung vom Client, wenn er keine Vertrauenskette vom Clientzertifikat zum Trust Anchor 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:

Erstellen Sie eine Trust-Config-Ressource mit dem Trust-Anchor (Root-Zertifikat) und Zwischenzertifikaten, die als Stammzertifikate dienen.
Verknüpfen Sie die Konfiguration der Vertrauensstellung mit der Ressource „Client Authentication“ (ServerTLSPolicy), die den Clientvalidierungsmodus entweder als ALLOW_INVALID_OR_MISSING_CLIENT_CERT oder REJECT_INVALID definiert.
Hängen Sie die Clientauthentifizierungsressource (ServerTLSPolicy) an die Ziel-HTTPS-Proxy-Ressource des Load Balancers an.
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:

Schritte zur Validierung von Clientzertifikaten

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

Prüfen, ob der Kunde den privaten Schlüssel hat

Der Client beweist, dass er den privaten Schlüssel besitzt, 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 ungültige oder fehlende Clientzertifikate zulässt. Für globale externe Application Load Balancer werden keine Fehler protokolliert. Bei regionalen externen Application Load Balancern und internen Application Load Balancern wird jedoch ein TLS-Fehler im Feld proxyStatus protokolliert.
Überprüfen Sie die Vertrauenskette.

Der Load Balancer prüft die Vertrauenskette zwischen dem Clientzertifikat und der konfigurierten Vertrauenskonfiguration. Die Überprüfung umfasst Folgendes:
- Die Client-, Zwischen- und Stammzertifikate erfüllen die Anforderungen an Zertifikate.
- Das Feld „Subject“ (Subjekt) im übergeordneten Zertifikat stimmt mit dem Feld „Aussteller“ (Issuer) im untergeordneten Zertifikat überein. Dadurch wird sichergestellt, dass die Identität (Subjekt) 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 vertrauenswürdig ist, da auf den öffentlichen Schlüssel der Stammzertifizierungsstelle in der AKID verwiesen 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.
Leiten Sie die Anfrage an das Backend weiter.

Wenn die Clientzertifikatsvalidierung 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 Modus für die clientseitige Validierung ab:
- ALLOW_INVALID_OR_MISSING_CLIENT_CERT: Die Anfrage wird mit benutzerdefinierten mTLS-Headern weitergeleitet, die den Grund für den Validierungsfehler angeben. Bei regionenübergreifenden internen Application Load Balancern, regionalen externen Application Load Balancern und regionalen internen Application Load Balancern können Sie zusätzlich zu benutzerdefinierten mTLS-Headern optionale mTLS-Felder konfigurieren, um den Grund für den Fehler zu ermitteln.
- 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-Header aufgeführt, die an das Backend übergeben werden, sowohl wenn das Clientzertifikat die Validierung besteht als auch wenn sie fehlschlägt. Wenn die Validierung des Clientzertifikats fehlschlägt, werden benutzerdefinierte Header nur an das Backend übergeben, wenn der Clientvalidierungsmodus auf ALLOW_INVALID_OR_MISSING_CLIENT_CERT festgelegt ist.

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 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 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>`
Beim Prüfen der Zertifikatskette wurde das Zeitlimit ü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 Zertifikats-Hash 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>`

Fehlerbehandlung und ‑protokollierung

Anwendungs-Load Balancer bieten detaillierte Logging-Funktionen, mit denen Sie die Clientzertifikatsvalidierung überwachen, potenzielle Probleme erkennen 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.

Im `REJECT_INVALID`-Modus protokollierte Fehler

Wenn die Clientzertifikatsvalidierung 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	Geloggter 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 `Extended Key Usage (EKU)`-Erweiterung, die `clientAuth` enthält.	`client_cert_chain_invalid_eku`
Beim Prüfen der Zertifikatskette wurde das Zeitlimit ü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 nicht das angeforderte Zertifikat bereitgestellt.	`client_cert_not_provided`
Die Validierung des Clientzertifikats mit der Ressource `TrustConfig` ist fehlgeschlagen.	`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	Geloggter Fehler
Das Clientzertifikat stimmt während des Handshakes mit der Signatur nicht überein.	SSL-Handshake beenden	–
Der Dienst kann die Zertifikatskettenüberprüfung nicht durchführen.	Verbindung beenden	`client_cert_validation_unavailable`
Interner Fehler bei der Validierung der Zertifikatskette.	Verbindung beenden	`client_cert_validation_internal_error`
Passende `TrustConfig` 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`

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

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 sowie 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.
Die 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 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.