Backend-authentifiziertes TLS und backend-mTLS

Wenn ein Load-Balancer eine Verbindung zu Back-Ends innerhalb von Google Cloudherstellt, akzeptiert der Load-Balancer jedes Zertifikat, das von Ihren Back-Ends vorhanden ist. In solchen Fällen führt der Load-Balancer keine Zertifikatsprüfung durch.

Mit backend-authentifiziertem TLS oder der Backend-Authentifizierung kann der Load-Balancer die Identität der Back-Ends überprüfen, mit denen er eine Verbindung herstellt. Mit Backend-mTLS kann der Load-Balancer seine Identität gegenüber Backends zusätzlich mit einem Client-TLS-Zertifikat nachweisen.

Das folgende Diagramm zeigt den Unterschied zwischen Frontend- und Backend-mTLS und konzentriert sich auf die Rolle des Load-Balancers in den einzelnen Fällen. Bei Frontend-mTLS fungiert der Load Balancer als Server und überprüft die Identität des Clients. Bei Backend-mTLS fungiert der Load Balancer als Client und weist dem Backend seine Identität nach.

Frontend- und Backend-mTLS.
mTLS für Frontend und Backend (zum Vergrößern klicken).

mTLS funktioniert unabhängig im Frontend und im Backend. Sie können mTLS entweder für das Frontend, das Backend oder sowohl für das Frontend als auch für das Backend konfigurieren.

Dieses Dokument bietet einen Überblick über das Backend-authentifizierte TLS und das Backend-mTLS. Weitere Informationen zu Frontend-mTLS finden Sie unter Übersicht über gegenseitiges TLS.

Backend-authentifiziertes TLS und Backend-mTLS können für die Backend-Dienstressource globaler externer Application Load Balancer konfiguriert werden.

Features

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. Durch die TLS-Authentifizierung des Back-Ends und das gegenseitige TLS des Back-Ends werden Application Load Balancern die folgenden Funktionen hinzugefügt:

  • Der Load-Balancer kann von Back-Ends präsentierte Zertifikate anhand Ihrer eigenen Vertrauensanker validieren. Sie können mehrere Vertrauensanker hochladen, um eine nahtlose Migration von einer früheren PKI zu einer neuen PKI ohne Ausfallzeiten zu ermöglichen.

  • Der Load Balancer kann TLS-Zertifikate von Backends anhand öffentlicher Vertrauensanker (Web-PKI) validieren.

  • Sie können zusätzlich zu Ihren Vertrauensankern Zwischenzertifikate konfigurieren, um den Validierungspfad für Back-End-Zertifikate zu erstellen. Durch die Verwendung von Zwischenzertifikaten müssen Ihre Backend-Server nicht die vollständige Zertifikatskette bereitstellen.

  • Sie können einen TLS-SNI-Hostnamen (Server Name Indication) für Ihren Backend-Dienst konfigurieren. Während des TLS-Handshake fügt der Load-Balancer diesen SNI-Hostnamen in die ClientHello-Nachricht ein, die er an das Backend sendet. Das Backend antwortet dann mit seinem TLS-Zertifikat und der Load Balancer prüft, ob mindestens eines der SAN-Felder (Subject Alternative Name) dieses Zertifikats mit dem Hostnamen oder einem der für den Backend-Dienst konfigurierten SAN-Felder übereinstimmt.

  • Sie können den Back-End-Dienst Ihres Load-Balancers so konfigurieren, dass er mTLS verwendet, damit der Load-Balancer seine Identität gegenüber den Back-Ends nachweisen kann. Die Authentifizierung erfolgt mit einem Clientzertifikat (Load-Balancer-Zertifikat), das der Load-Balancer dem Backend präsentiert.

Zertifikatsanforderungen

Achten Sie beim Konfigurieren von Zertifikaten für die Backend-Authentifizierung mit TLS und Backend-mTLS darauf, dass sie die folgenden Anforderungen erfüllen:

  • Moderne Kryptografietools bilden die Grundlage der mTLS-Authentifizierung. Zertifikate müssen entweder RSA- oder ECDSA-Algorithmen für den Schlüsselaustausch verwenden. Für Hashing-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.

  • Von Back-Ends bereitgestellte Leaf-Serverzertifikate müssen die folgenden Anforderungen erfüllen:

  • Für untergeordnete Clientzertifikate (Load Balancer), die in Backend-mTLS verwendet werden, muss das Zertifikat eine Certificate Manager-Zertifikatsressource sein. Der Bereich dieses Zertifikats muss client-auth sein. Das bedeutet, dass dieses Zertifikat als Clientzertifikat im Backend-mTLS verwendet wird.

  • Für Root- und Zwischenzertifikate, die mit dem Backend-authentifizierten TLS verwendet werden, gelten die folgenden Anforderungen:

