Backend-authentifiziertes TLS und backend-mTLS

Vorschau

Diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie besehen“ verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

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.

Bei TLS mit Backend-Authentifizierung oder Backend-Authentifizierung kann der Load Balancer die Identität der Backends prüfen, mit denen er eine Verbindung herstellt. Mit mTLS für das Backend kann der Load Balancer seine Identität gegenüber Backends zusätzlich mit einem Client-TLS-Zertifikat bestätigen.

Das folgende Diagramm zeigt den Unterschied zwischen Frontend- und Backend-mTLS. Dabei wird jeweils die Rolle des Load Balancers hervorgehoben. Bei mTLS im Frontend fungiert der Load Balancer als Server und überprüft die Identität des Clients. Bei der Backend-mTLS-Authentifizierung fungiert der Load Balancer als Client und bestätigt seine Identität gegenüber dem Backend.

Frontend- und Backend-mTLS (zum Vergrößern anklicken)

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

In diesem Dokument finden Sie einen Überblick über das backendgeauthentifizierte TLS und das backendgestützte mTLS. Weitere Informationen zu mTLS für das Frontend finden Sie unter Übersicht über gegenseitiges TLS.

Backend-authentifiziertes TLS und Backend-mTLS können auf der 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 (CA). Mit backend-authentifiziertem TLS und backend-mTLS erhalten Application Load Balancer die folgenden Funktionen:

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

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

• Sie können zusätzlich zu Ihren Vertrauensankern Zwischenzertifikate konfigurieren, um den Pfad zur Validierung des Back-End-Zertifikats 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 an das Backend gesendet wird. 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 SAN-Felder übereinstimmt, die für den Backend-Dienst konfiguriert sind.

• Sie können den Back-End-Dienst Ihres Load Balancers für die Verwendung von mTLS konfigurieren, damit der Load Balancer seine Identität gegenüber den Back-Ends nachweisen kann. Diese Authentifizierung erfolgt mit einem Clientzertifikat (Load Balancer-Zertifikat), das der Load Balancer dem Backend vorlegt.

Zertifikatsanforderungen

Achten Sie beim Konfigurieren von Zertifikaten für backend-authentifiziertes TLS und backend-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. Hash-Algorithmen müssen SHA-256 oder eine stärkere kryptografische Hash-Funktion verwenden. Hash-Algorithmen wie MD4, MD5 und SHA-1 werden nicht unterstützt.

• Für vom Backend bereitgestellte Endserverzertifikate gelten die folgenden Anforderungen:

  • Die Erweiterung Grundlegende Einschränkungen darf CA=true nicht enthalten.
  • Die Erweiterung Erweiterte Schlüsselverwendung muss serverAuth enthalten.
  • Die Erweiterung Erweiterte Schlüsselverwendung darf nicht die Felder codeSigning, timeStamping oder OCSPSigning enthalten.
  • Das Zertifikat darf nicht abgelaufen sein.

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

  • Die Erweiterung Grundlegende Einschränkungen darf CA=true nicht 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.

• Für Root- und Zwischenzertifikate, die mit backend-authentifiziertem TLS verwendet werden, gelten die folgenden Anforderungen:

  • Die Erweiterung Grundlegende Einschränkungen muss CA=true enthalten.
  • Die Erweiterung Schlüsselverwendung muss auf keyCertSign gesetzt sein.
  • Die Erweiterung Erweiterte Schlüsselverwendung muss das Feld serverAuth enthalten.
  • Das Zertifikat darf nicht abgelaufen sein.

Hauptkomponenten von backend-authentifiziertem TLS und backend-mTLS

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

So konfigurieren Sie die backendgestützte TLS-Authentifizierung:

• Erstellen Sie eine TrustConfig-Ressource.
• Erstellen Sie eine Backend Authentication Config-Ressource.
• Aktualisieren Sie das TLS-Einstellungsattribut für den Backend-Dienst und verweisen Sie darauf.

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

