如何通过 ELB 将 HTTPS 流量路由到运行 Java JHipster webApp 的 EC2 容器答案

【问题标题】：How to route HTTPS traffic through ELB to a EC2 container running a Java JHipster webApp如何通过 ELB 将 HTTPS 流量路由到运行 Java JHipster webApp 的 EC2 容器
【发布时间】：2019-06-25 15:17:06
【问题描述】：

我在 EC2 中成功部署了一个 JHipster 单体应用程序（Angular + Java SpringBoot + Tomcat 容器，一切都在一起）。我可以设置安全组以启用对公共 DNS 的 8443 个传入请求，并且我可以从任何浏览器访问它。

之后，我向亚马逊申请了一个公共证书，用于我已经使用 Route53 获得的域。

所以想法是使用 443 而不是 8443 和真实域（而不是 AWS 提供的公共 DNS），所以实际上我创建了一个 ELB（都在同一个 VPC、安全组和托管区域中） .此 ELB 正在侦听 443 并作为默认操作重定向到 8443。

但是.. ERR_CONNECTION_REFUSED 是浏览器显示的内容..

值得一提的是，由于 AWS 不允许我们在运行应用程序的 EC2 的 JDK 中下载证书（至少我在控制台中没有看到任何选项），因此我安装了一个自定义证书（使用 keytools 生成），以便在 Tomcat 中应用它来监听已经提到的 8443 端口。

我也尝试在 8080 而不是 8443 中运行（当然还有更新安全组），但没有任何变化..

你能告诉我我错过了什么吗？到目前为止，我看到的独特方法是使用 NGINX 创建一个新的 EC2，以充当 ELB 后面的反向代理（可能带有重写策略），但除非绝对需要，否则我更愿意避免额外的复杂性。

补充资料：

Tomcat 服务器配置：

    server:
        port: 8443
        server.ssl.key-store: keystore.p12
        server.ssl.key-store-password: thePassword
        server.ssl.keyStoreType: PKCS12
        server.ssl.keyAlias: theKeyAlias

安全组入站规则：

    Custom TCP 8443 with 172.31.0.0/16 (the same range of the ELB)
    HTTPS TCP 443 with 0.0.0.0/0 and ::/0

AWS 证书也已启用并已颁发（CNAME 记录集已在 Route53 中创建）

**更新 1 - 2019 年 2 月 4 日 22:21 (GMT-3) **

伙计们，我终于决定在 ELB 后面安装一个 NGINX。此外，我意识到 NGINX 和 App Server 之间的通信可能是 HTTP，因此我的应用程序将侦听端口 8080，从而简化了方案。我还意识到我只需要一个证书就可以拥有“浏览器挂锁”并加密客户端和 ELB 之间的所有流量，因此无论是否无法下载它（也不需要在 NGINX 中安装）也不是 App.Server）。

【问题讨论】：

标签： java amazon-web-services amazon-ec2 https amazon-elb

【解决方案1】：

在 Apache 级别，您应该在端口 443 上添加一个侦听器，该侦听器将代理传递端口 8443 上的请求。这将确保域的端口 443 上的所有传入请求都将传递给在端口 8443 上运行的应用程序服务器

listen 443;
location /{
proxy_pass  http://127.0.0.1:8443;

}

【讨论】：

非常感谢您的回复。请看我已经进行了更新，顺便说一句，没有太大变化。我最终决定使用 NGINX（虽然你提到了 Apache，但概念是一样的）。我将创建一个新的 EC2，安装 NGINX 并将它放在 ELB 和 EC2 AppServer 的中间。然后，我将提出您为 Apache 建议但针对 NGINX 的等效规则，然后我将在这里告诉您它是如何进行的。谢谢！！
我想将您的答案设置为有用，但 Stackoverflow 告诉我：“感谢您的反馈！声望低于 15 人的投票将被记录，但不要更改公开显示的帖子得分。”

【解决方案2】：

终于问题解决了，我可以让 NGINX 正常工作，而且我还必须改变其他事情：

我已从 Application Load Balancer 传递到 Classic Load Balancer。最终方案就像我在本主题的 UPDATE 中解释的那样，我的意思是：

用户通过 HTTP 或 HTTPS 通过 Classic LB 连接，然后转到 EC2 NGINX 监听端口 80。

然后从 NGINX 到 WebApp 我以这种方式使用了 proxy_pass：

    location / {
        proxy_pass  http://172.x.y.z:8080;
    }

最后是 NGINX 中的 HTTP 转发以独占使用 HTTPS：

    proxy_set_header X-Forwarded-Proto $scheme;
    if ( $http_x_forwarded_proto != 'https' ) 
    {
       return 301 https://$host$request_uri;
    }

Lijo Abraham，你的回答帮助我有了明确的方向，这篇文章显示了所应用的确切解决方案（这就是为什么我会在这篇文章上打勾）。

非常感谢和问候。

**更新 1 - 2019 年 2 月 10 日 17:21 (GMT-3) ** 最后，这次我再次使用 Application ELB 而不是 Classic ELB（后者已弃用）重新制作了所有内容，并且一切都按预期工作，不要'不知道为什么一开始 ELB Classic 不起作用（可能是安全组规则配置中的一些错误或类似的东西）。

【讨论】：