Wichtige Komponenten von Backend-authentifiziertem TLS und Backend-mTLS

Mit Backend-authentifiziertes TLS kann der Load-Balancer die Identität der Back-Ends überprüfen, mit denen er eine Verbindung herstellt. Sie können die TLS-Authentifizierung des Back-Ends für einen HTTP(S)-Load-Balancer konfigurieren, der entweder HTTPS oder HTTP/2 als Back-End-Dienstprotokoll verwendet. Wenn Sie kein backend-authentifiziertes TLS konfigurieren, akzeptiert der Load-Balancer jedes Zertifikat vom Backend. Mit Backend-mTLS können Sie den Load-Balancer zusätzlich so konfigurieren, dass er dem Backend sein eigenes Clientzertifikat präsentiert, mit dem das Backend den Load-Balancer authentifizieren kann.

So konfigurieren Sie die TLS-Authentifizierung für das Backend:

  • Erstellen Sie eine TrustConfig-Ressource.
  • Erstellen Sie eine Backend Authentication Config-Ressource.
  • Aktualisieren Sie das Attribut für die TLS-Einstellung für den Backend-Dienst und verweisen Sie darauf auf die Ressource „Konfiguration der Backend-Authentifizierung“.

Wenn Sie Backend-mTLS konfigurieren möchten, müssen Sie ein Clientzertifikat erstellen und es an die Ressource „Konfiguration der Backend-Authentifizierung“ anhängen. Sie können das Clientzertifikat nicht anhängen, nachdem die Backend Authentication Config-Ressource erstellt wurde.

Das folgende Diagramm zeigt die verschiedenen Komponenten, die an den Backend-Dienst eines Application Load Balancers angehängt sind und die Backend-authentifizierte TLS- und Backend-mTLS-Funktionen ermöglichen.

Komponenten für Backend-authentifiziertes TLS und Backend-mTLS.
Komponenten für Backend-authentifiziertes TLS und Backend-mTLS (zum Vergrößern klicken)

Im Folgenden finden Sie einen Überblick über die verschiedenen Komponenten, die zum Konfigurieren von Backend-authentifiziertem TLS und Backend-mTLS verwendet werden.

Konfiguration der Vertrauensstellung

Um die Serverzertifikate zu authentifizieren, die Ihr Backend dem Load-Balancer präsentiert, muss der Load-Balancer mit X.509-Zertifikaten konfiguriert werden, die eine Vertrauenskette zum Aussteller des Zertifikats des Backends herstellen. Sie konfigurieren die Vertrauenskonfiguration mit einer TrustConfig-Ressource, die die gesamte Vertrauenskonfiguration enthält und einen einzelnen Trust Store umfasst.

Ein Trust Store enthält einen Trust-Anchor (Root-Zertifikat) und optional ein oder mehrere Zwischenzertifikate. Ein Trust-Anchor ist ein Zertifikat, das einen Root of Trust darstellt. Ein gültiges Serverzertifikat muss eine Vertrauenskette zu einem Vertrauensanker im Trust Store aufweisen.

Ein Zwischenzertifikat ist ein Zertifikat, das Teil einer Vertrauenskette ist, die zu einem Trust-Anchor im Trust Store zurückführt. Es wird zusammen mit allen zusätzlichen Zwischen-CAs, die im Endzertifikat enthalten sind, verwendet, um die Vertrauenskette während des Validierungsprozesses zu erstellen. Das Erstellen eines Zwischenzertifikats ist optional.

Wenn Sie ein Zertifikat verwenden müssen, das selbstsigniert ist, abgelaufen ist, nicht mit einem angegebenen Root of Trust verkettet ist oder die Validierung fehlgeschlagen ist, können Sie ein solches Zertifikat einer Zulassungsliste in der Trust-Konfiguration hinzufügen. Das Erstellen eines selbstsignierten Zertifikats, das einer Zulassungsliste hinzugefügt werden kann, ist ebenfalls optional.

Der Trust Store enthält keine privaten Schlüssel, da nur die Zertifikate zum Überprüfen einer Vertrauenskette erforderlich sind.

Ressource „Konfiguration der Backend-Authentifizierung“