Das folgende Diagramm zeigt die verschiedenen Komponenten, die mit dem Backend-Dienst eines Application Load Balancers verbunden sind und die backendgeauthentifiziertes TLS und backend-mTLS ermöglichen.

Backend-authentifizierte TLS- und mTLS-Komponenten (zum Vergrößern klicken)

In den folgenden Informationen finden Sie einen Überblick über die verschiedenen Komponenten, die zum Konfigurieren von backend-authentifiziertem TLS und backend-mTLS verwendet werden.

Vertrauenskonfiguration

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

Ein Trust Store umschließt 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 Trust Anchor 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 Zwischenzertifizierungsstellen, die im untergeordneten Zertifikat enthalten sind, verwendet, um während des Validierungsprozesses die Vertrauenskette aufzubauen. Das Erstellen eines Zwischenzertifikats ist optional.

Wenn Sie ein selbst signiertes, abgelaufenes Zertifikat verwenden müssen, das nicht mit einer bestimmten Vertrauensbasis verknüpft ist oder bei der Validierung fehlgeschlagen ist, können Sie ein solches Zertifikat in der Vertrauenskonfiguration einer Zulassungsliste 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 zur Überprüfung einer Vertrauenskette erforderlich sind.

Ressource „Konfiguration der Backend-Authentifizierung“

Die Ressource „Backend Authentication Config“ (BackendAuthenticationConfig), die dem Back-End-Dienst des Load Balancers zugeordnet ist, ermöglicht Folgendes:

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

Wenn Sie backendauthentifiziertes TLS und backend-mTLS aktivieren möchten, muss die Ressource „Backend Authentication Config“ auf die folgenden Ressourcen verweisen:

• 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 neben den Zertifikaten, die in der Vertrauenskonfiguration als vertrauenswürdig eingestuft sind, auch Backend-Serverzertifikate von öffentlichen Zertifizierungsstellen vertraut. Weitere Informationen finden Sie unter Öffentliche Stammzertifizierungsstellen verwenden.

• Clientzertifikat (clientCertificate): Das Clientzertifikat, mit dem der Load Balancer seine Identität gegenüber dem Backend ausdrückt, wenn für die Verbindung zum Backend mTLS verwendet wird. Bei der vom Back-End authentifizierten TLS-Authentifizierung (Back-End-Authentifizierung) kann dieses Feld leer sein. In diesem Fall authentifiziert der Load Balancer nur das Back-End, aber nicht sich selbst, beim Back-End.

Backend-Dienst

Innerhalb des Back-End-Dienstes verweist das Attribut tlsSettings auf die folgenden Ressourcen, um das Back-End-Zertifikat zu validieren.

• Konfiguration der Backend-Authentifizierung (authenticationConfig)
• SNI-Hostname (sni)
• Zulässige SANs (subjectAltNames)

Hinweis: Die Konfiguration des SNI-Hostnamens und der akzeptierten SANs im Backend-Dienst zur Überprüfung des Backend-Zertifikats ist optional. Sie können das Backend-Zertifikat jedoch nicht validieren, ohne die Ressource „Backend Authentication Config“ (Backend-Authentifizierungskonfiguration) im Backend-Dienst zu konfigurieren. Das bedeutet, dass das Backend-Zertifikat über eine vertrauenswürdige Zertifikatskette validiert werden muss, was durch eine Vertrauenskonfiguration ausgedrückt wird.

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 die backend-authentifizierte TLS-Verbindung konfiguriert ist.

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

• Sendet den SNI-Hostnamen während des TLS-Handshakes an den Backend-Server.
• Es wird geprü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 Backends einen SAN enthält, der mit dem SNI-Hostnamen übereinstimmt. Wenn jedoch SANs auf dem Backend-Dienst (tlsSettings.subjectAltNames) konfiguriert sind, führt der Load Balancer Folgendes aus:

• Der SNI-Hostname wird bei der SAN-Bestätigung 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 zur Back-End-authentifizierten TLS-Authentifizierung (Back-End-Authentifizierung) können Sie den Back-End-Dienst eines Load Balancers so konfigurieren, dass er mTLS verwendet, damit der Load Balancer seine Identität gegenüber dem Back-End nachweisen kann. Bei dieser Authentifizierung wird ein Clientzertifikat (Load Balancer) verwendet, das der Load Balancer dem Backend vorlegt.

So konfigurieren Sie mTLS für das Backend:

• Erstellen Sie eine Clientzertifikatressource, die das Zertifikat des Clients (Load Balancer) und seinen privaten Schlüssel enthält.
• Hängen Sie das Clientzertifikat an die Ressource „Backend Authentication Config“ an.

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

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

Backend-authentifiziertes TLS und Backend-mTLS auf dem Load Balancer konfigurieren

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

Private PKI verwenden

Im Folgenden finden Sie eine allgemeine Übersicht über die wichtigsten Schritte, die Sie ausführen müssen, um backendauthentifiziertes TLS und backend-mTLS auf Ihrem Load Balancer mit Zertifikaten zu konfigurieren, die von Ihrer privaten PKI ausgestellt wurden. Private PKIs haben den Vorteil, dass sie vollständig unter Ihrer Kontrolle stehen und von den PKI-Systemen des öffentlichen Internets isoliert sind.

1. Erstellen Sie eine Trust-Config-Ressource mit dem Trust-Anchor (Root-Zertifikat) und Zwischenzertifikaten, die als Stammzertifikate dienen.

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

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

4. Hängen Sie die Ressource „Backend Authentication Config“ an den Backend-Dienst des Load Balancers an.

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

• Backend-authentifiziertes TLS einrichten

• mTLS für das Backend einrichten

Öffentliche Root of Trusts verwenden

Sie können nicht nur Zertifikate aus Ihrer privaten PKI verwenden, um die backendauthentifizierte TLS-Verbindung zu aktivieren, sondern auch öffentliche Stammzertifikate, um das Backendzertifikat zu validieren.

Wenn Sie öffentliche Stammzertifikate 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 Ressource „Backend Authentication Config“ festlegen. Sie können jedoch auch eine Vertrauenskonfiguration erstellen, die neben den von der Vertrauenskonfiguration als vertrauenswürdig eingestuften Zertifikaten auch die Stammzertifikate Ihrer öffentlich ausgestellten Zertifikate enthält.

Für die Einstellung PUBLIC_ROOTS wird eine Reihe von Root-Zertifizierungsstellen verwendet, die denen der von Browsern als vertrauenswürdig eingestuften Zertifizierungsstellen ähnelt. Diese werden von Google verwaltet und können sich im Laufe der Zeit ändern. Das Risiko besteht, dass Ihre Backend-Zertifikate ungültig werden, wenn sich diese Wurzeln ändern. Wenn Sie öffentlich ausgestellte Zertifikate validieren müssen, sollten Sie eine etablierte und vertrauenswürdige Zertifizierungsstelle auswählen, die für die Ausstellung Ihrer Backend-Zertifikate die Zwischen-Quersignatur verwendet, um das Risiko zu verringern, dass ein Stammzertifikat abläuft oder widerrufen wird.

Schritte zur Validierung von Serverzertifikaten

Bei der Validierung des Serverzertifikats bei der TLS-Authentifizierung durch das Backend oder der Backend-Authentifizierung führt der Load Balancer folgende Schritte aus:

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

   Der Server beweist den Besitz des privaten Schlüssels, der mit dem Zertifikat verknüpft ist, das er dem Load Balancer vorlegt, indem er eine Information mit seinem privaten Schlüssel signiert und sie als Teil der CertificateVerify-Nachricht an den Load Balancer sendet. Der Load Balancer prüft dann diese Signatur mit dem öffentlichen Schlüssel aus dem Zertifikat des Servers. Wenn die Signaturprüfung fehlschlägt, bedeutet das, dass der Backend-Server nicht über den privaten Schlüssel verfügt, der dem Zertifikat entspricht. In solchen Fällen beendet der Load Balancer den TLS-Handshake, ohne Fehler zu protokollieren.

