使用 Amazon Elastic Load Balancing 的一种方式（或服务器端）TLS/HTTPS 是 well documented
对双向（或客户端）TLS/HTTPS 的支持在文档中并不清楚。
假设 ELB 正在终止 TLS/HTTPS 连接：
ELB 确实支持 TCP 转发，因此 EC2 托管服务器可以建立双向 TLS/HTTPS 连接，但在这种情况下，我对 ELB 终止 TLS/HTTPS 连接并识别客户端感兴趣。
【问题讨论】：
标签： ssl amazon-web-services amazon-elb authentication two-way
在双端 HTTPS 模式下，我不明白它是如何实现的，因为 ELB 正在与后端服务器建立第二个 TCP 连接，并且在内部它正在解密/加密客户端和服务器的有效负载...因此服务器不会直接看到客户端证书，并且除了 -For、-Proto 和 -Port 之外没有记录的 X-Forwarded-* 标头。
另一方面，在 ELB 以 TCP 模式运行时，SSL 协商是直接在客户端和服务器之间完成的，ELB 会盲目地将流捆绑在一起。如果服务器支持PROXY protocol，您可以enable that functionality in the ELB，这样您就可以在服务器上识别客户端的原始IP和端口，以及直接识别客户端证书，因为客户端将直接与您协商......虽然这意味着您不再将 SSL 卸载到 ELB，这可能是您尝试做的事情的一部分。
更新：
似乎没有一种方法可以完成您想做的所有事情——卸载 SSL 并识别客户端证书——仅使用 ELB。以下信息“物有所值”。
显然 HAProxy 有support for client-side certificates in version 1.5，并在X- 标头中传递证书信息。由于 HAProxy 还通过配置支持PROXY 协议（类似于tcp-request connection expect-proxy）......所以您可以在 TCP 模式 ELB 后面使用 HAProxy，HAProxy 终止 SSL 连接并转发 both来自 ELB 的客户端 IP/端口信息（通过PROXY 协议）和客户端证书信息到应用程序服务器......因此允许您仍然保持 SSL 卸载。
我提到这一点是因为它似乎是一个互补的解决方案，可能比单独使用任何一个平台功能更完整，而且至少在 1.4 中，这两个产品完美地协同工作——我在 ELB 后面成功地使用 HAProxy 1.4我最大的 Web 平台中的请求（在我的情况下，ELB 正在卸载 SSL——没有客户端证书），尽管级联负载均衡器明显冗余，但它似乎是一个可靠的组合。我喜欢让 ELB 成为糟糕的大型 Internet 上唯一的东西，尽管我没有理由认为直接暴露的 HAProxy 本身就会有问题。在我的应用程序中，ELB 用于平衡 A/Z 中的 HAProxies（我原本打算也自动扩展，但即使在我们繁忙的季节，CPU 利用率也保持如此之低，以至于我从来没有超过一个可用区，我从来没有丢失过一个，但是...）除了给我之外，它还可以在将流量传递到实际平台之前对标头进行一些过滤、转发和修改一些我自己没有 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-----
【讨论】：