Votre instance ne voit pas seulement le certificat du client d'origine ... elle ne participe pas réellement à la même session TLS que le client. ELB Classic et ALB créent deux sessions TLS indépendantes et relient leurs charges utiles ensemble.
Pour faire ce que vous voulez, l'ELB ne peut pas participer au TLS. Tout doit être fait par votre serveur, et l'équilibreur doit fonctionner au niveau 4 ou inférieur. Cela exclut Application Load Balancer, qui fonctionnait uniquement à la couche 7.
Il existe deux solutions pour cela.
L'ancienne solution devait utiliser un ELB (Classic) en mode TCP, avec TLS (SSL) désactivé. L'ELB transmet aveuglément la charge utile des connexions cryptées à l'instance, qui négocie TLS directement avec le navigateur, et peut donc utiliser son fichier CA pour authentifier le navigateur. Cela devient un peu difficile car, par défaut, votre instance ne verra pas l'adresse IP du client, et parce que l'ELB fonctionne en mode couche 4 (sans parler de la gestion du trafic chiffré qu'il ne comprend pas), il ne peut pas ajoutez les X-Forwarded-For en-têtes ... donc vous devez activer le support "Proxy protocol" sur l'ELB, et votre instance doit comprendre comment extraire l'adresse du client du préambule du protocole Proxy.
La nouvelle solution est un troisième type d'équilibreur, appelé Network Load Balancer. Ce service fonctionne à la couche 3 et vous permet - essentiellement - de mapper une seule adresse IP élastique sur plusieurs instances EC2, pour équilibrer les demandes entrantes sur des ports spécifiques, avec des contrôles d'intégrité pour supprimer les instances malsaines de la rotation. Vos instances sont toujours chargées de gérer tous les le TLS eux-mêmes, mais ils verront l'adresse du client sur la connexion entrante.