Die Ressource „Konfiguration der Backend-Authentifizierung“ (BackendAuthenticationConfig), die an den Backend-Dienst des Load-Balancers angehängt ist, ermöglicht Folgendes:

  • Backend-authentifiziertes TLS (mit der Vertrauenskonfiguration und öffentlichen Vertrauens-Roots)
  • Backend-mTLS (mit dem Clientzertifikat)

Zum Aktivieren von backend-authentifiziertem TLS und Backend-mTLS verweist die Ressource „Konfiguration der Backend-Authentifizierung“ auf die folgenden Ressourcen:

  • Vertrauenskonfiguration (trustConfig): Die angehängte Vertrauenskonfiguration, die zum Validieren des vom Backend bereitgestellten Serverzertifikats verwendet wird.

  • Öffentliche Vertrauensanker (wellKnownRoots): Gibt an, ob der Load Balancer Backend-Serverzertifikaten vertraut, die von öffentlichen Zertifizierungsstellen ausgestellt wurden, zusätzlich zu Zertifikaten, denen durch die Vertrauenskonfiguration vertraut wird. Weitere Informationen finden Sie unter Öffentliche Vertrauensanker verwenden.

  • Clientzertifikat (clientCertificate): Das Clientzertifikat, das der Load Balancer verwendet, um seine Identität gegenüber dem Backend zu bestätigen, wenn für die Verbindung zum Backend mTLS verwendet wird. Bei backend-authentifiziertem TLS (Backend-Authentifizierung) kann dieses Feld leer sein. In diesem Fall authentifiziert der Load Balancer nur das Backend, aber nicht sich selbst beim Backend.

Backend-Dienst

Im Back-End-Dienst verweist das Attribut tlsSettings auf die folgenden Ressourcen, um das Back-End-Zertifikat zu validieren.

  • Konfiguration der Backend-Authentifizierung (authenticationConfig)
  • SNI-Hostname (sni)
  • Akzeptierte SANs (subjectAltNames)

Die Felder „SNI“ (sni) und „SAN“ (subjectAltNames) im Attribut tlsSettings steuern, wie der Load Balancer das Zertifikat des Backends anhand der SAN-Werte des Zertifikats validiert. Diese Felder wirken sich auf den Validierungsprozess aus, unabhängig davon, ob backend-authentifiziertes TLS konfiguriert ist.

Wenn das SNI-Feld festgelegt ist (tlsSettings.sni), führt der Load-Balancer die folgenden Schritte aus:

  • Sendet den SNI-Hostname während des TLS-Handshakes an den Backend-Server.
  • Prüft, ob das TLS-Zertifikat des Backends einen SAN enthält, der mit dem SNI-Hostnamen übereinstimmt.

Standardmäßig prüft der Load-Balancer, ob das TLS-Zertifikat des Back-Ends einen SAN enthält, der mit dem SNI-Hostnamen übereinstimmt. Wenn jedoch SANs für den Backend-Dienst (tlsSettings.subjectAltNames) konfiguriert sind, führt der Load-Balancer Folgendes aus:

  • Der SNI-Hostname wird bei der SAN-Überprüfung ignoriert.
  • Prüft, ob das TLS-Zertifikat des Backends einen SAN enthält, der mit einem der akzeptierten SANs (subjectAltNames) übereinstimmt, die für den Backend-Dienst konfiguriert sind.

Clientzertifikat

Zusätzlich zu TLS mit Backend-Authentifizierung (Backend-Authentifizierung) können Sie den Backend-Dienst eines Load-Balancers so konfigurieren, dass er mTLS verwendet. So kann der Load-Balancer seine Identität gegenüber dem Backend nachweisen. Für diese Authentifizierung wird ein Clientzertifikat (Load Balancer) verwendet, das der Load Balancer dem Backend präsentiert.

So konfigurieren Sie das Backend-mTLS:

  • Erstellen Sie eine Clientzertifikatsressource, die das Clientzertifikat (Load Balancer) und den zugehörigen privaten Schlüssel enthält.
  • Hängen Sie das Clientzertifikat an die Ressource „Konfiguration der Backend-Authentifizierung“ an.

Backend-mTLS ist auch mit von Compute Engine verwalteten Arbeitslastidentitäten kompatibel, wenn Sie verwaltete Zertifikate über Certificate Manager konfigurieren. Von öffentlichen PKIs verwaltete Zertifikate werden nicht unterstützt. Alle Clientzertifikate müssen den Bereich client-auth haben und den Zertifikatanforderungen entsprechen.

Wenn das Backend ein Clientzertifikat anfordert, muss es so konfiguriert sein, dass es das Clientzertifikat akzeptiert. Wenn das Back-End die Verbindung des Load Balancers ablehnt, gibt der Load Balancer für die weitergeleiteten Anfragen den HTTP-Statuscode 502 zurück und protokolliert einen generischen Status in Cloud Logging.

Backend-authentifiziertes TLS und Backend-mTLS für den Load Balancer konfigurieren

Sie können backend-authentifiziertes TLS und Backend-mTLS auf dem Load-Balancer entweder mit einer privaten PKI oder mit öffentlichen Vertrauensanker konfigurieren.

Private PKI verwenden

Im Folgenden finden Sie eine allgemeine Übersicht über die wichtigsten Schritte, die Sie ausführen müssen, um authentifiziertes TLS und mTLS für das Backend auf Ihrem Load Balancer mit Zertifikaten zu konfigurieren, die von Ihrer privaten PKI ausgestellt wurden. Eine private PKI hat den Vorteil, dass sie vollständig unter Ihrer Kontrolle steht und von den PKI-Systemen des öffentlichen Internets isoliert ist.

  1. Erstellen Sie eine TrustConfig-Ressource, die den Vertrauensanker (Root-Zertifikat) und Zwischenzertifikate enthält, die als Vertrauensanker dienen.

  2. Wenn Sie Backend-mTLS konfigurieren möchten, erstellen Sie ein Clientzertifikat, das das Clientzertifikat (Load Balancer) und den zugehörigen privaten Schlüssel enthält.

  3. Erstellen Sie eine Ressource für die Konfiguration der Backend-Authentifizierung, die auf die Vertrauenskonfiguration verweist. Wenn Sie Backend-mTLS konfigurieren möchten, verweist die Ressource „Konfiguration der Backend-Authentifizierung“ sowohl auf die Vertrauenskonfiguration als auch auf das Clientzertifikat.

  4. Hängen Sie die Ressource „Konfiguration der Backend-Authentifizierung“ an den Backend-Dienst des Load-Balancers an.

Weitere Informationen zu dieser Einrichtung finden Sie in den folgenden Leitfäden:

Öffentliche Roots of Trust verwenden

Zusätzlich zur Verwendung von Zertifikaten, die von Ihrer privaten PKI ausgestellt wurden, um die TLS-Authentifizierung des Back-Ends zu aktivieren, können Sie auch öffentliche Vertrauensanker verwenden, um das Back-End-Zertifikat zu validieren.

Wenn Sie öffentliche Vertrauensanker verwenden möchten, müssen Sie keine Vertrauenskonfiguration erstellen und an die Ressource „Backend Authentication Config“ anhängen. Stattdessen müssen Sie PUBLIC_ROOTS als Wert im Feld wellKnownRoots der Backend Authentication Config-Ressource festlegen. Sie können aber auch eine Vertrauenskonfiguration erstellen, die zusätzlich zu den von der Vertrauenskonfiguration als vertrauenswürdig eingestuften Zertifikaten explizit die Roots Ihrer öffentlich ausgestellten Zertifikate enthält.

Für die Einstellung PUBLIC_ROOTS wird eine Reihe von Root-Zertifizierungsstellen verwendet, die von Google verwaltet werden und sich im Laufe der Zeit ändern können. Sie ähneln den Root-Zertifizierungsstellen, die von Browsern als vertrauenswürdig eingestuft werden. Dadurch besteht das Risiko, dass Ihre Backend-Zertifikate ungültig werden, wenn sich diese Stammzertifikate ändern. Wenn Sie öffentlich ausgestellte Zertifikate validieren müssen, sollten Sie eine etablierte und vertrauenswürdige Zertifizierungsstelle auswählen, die Zwischenzertifikate verwendet, um Ihre Backend-Zertifikate auszustellen. So wird das Risiko verringert, dass ein Stammzertifikat abläuft oder widerrufen wird.

Schritte zur Validierung des Serverzertifikats

