Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Gegenseitige Authentifizierung mit TLS im Application Load Balancer
Die gegenseitige TLS-Authentifizierung ist eine Variante von Transport Layer Security (TLS). Herkömmliches TLS ermöglicht eine sichere Kommunikation zwischen einem Server und einem Client, wobei der Server seinen Clients seine Identität mitteilen muss. Bei Mutual TLS handelt ein Load Balancer bei der Aushandlung von TLS die gegenseitige Authentifizierung zwischen dem Client und dem Server aus. Wenn Sie Mutual TLS mit Ihrem Application Load Balancer verwenden, vereinfachen Sie das Authentifizierungsmanagement und reduzieren die Belastung Ihrer Anwendungen.
Durch die Verwendung von Mutual TLS kann Ihr Load Balancer die Client-Authentifizierung verwalten und so sicherstellen, dass nur vertrauenswürdige Clients mit Ihren Backend-Anwendungen kommunizieren. Wenn Sie diese Funktion verwenden, authentifiziert der Load Balancer Clients mithilfe von Zertifikaten von einer Zertifizierungsstelle (CA) eines Drittanbieters oder mithilfe der AWS Private Certificate Authority (PCA), optional, mit Sperrprüfungen. Der Load Balancer leitet die Client-Zertifikatsinformationen mithilfe von HTTP-Headern, die Ihre Anwendungen für die Autorisierung verwenden können, an das Backend weiter.
Mutual TLS for Application Load Balancers bietet die folgenden Optionen für die Validierung Ihrer X.509v3-Client-Zertifikate:
Gegenseitiger TLS-Passthrough: Der Load Balancer sendet die gesamte Client-Zertifikatskette an das Ziel, ohne sie zu überprüfen. Ziele sollten die Client-Zertifikatskette verifizieren. Anschließend können Sie mithilfe der Client-Zertifikatskette die Load Balancer-Authentifizierung und die Zielautorisierungslogik in Ihrer Anwendung implementieren.
Gegenseitige TLS-Überprüfung: Der Load Balancer führt die X.509-Client-Zertifikatsauthentifizierung für Clients durch, wenn ein Load Balancer TLS-Verbindungen aushandelt.
Um den gegenseitigen TLS-Passthrough zu verwenden, müssen Sie den Listener so konfigurieren, dass er die Zertifikate von Clients akzeptiert. Informationen zur Verwendung von Mutual TLS mit Überprüfung finden Sie unter. Konfiguration von Mutual TLS auf einem Application Load Balancer
Bevor Sie mit der Konfiguration von Mutual TLS auf Ihrem Application Load Balancer beginnen
Bevor Sie mit der Konfiguration von Mutual TLS auf Ihrem Application Load Balancer beginnen, sollten Sie Folgendes beachten:
- Kontingente
Application Load Balancers enthalten bestimmte Beschränkungen in Bezug auf die Anzahl der in Ihrem AWS Konto verwendeten Trust Stores, CA-Zertifikate und Zertifikatssperrlisten.
Weitere Informationen finden Sie unter Kontingente für Ihre Application Load Balancers.
- Anforderungen für Zertifikate
Application Load Balancers unterstützen Folgendes für Zertifikate, die mit gegenseitiger TLS-Authentifizierung verwendet werden:
Unterstütztes Zertifikat: X.509v3
Unterstützte öffentliche Schlüssel: RSA 2K — 8K oder ECDSA secp256r1, secp384r1, secp521r1
Unterstützte SHA256 Signaturalgorithmen:, 384, RSA/SHA256, 384, 512 with EC/SHA 512 mit 256.384.512 Hash mit RSASSA-PSS mit MGF1
- CA-Zertifikatspakete
Folgendes gilt für Zertifizierungsstellen-Pakete (CA):
Application Load Balancers laden jedes Zertifikatspaket der Zertifizierungsstelle (CA) als Batch hoch. Application Load Balancers unterstützen das Hochladen einzelner Zertifikate nicht. Wenn Sie neue Zertifikate hinzufügen müssen, müssen Sie die Zertifikatspaketdatei hochladen.
Verwenden Sie die ModifyTrustStoreAPI, um ein CA-Zertifikatspaket zu ersetzen.
- Reihenfolge der Zertifikate für Passthrough
Wenn Sie den gegenseitigen TLS-Passthrough verwenden, fügt der Application Load Balancer Header ein, um den Backend-Zielen die Zertifikatskette des Clients zu präsentieren. Die Reihenfolge der Präsentation beginnt mit den Leaf-Zertifikaten und endet mit dem Stammzertifikat.
- Wiederaufnahme der Sitzung
Die Sitzungswiederaufnahme wird nicht unterstützt, wenn der Modus Mutual TLS Passthrough oder Verify mit einem Application Load Balancer verwendet wird.
- HTTP-Header
Application Load Balancer verwenden
X-Amzn-MtlsHeader, um Zertifikatsinformationen zu senden, wenn es Clientverbindungen mit gegenseitigem TLS aushandelt. Weitere Informationen und Beispiel-Header finden Sie unter. HTTP-Header und gegenseitiges TLS- CA-Zertifikatsdateien
CA-Zertifikatsdateien müssen die folgenden Anforderungen erfüllen:
Die Zertifikatsdatei muss das PEM-Format (Privacy Enhanced Mail) verwenden.
Der Inhalt des Zertifikats muss innerhalb der
-----END CERTIFICATE-----Grenzen-----BEGIN CERTIFICATE-----und liegen.Den Kommentaren muss ein
#Zeichen vorangestellt werden und sie dürfen keine-Zeichen enthalten.Es dürfen keine Leerzeilen vorhanden sein.
Beispielzertifikat, das nicht akzeptiert wird (ungültig):
# comments Certificate: Data: Version: 3 (0x2) Serial Number: 01 Signature Algorithm: ecdsa-with-SHA384 Issuer: C=US, O=EXAMPLE, OU=EXAMPLE, CN=EXAMPLE Validity Not Before: Jan 11 23:57:57 2024 GMT Not After : Jan 10 00:57:57 2029 GMT Subject: C=US, O=EXAMPLE, OU=EXAMPLE, CN=EXAMPLE Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 00:01:02:03:04:05:06:07:08 ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment, Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Key Identifier: 00:01:02:03:04:05:06:07:08 X509v3 Subject Alternative Name: URI:EXAMPLE.COM Signature Algorithm: ecdsa-with-SHA384 00:01:02:03:04:05:06:07:08 -----BEGIN CERTIFICATE----- Base64–encoded certificate -----END CERTIFICATE-----Beispielzertifikate, die akzeptiert werden (gültig):
-
Einzelzertifikat (PEM-codiert):
# comments -----BEGIN CERTIFICATE----- Base64–encoded certificate -----END CERTIFICATE----- -
Mehrere Zertifikate (PEM-kodiert):
# comments -----BEGIN CERTIFICATE----- Base64–encoded certificate -----END CERTIFICATE----- # comments -----BEGIN CERTIFICATE----- Base64–encoded certificate -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- Base64–encoded certificate -----END CERTIFICATE-----
HTTP-Header und gegenseitiges TLS
In diesem Abschnitt werden die HTTP-Header beschrieben, die Application Load Balancers verwenden, um Zertifikatsinformationen zu senden, wenn Verbindungen mit Clients, die gegenseitiges TLS verwenden, aushandeln. Die spezifischen X-Amzn-Mtls Header, die der Application Load Balancer verwendet, hängen vom von Ihnen angegebenen gegenseitigen TLS-Modus ab: Passthrough-Modus oder Verifizierungsmodus.
Hinweise zu anderen HTTP-Headern, die von Application Load Balancers unterstützt werden, finden Sie unter. HTTP-Header und Application Load Balancer
HTTP-Header für den Passthrough-Modus
Für Mutual TLS im Passthrough-Modus verwenden Application Load Balancer den folgenden Header.
Dieser Header enthält das URL-kodierte PEM-Format der gesamten Client-Zertifikatskette, die in der Verbindung dargestellt wird, mit sicheren Zeichen. +=/
Inhalt eines Beispiel-Headers:
X-Amzn-Mtls-Clientcert: -----BEGIN%20CERTIFICATE-----%0AMIID<...reduced...>do0g%3D%3D%0A-----END%20CERTIFICATE-----%0A-----BEGIN%20CERTIFICATE-----%0AMIID1<...reduced...>3eZlyKA%3D%3D%0A-----END%20CERTIFICATE-----%0AHTTP-Header für den Überprüfungsmodus
Für gegenseitiges TLS im Überprüfungsmodus verwenden Application Load Balancer die folgenden Header.
Dieser Header enthält eine hexadezimale Darstellung der Seriennummer des Leaf-Zertifikats.
Beispiel für den Inhalt der Kopfzeile:
X-Amzn-Mtls-Clientcert-Serial-Number: 03A5B1Dieser Header enthält eine RFC2253 Zeichenkettendarstellung des definierten Namens (DN) des Emittenten.
Beispiel für den Inhalt der Kopfzeile:
X-Amzn-Mtls-Clientcert-Issuer: CN=rootcamtls.com,OU=rootCA,O=mTLS,L=Seattle,ST=Washington,C=USDieser Header enthält eine RFC2253 Zeichenkettendarstellung des definierten Namens (DN) des Subjekts.
Beispiel für den Inhalt einer Kopfzeile:
X-Amzn-Mtls-Clientcert-Subject: CN=client_.com,OU=client-3,O=mTLS,ST=Washington,C=USDieser Header enthält das Und-Datum im Format 01. ISO86 notBefore notAfter
Beispiel für den Inhalt einer Kopfzeile:
X-Amzn-Mtls-Clientcert-Validity: NotBefore=2023-09-21T01:50:17Z;NotAfter=2024-09-20T01:50:17ZDieser Header enthält ein URL-codiertes PEM-Format des Leaf-Zertifikats mit sicheren Zeichen. +=/
Beispiel für den Inhalt einer Kopfzeile:
X-Amzn-Mtls-Clientcert-Leaf: -----BEGIN%20CERTIFICATE-----%0AMIIG<...reduced...>NmrUlw%0A-----END%20CERTIFICATE-----%0AGeben Sie den Betreffnamen der Zertifizierungsstelle (CA) bekannt
Die Betreffnamen der Advertising Certificate Authority (CA) verbessern den Authentifizierungsprozess, indem sie Kunden dabei helfen, zu bestimmen, welche Zertifikate bei der gegenseitigen TLS-Authentifizierung akzeptiert werden.
Wenn Sie die Option Betreffnamen von Zertifizierungsstellen ankündigen aktivieren, kündigt der Application Load Balancer die Liste der Zertifizierungsstellen (CAs), denen er vertraut, basierend auf dem Vertrauensspeicher, dem er zugeordnet ist, an. Wenn ein Client über den Application Load Balancer eine Verbindung zu einem Ziel herstellt, erhält der Client die Liste der vertrauenswürdigen CA-Betreffnamen.
Wenn der Application Load Balancer während des TLS-Handshakes ein Client-Zertifikat anfordert, nimmt er eine Liste vertrauenswürdiger CA Distinguished Names (DNs) in seine Zertifikatsanforderungsnachricht auf. Dies hilft den Clients bei der Auswahl gültiger Zertifikate, die mit den angekündigten CA-Betreffnamen übereinstimmen, wodurch der Authentifizierungsprozess optimiert und Verbindungsfehler reduziert werden.
Sie können den Betreffnamen der Zertifizierungsstelle für neue und bestehende Listener ankündigen aktivieren. Weitere Informationen finden Sie unter Hinzufügen eines HTTPS-Listeners.
Verbindungsprotokolle für Application Load Balancer
Elastic Load Balancing stellt Verbindungsprotokolle bereit, die Attribute der an Ihre Application Load Balancer gesendeten Anfragen erfassen. Verbindungsprotokolle enthalten Informationen wie die Client-IP-Adresse und den Port, Informationen zum Client-Zertifikat, die Verbindungsergebnisse und die verwendeten TLS-Chiffren. Diese Verbindungsprotokolle können dann verwendet werden, um Anforderungsmuster und andere Trends zu überprüfen.
Weitere Informationen zu Verbindungsprotokollen finden Sie unter Verbindungsprotokolle für Ihren Application Load Balancer