2. Überprüfen Sie die Vertrauenskette.

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

   • Das Serverzertifikat des Backends, Zwischenzertifikate (falls vorhanden) und das konfigurierte Root-Zertifikat erfüllen die Anforderungen an Zertifikate.
   • Bei allen Zertifikaten in der Vertrauenskette stimmt das Feld „Subject“ im übergeordneten Zertifikat mit dem Feld „Aussteller“ im untergeordneten Zertifikat überein. So wird sichergestellt, dass die Identität (Subjekt) des übergeordneten Zertifikats mit der Identität übereinstimmt, die im untergeordneten Zertifikat als Aussteller aufgeführt ist.
   • Bei allen Zertifikaten 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 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.
   Hinweis: Selbst signierte Clientzertifikate bilden keine gültige Vertrauenskette und werden immer abgelehnt.

3. Stellen Sie eine Verbindung zum Backend her.

   Wenn die Zertifikatsüberprüfung erfolgreich ist, fährt der Load Balancer mit der Verbindung zum Backend fort.

   Wenn die Zertifikatsüberprüfung jedoch fehlschlägt, beendet der Load Balancer die Verbindung zum Backend, sendet einen HTTP-Statuscode 502 an den Client und protokolliert den Grund für die Beendigung in Cloud Logging. Bei einem Zertifikatsüberprüfungsfehler veranlassen nachfolgende eingehende Anfragen den Load Balancer, die Back-End-Verbindung neu zu starten.

   Die Backend-Verbindung kann auch fehlschlagen, wenn der Backend-Server die Verbindung ablehnt. Bei Backend-mTLS kann das passieren, wenn das Clientzertifikat ungültig ist. Wenn die Verbindung zum Backend fehlschlägt, antwortet der Load Balancer auf Proxyanfragen mit einem HTTP-502-Statuscode und protokolliert einen allgemeinen Fehlergrund in Cloud Logging.

Beschränkungen

• TLS mit Backend-Authentifizierung und mTLS mit Backend können nur für globale externe Application Load Balancer konfiguriert werden. Klassische Application Load Balancer unterstützen keine vom Backend authentifizierte TLS- und mTLS-Verschlüsselung.

• Backend-authentifizierte TLS- und mTLS-Verbindungen werden für die folgenden Backendtypen nicht unterstützt:

  • Globale Internet-NEG-Back-Ends

  • App Engine-Back-Ends

• Wenn Sie mTLS für das Backend aktivieren möchten, müssen Sie auch TLS mit Backend-Authentifizierung konfigurieren.

• Wenn Sie mTLS für das Backend aktivieren möchten, müssen Sie das Clientzertifikat erstellen, bevor Sie die Ressource „Backend Authentication Config“ konfigurieren.

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

• Der Load Balancer gibt den SNI-Hostnamen des Clients nicht von der Frontend-TLS-Verbindung an, wenn eine Verbindung zu einem Back-End hergestellt wird. Back-Ends können jedoch über einen benutzerdefinierten Anfrageheader auf den SNI-Hostnamen des Clients zugreifen.

• Bei Back-End-mTLS sind die Clientzertifikatschlüssel auf Folgendes beschränkt:

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

• Die Back-End-authentifizierte TLS-Verbindung unterstützt keine Zertifikatentzugsüberprüfungen.

Kontingente und Limits

• Ein einzelner Trust Store kann bis zu 200 Trust-Anchor und Zwischenzertifikate enthalten, wobei für Zwischenzertifikate ein separates Limit von 100 vorgesehen ist. Dieselben Informationen zum Subjekt und zum öffentlichen Schlüssel des Subjekts dürfen nicht in mehr als drei Zwischenzertifikaten enthalten sein.

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

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

• Stammzertifikate, 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

• Backend-authentifiziertes TLS mit selbstverwalteten Zertifikaten einrichten