使用 Amazon Elastic Load Balancing 的一种方式（或服务器端）TLS/HTTPS 有据可查
文档中对双向（或客户端）TLS/HTTPS 的支持并不明确。
假设 ELB 正在终止 TLS/HTTPS 连接：
ELB 确实支持 TCP 转发，因此 EC2 托管服务器可以建立双向 TLS/HTTPS 连接，但在这种情况下，我对 ELB 终止 TLS/HTTPS 连接并识别客户端感兴趣。
在双端 HTTPS 模式下，我看不出它是如何做到的，因为 ELB 正在建立与后端服务器的第二个 TCP 连接，并且在内部它正在解密/加密客户端和服务器的有效负载......因此服务器不会直接看到客户端证书，并且除了 -For、-Proto 和 -Port 之外，没有记录的 X-Forwarded-* 标头。
另一方面，在 ELB 以 TCP 模式运行时，SSL 协商是在客户端和服务器之间直接完成的，ELB 会盲目地将流捆绑在一起。如果服务器支持该PROXY协议，您可以在 ELB 中启用该功能，以便您可以在服务器上识别客户端的原始 IP 和端口，以及直接识别客户端证书，因为客户端将直接与您协商......虽然这意味着您不再将 SSL 卸载到 ELB，这可能是您尝试做的事情的一部分。
更新：
看起来没有一种方法可以完成您想做的所有事情——卸载 SSL 并识别客户端证书——仅使用 ELB。以下信息以“物有所值”的方式呈现。
显然 HAProxy在 1.5 版本中支持客户端证书，并在标头中传递证书信息X-。由于 HAProxy 还通过配置支持该PROXY协议（类似于ELB（通过协议）和客户端证书信息到应用程序服务器......因此允许您仍然保持 SSL 卸载。tcp-request connection expect-proxyPROXY
我提到这一点是因为它似乎是一个互补的解决方案，可能比任何一个单独的平台都更完整，并且至少在 1.4 中，这两个产品完美地协同工作——我在 ELB 后面成功地使用 HAProxy 1.4 来处理我的所有请求最大的 Web 平台（在我的例子中，ELB 正在卸载 SSL——没有客户端证书），尽管级联负载均衡器明显冗余，但它似乎是一个可靠的组合。我喜欢让 ELB 成为糟糕的互联网上唯一的东西，尽管我没有理由认为直接暴露的 HAProxy 本身就会有问题。在我的应用程序中，ELB 用于平衡 A/Z 中的 HAProxies（我原本打算也自动缩放，从来没有丢失过，但是...）然后可以在将流量传递到实际平台之前对标头进行一些过滤、转发和修改，此外还可以给我一些我没有的日志记录、重写和流量拆分控制。不能单独使用 ELB。
如果您的后端本身可以支持客户端身份验证的 HTTPS 连接，您可以将 ELB 用作端口 443 上的 TCP 到后端侦听端口上的 TCP。这将使 ELB 只是将未加密的请求直接重新发送到您的后端。此配置也不需要将 SSL 证书安装到负载平衡器。
更新：使用此解决方案未设置 x-forwarded-* 标头。
您可以在 Elastic Beanstalk 上切换到单实例，并使用ebextensions上传证书并将 nginx 配置为双向 TLS。
例子
.ebextensions/setup.config
files:
"/etc/nginx/conf.d/00_elastic_beanstalk_ssl.conf":
mode: "000755"
owner: root
group: root
content: |
server {
listen 443;
server_name example.com;
ssl on;
ssl_certificate /etc/nginx/conf.d/server.crt;
ssl_certificate_key /etc/nginx/conf.d/server.key;
ssl_client_certificate /etc/nginx/conf.d/ca.crt;
ssl_verify_client on;
gzip on;
send_timeout 300s;
client_body_timeout 300s;
client_header_timeout 300s;
keepalive_timeout 300s;
location / {
proxy_pass http://127.0.0.1:5000;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-SSL-client-serial $ssl_client_serial;
proxy_set_header X-SSL-client-s-dn $ssl_client_s_dn;
proxy_set_header X-SSL-client-i-dn $ssl_client_i_dn;
proxy_set_header X-SSL-client-session-id $ssl_session_id;
proxy_set_header X-SSL-client-verify $ssl_client_verify;
proxy_connect_timeout 300s;
proxy_send_timeout 300s;
proxy_read_timeout 300s;
}
}
"/etc/nginx/conf.d/server.crt":
mode: "000400"
owner: root
group: root
content: |
-----BEGIN CERTIFICATE-----
MIJDkzCCAvygAwIBAgIJALrlDwddAmnYMA0GCSqGSIb3DQEBBQUAMIGJMQswCQYD
...
LqGyLiCzbVtg97mcvqAmVcJ9TtUoabtzsRJt3fhbZ0KKIlzqkeZr+kmn8TqtMpGn
r6oVDizulA==
-----END CERTIFICATE-----
"/etc/nginx/conf.d/server.key":
mode: "000400"
owner: root
group: root
content: |
-----BEGIN RSA PRIVATE KEY-----
MIJCXQIBAAKBgQCvnu08hroXwnbgsBOYOt+ipinBWNDZRtJHrH1Cbzu/j5KxyTWF
...
f92RjCvuqdc17CYbjo9pmanaLGNSKf0rLx77WXu+BNCZ
-----END RSA PRIVATE KEY-----
"/etc/nginx/conf.d/ca.crt":
mode: "000400"
owner: root
group: root
content: |
-----BEGIN CERTIFICATE-----
MIJCizCCAfQCCQChmTtNzd2fhDANBgkqhkiG9w0BAQUFADCBiTELMAkGA1UEBhMC
...
4nCavUiq9CxhCzLmT6o/74t4uCDHjB+2+sIxo2zbfQ==
-----END CERTIFICATE-----