Bei der Validierung des Serverzertifikats während des backend-authentifizierten TLS oder der Backend-Authentifizierung führt der Load Balancer die folgenden Schritte aus:

  1. Prüfen, ob der Server den privaten Schlüssel des Zertifikats besitzt:

    Der Server weist nach, dass er den privaten Schlüssel besitzt, der dem Zertifikat zugeordnet ist, das er dem Load Balancer präsentiert. Dazu signiert er einen Teil der Informationen mit seinem privaten Schlüssel und sendet ihn als Teil der CertificateVerify-Nachricht an den Load Balancer. Der Load Balancer überprüft diese Signatur dann mit dem öffentlichen Schlüssel aus dem Zertifikat des Servers. Wenn die Signaturprüfung fehlschlägt, bedeutet das, dass der Backend-Server nicht den privaten Schlüssel besitzt, der dem Zertifikat entspricht. In solchen Fällen beendet der Load Balancer den TLS-Handshake, ohne Fehler zu protokollieren.

  2. Vertrauenskette prüfen

    Wenn die Vertrauenskonfiguration mindestens einen Trust-Anchor enthält oder das Attribut wellKnownRoots auf PUBLIC_ROOTS gesetzt ist, versucht der Load Balancer, eine Vertrauenskette zwischen dem Serverzertifikat und dem konfigurierten Trust-Anchor zu prüfen. Die Überprüfung umfasst Folgendes:

    • Das Serverzertifikat des Backends, die Zwischenzertifikate (falls angegeben) und das konfigurierte Root-Zertifikat entsprechen den Zertifikatsanforderungen.
    • Für alle Zertifikate in der Vertrauenskette stimmt das Feld „Subject“ (Betreff) im übergeordneten Zertifikat mit dem Feld „Issuer“ (Aussteller) im untergeordneten Zertifikat überein. Diese Überprüfung trägt dazu bei, dass die Identität (Antragsteller) des übergeordneten Zertifikats mit der Identität übereinstimmt, die im untergeordneten Zertifikat als Aussteller aufgeführt ist.
    • Für alle Zertifikate in der Vertrauenskette stimmt die Subject Key Identifier (SKID) des übergeordneten Zertifikats mit der Authority Key Identifier (AKID) im untergeordneten Zertifikat überein. Diese Übereinstimmung bestätigt, dass das untergeordnete Zertifikat von der richtigen Stammzertifizierungsstelle ausgestellt wurde und dass es vertrauenswürdig ist, da der öffentliche Schlüssel des Stamms in der AKID referenziert wird, um die Gültigkeit des Zertifikats zu überprüfen.

  3. Verbindung zum Backend herstellen

    Wenn die Zertifikatsprüfung erfolgreich ist, stellt der Load-Balancer die Verbindung zum Backend her.

    Wenn die Zertifikatsvalidierung jedoch fehlschlägt, beendet der Load Balancer die Verbindung zum Backend, sendet den HTTP-Statuscode 502 an den Client und protokolliert den Grund für die Beendigung in Cloud Logging. Im Falle eines Zertifikatsvalidierungsfehlers veranlassen nachfolgende eingehende Anfragen den Load-Balancer, die Backend-Verbindung neu zu initiieren.

    Die Backend-Verbindung kann auch fehlschlagen, wenn der Backend-Server die Verbindung ablehnt. Bei Backend-mTLS kann dies passieren, weil das Clientzertifikat als ungültig erkannt wird. Wenn die Verbindung zum Backend fehlschlägt, antwortet der Load Balancer auf weitergeleitete Anfragen mit dem HTTP-Statuscode 502 und protokolliert einen allgemeinen Fehlergrund in Cloud Logging.

Fehlerbehandlung und Logging

Application Load Balancers bieten detaillierte Logging-Funktionen, mit denen Sie die Validierung von Serverzertifikaten ü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.

Wenn die Validierung des Serverzertifikats fehlschlägt, wird die Verbindung beendet und die Fehler werden in Cloud Logging protokolliert. Diese Fehler werden in der folgenden Tabelle beschrieben.

Status des Serverzertifikats Protokollierter Fehler
Die Serverzertifikatskette ist zu lang (mehr als 10 Zwischenzertifikate, die im Serverzertifikat enthalten sind). server_cert_chain_exceeded_limit

Ein Server- oder Zwischenzertifikat hat eine ungültige RSA-Schlüsselgröße.

Es wird keine Validierung durchgeführt.

RSA-Schlüssel können zwischen 2.048 und 4.096 Bit lang sein.

 server_cert_invalid_rsa_key_size

Ein Server- oder Zwischenzertifikat verwendet eine nicht unterstützte elliptische Kurve.

Es wird keine Validierung durchgeführt.

Gültige Kurven sind P-256 und P-384.

 server_cert_unsupported_elliptic_curve_key

Ein Server- oder Zwischenzertifikat verwendet einen Nicht-RSA- oder Nicht-ECDSA-Algorithmus.

Es wird keine Validierung durchgeführt.

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

 server_cert_pki_too_large

