【发布时间】:2017-10-09 04:41:38
【问题描述】:
我想为我的 API 自定义“受信任的 CA”配置。当不使用 ELB 时,我可以通过在我的 Web 服务器中配置一个“ca.pem”文件来实现这一点。但是,当使用 ELB 时,我认为我的 Web 服务器没有收到原始传入的客户端证书(而是 ELB 的证书)。
是否有可能以某种方式使我的自定义 CA 生效,即使在 ELB 之后?
【问题讨论】:
标签: amazon-elb client-certificates
我想为我的 API 自定义“受信任的 CA”配置。当不使用 ELB 时,我可以通过在我的 Web 服务器中配置一个“ca.pem”文件来实现这一点。但是,当使用 ELB 时,我认为我的 Web 服务器没有收到原始传入的客户端证书(而是 ELB 的证书)。
是否有可能以某种方式使我的自定义 CA 生效,即使在 ELB 之后?
【问题讨论】:
标签: amazon-elb client-certificates
您的实例不仅看不到原始客户端的证书......它实际上并没有参与与客户端相同的 TLS 会话。 ELB Classic 和 ALB 创建两个独立的 TLS 会话并将它们的负载绑定在一起。
要为所欲为,ELB 根本无法参与 TLS。这一切都必须由您的服务器完成,并且平衡器必须在第 4 层或更低层运行。这排除了仅在第 7 层运行的 Application Load Balancer。
有两种解决方案。
旧的解决方案是在 TCP 模式下使用 ELB(经典),并禁用 TLS (SSL)禁用。 ELB 将加密连接中的有效负载盲目地传递给实例,实例直接与浏览器协商 TLS,因此可以使用其 CA 文件对浏览器进行身份验证。不过,这有点棘手,因为默认情况下您的实例不会看到客户端的 IP 地址,并且因为 ELB 运行在第 4 层模式(更不用说处理它不理解的加密流量),所以它不能添加 X-Forwarded-For 标头...因此必须在 ELB 上启用“代理协议”支持,并且您的实例必须了解如何从代理协议序言中提取客户端地址。
较新的解决方案是第三种类型的平衡器,称为Network Load Balancer。该服务在第 3 层运行,允许您(本质上)将单个弹性 IP 地址映射到多个 EC2 实例,以平衡特定端口上的传入请求,并通过运行状况检查从轮换中删除不健康的实例。您的实例仍然负责自己处理所有 TLS,但它们会在传入连接上看到客户端地址。
【讨论】: