Avant de commencer En-têtes HTTP Annoncez le nom du sujet CA Journaux de connexion.

Authentification mutuelle avec TLS dans Application Load Balancer

L'authentification TLS mutuelle est une variante du protocole TLS (Transport Layer Security). Le protocole TLS traditionnel établit des communications sécurisées entre un serveur et un client, le serveur devant fournir son identité à ses clients. Avec le TLS mutuel, un équilibreur de charge négocie l'authentification mutuelle entre le client et le serveur tout en négociant le TLS. Lorsque vous utilisez le protocole TLS mutuel avec votre équilibreur de charge d'application, vous simplifiez la gestion de l'authentification et réduisez la charge de vos applications.

En utilisant le protocole TLS mutuel, votre équilibreur de charge peut gérer l'authentification des clients afin de garantir que seuls les clients de confiance communiquent avec vos applications principales. Lorsque vous utilisez cette fonctionnalité, l'équilibreur de charge authentifie les clients à l'aide de certificats provenant d'une autorité de certification (CA) tierce ou en utilisant le Autorité de certification privée AWS (PCA), éventuellement, avec des contrôles de révocation. L'équilibreur de charge transmet les informations du certificat client au backend à l'aide d'en-têtes HTTP, que vos applications peuvent utiliser pour l'autorisation.

Mutual TLS for Application Load Balancers propose les options suivantes pour valider vos X.509v3 certificats clients :

Passthrough TLS mutuel : l'équilibreur de charge envoie l'intégralité de la chaîne de certificats client à la cible, sans la vérifier. Les cibles doivent vérifier la chaîne de certificats du client. Ensuite, à l'aide de la chaîne de certificats client, vous pouvez implémenter l'authentification de l'équilibreur de charge et la logique d'autorisation des cibles dans votre application.
Vérification TLS mutuelle : l'équilibreur de charge effectue l'authentification par certificat X.509 client pour les clients lorsqu'un équilibreur de charge négocie des connexions TLS.

Pour utiliser le relais TLS mutuel, vous devez configurer l'écouteur pour qu'il accepte les certificats des clients. Pour utiliser le protocole TLS mutuel avec vérification, consultezConfiguration du protocole TLS mutuel sur un équilibreur de charge d'application.

Avant de commencer à configurer le protocole TLS mutuel sur votre équilibreur de charge d'application

Avant de commencer à configurer le protocole TLS mutuel sur votre équilibreur de charge d'application, tenez compte des points suivants :

Quotas

Les équilibreurs de charge d'applications incluent certaines limites relatives au nombre de magasins de confiance, de certificats CA et de listes de révocation de certificats utilisés sur votre AWS compte.

Pour plus d’informations, consultez la section Quotas pour vos Application Load Balancer.

Exigences relatives aux certificats

Les équilibreurs de charge d'application prennent en charge les éléments suivants pour les certificats utilisés avec l'authentification TLS mutuelle :

Certificat pris en charge : X.509v3
Clés publiques prises en charge : RSA 2K — 8K ou ECDSA secp256r1, secp384r1, secp521r1
Algorithmes de signature pris en charge : SHA256, 384, 512 avec RSA/SHA256, 384, 512 avec EC/SHA256 384 512 hachages avec MGF1 RSASSA-PSS

Ensembles de certificats CA

Les règles suivantes s'appliquent aux offres groupées d'autorités de certification (CA) :

Les équilibreurs de charge d'application téléchargent chaque ensemble de certificats d'autorité de certification (CA) par lots. Les équilibreurs de charge des applications ne prennent pas en charge le téléchargement de certificats individuels. Si vous devez ajouter de nouveaux certificats, vous devez télécharger le fichier du bundle de certificats.
Pour remplacer un ensemble de certificats CA, utilisez l'ModifyTrustStoreAPI.

Commande de certificats pour le transfert

Lorsque vous utilisez le relais TLS mutuel, l'équilibreur de charge d'application insère des en-têtes pour présenter la chaîne de certificats des clients aux cibles principales. L'ordre de présentation commence par les certificats foliaires et se termine par le certificat racine.

Reprise de la session

La reprise de session n'est pas prise en charge lors de l'utilisation des modes de transmission ou de vérification TLS mutuels avec un équilibreur de charge d'application.

En-têtes HTTP

Les équilibreurs de charge d'application utilisent X-Amzn-Mtls des en-têtes pour envoyer des informations de certificat lorsqu'ils négocient des connexions clients à l'aide du protocole TLS mutuel. Pour plus d'informations et des exemples d'en-têtes, consultezen-têtes HTTP et TLS mutuel.

Fichiers de certificats CA

Les fichiers de certificats CA doivent satisfaire aux exigences suivantes :

Le fichier de certificat doit utiliser le format PEM (Privacy Enhanced Mail).
Le contenu du certificat doit être inclus dans les -----END CERTIFICATE----- limites -----BEGIN CERTIFICATE----- et.
Les commentaires doivent être précédés d'un # caractère et ne doivent pas en contenir. -
Il ne peut pas y avoir de lignes blanches.

Exemple de certificat qui n'est pas accepté (non valide) :


# 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-----

Exemples de certificats acceptés (valides) :

Certificat unique (encodé PEM) :


# comments
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----

Certificats multiples (codés PEM) :


# comments
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----
# comments
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----

en-têtes HTTP et TLS mutuel

Cette section décrit les en-têtes HTTP que les équilibreurs de charge d'application utilisent pour envoyer des informations de certificat lors de la négociation de connexions avec des clients à l'aide du protocole TLS mutuel. X-Amzn-MtlsLes en-têtes spécifiques utilisés par Application Load Balancer dépendent du mode TLS mutuel que vous avez spécifié : mode relais ou mode vérification.

Pour plus d'informations sur les autres en-têtes HTTP pris en charge par les équilibreurs de charge d'application, consultez. En-têtes HTTP et Application Load Balancers

En-tête HTTP pour le mode relais

Pour le TLS mutuel en mode relais, les équilibreurs de charge d'application utilisent l'en-tête suivant.

Cet en-tête contient le format URL-encoded PEM de l'ensemble de la chaîne de certificats clients présentée dans la connexion, avec +=/ comme caractères sûrs.