Ein Zwischenzertifikat zur Validierung hatte mehr als 10 Namenseinschränkungen.

server_cert_chain_max_name_constraints_exceeded

Das Serverzertifikat hat ein Erweiterungsfeld Extended Key Usage (EKU), das jedoch nicht serverAuth enthält.

server_cert_chain_invalid_eku
Das Zeitlimit wurde beim Prüfen der Zertifikatskette überschritten. server_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 Serverzertifikate. Die maximale Anzahl der Iterationen beträgt 100 (Zertifikate, die zur Validierung der Serverzertifikatskette geprüft werden).

 server_cert_validation_search_limit_exceeded

Sie haben mTLS konfiguriert, ohne eine TrustConfig-Ressource einzurichten.

 server_cert_validation_not_performed

Der Server hat das angeforderte Zertifikat während des Handshakes nicht bereitgestellt.

 server_cert_not_provided

Das Serverzertifikat schlägt für die Validierung der Ressource TrustConfig fehl.

 ssl_certificate_verification_failed

Der Dienst kann die Zertifikatskette nicht validieren.

 server_cert_validation_unavailable
Interner Fehler beim Validieren der Zertifikatskette. server_cert_validation_internal_error

Keine passenden TrustConfig gefunden.

 server_cert_trust_config_not_found
Die Nutzlast des Serverzertifikats (einschließlich Zwischenzertifikaten) ist zu groß (über 16 KB). server_cert_exceeded_size_limit

Beschränkungen

  • Backend-authentifiziertes TLS und Backend-mTLS können nur für globale externe Application Load Balancer konfiguriert werden. Klassische Application Load Balancer unterstützen kein TLS mit Backend-Authentifizierung und kein mTLS mit Backend-Authentifizierung.

  • Backend-authentifiziertes TLS und Backend-mTLS werden für die folgenden Backend-Typen nicht unterstützt:

    • Globale Internet-NEG-Back-Ends

    • App Engine-Back-Ends

  • Wenn Sie Backend-mTLS aktivieren möchten, müssen Sie auch Backend-authentifiziertes TLS konfigurieren.

  • Wenn Sie Backend-mTLS aktivieren möchten, müssen Sie das Clientzertifikat erstellen, bevor Sie die Ressource „Konfiguration der Backend-Authentifizierung“ konfigurieren.

  • Von Back-Ends verwendete Systemdiagnosen implementieren keine TLS-Authentifizierung oder mTLS-Funktionen. Sie müssen die Back-Ends mit Systemdiagnose-Endpunkten konfigurieren, die auf HTTP- oder HTTPS-Anfragen reagieren können.

  • Der Load-Balancer übergibt den SNI-Hostnamen des Clients nicht von der Frontend-TLS-Verbindung, wenn er eine Verbindung zu einem Backend herstellt. Back-Ends können jedoch über einen benutzerdefinierten Anfrageheader auf den SNI-Hostnamen des Clients zugreifen.

  • Bei Backend-mTLS sind die Schlüssel für Clientzertifikate auf Folgendes beschränkt:

    • RSA-Schlüssel können zwischen 2.048 und 4.096 Bit lang sein.
    • ECDSA-Schlüssel können die P-256- oder P-384-Kurven verwenden.

  • Backend-authentifiziertes TLS unterstützt keine Prüfungen des Zertifikatsperrstatus.

Kontingente und Limits

  • Ein einzelner Trust Store kann bis zu 200 Trust-Anker und Zwischenzertifikate enthalten, wobei für Zwischenzertifikate ein separates Limit von 100 gilt. Nicht mehr als drei Zwischenzertifikate dürfen dieselben Informationen zum Subjekt und zum öffentlichen Schlüssel des Subjekts haben.

  • Die maximale Tiefe einer Zertifikatskette beträgt 10 Zertifikate, einschließlich der Root- und Blattzertifikate. Die maximale Anzahl von Zwischenzertifikaten, die beim Aufbau der Vertrauenskette ausgewertet werden können, beträgt 100.

  • Bei der Backend-authentifizierten TLS-Verschlüsselung ist die vom Backend empfangene Zertifikatskette auf maximal 16 KB und 10 Zertifikate beschränkt.

  • Root-Zertifikate, die für die Validierung verwendet werden, dürfen nicht mehr als 10 Namenseinschränkungen enthalten.

  • Im Feld tlsSettings.subjectAltNames[] sind maximal fünf alternative Inhabernamen zulässig.

Nächste Schritte