如何通过 ELB 将 HTTPS 流量路由到 EC2 容器 运行 a Java JHipster webApp
How to route HTTPS traffic through ELB to a EC2 container running a Java JHipster webApp
我有一个 JHipster 单体应用程序（Angular + Java SpringBoot + Tomcat 容器，一切都在一起）在 EC2 中成功部署。我可以设置安全组以启用对 Public DNS 的 8443 个传入请求，并且我能够从任何浏览器访问它。
之后，我已经从 Amazon 申请了一个 public 证书，用于我已经通过 Route53 获得的域。
所以我的想法是使用 443 而不是 8443 和真实域（而不是 AWS 提供的 Public 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 中创建的）
**更新 2019 年 2 月 1 - 4 日 22:21 (GMT-3) **
伙计们，我终于决定在 ELB 后面有一个 NGINX。我还意识到 NGINX 和 App Server 之间的通信可以是 HTTP，因此我的应用程序将在端口 8080 上侦听，从而简化了一些方案。我也意识到我只需要一个证书就可以拥有 "browser padlock" 并加密客户端和 ELB 之间的所有流量，所以无论是否无法下载它（也不需要安装在NGINX 或 App.Server）。
在 Apache 级别，您应该在端口 443 上添加一个侦听器，它将代理传递端口 8443 上的请求。这将确保域的端口 443 上的所有传入请求都将传递给应用程序 运行 在服务器的 8443 端口上
listen 443;
location /{
proxy_pass http://127.0.0.1:8443;
}
终于解决了问题，我可以使 NGINX 正常工作，而且我还必须更改其他内容：
我已经从 Application Load Balancer 转移到 Classic Load Balancer。最终方案就像我在本主题的更新中解释的那样，我的意思是：
用户通过 Classic LB 通过 HTTP 或 HTTPS 连接，然后转到侦听端口 80 的 EC2 NGINX。
然后从 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，你的回答帮助我找到了明确的方向，这个 post 显示了应用的确切解决方案（这就是为什么我会在这个 post 上打绿色勾）。
非常感谢和问候。
** 更新 1 - 2019 年 2 月 10 日 17:21 (GMT-3) ** 最后，我这次使用 Application ELB 而不是 Classic ELB（后者已弃用）重新制作了所有内容，并且一切正常预期，不知道为什么一开始 ELB Classic 不起作用（可能是安全组规则配置中的一些错误或类似的错误）。
我有一个 JHipster 单体应用程序（Angular + Java SpringBoot + Tomcat 容器，一切都在一起）在 EC2 中成功部署。我可以设置安全组以启用对 Public DNS 的 8443 个传入请求，并且我能够从任何浏览器访问它。
之后，我已经从 Amazon 申请了一个 public 证书，用于我已经通过 Route53 获得的域。
所以我的想法是使用 443 而不是 8443 和真实域（而不是 AWS 提供的 Public 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 中创建的）
**更新 2019 年 2 月 1 - 4 日 22:21 (GMT-3) **
伙计们，我终于决定在 ELB 后面有一个 NGINX。我还意识到 NGINX 和 App Server 之间的通信可以是 HTTP，因此我的应用程序将在端口 8080 上侦听，从而简化了一些方案。我也意识到我只需要一个证书就可以拥有 "browser padlock" 并加密客户端和 ELB 之间的所有流量，所以无论是否无法下载它（也不需要安装在NGINX 或 App.Server）。
在 Apache 级别，您应该在端口 443 上添加一个侦听器，它将代理传递端口 8443 上的请求。这将确保域的端口 443 上的所有传入请求都将传递给应用程序 运行 在服务器的 8443 端口上
listen 443;
location /{
proxy_pass http://127.0.0.1:8443;
}
终于解决了问题，我可以使 NGINX 正常工作，而且我还必须更改其他内容：
我已经从 Application Load Balancer 转移到 Classic Load Balancer。最终方案就像我在本主题的更新中解释的那样，我的意思是：
用户通过 Classic LB 通过 HTTP 或 HTTPS 连接，然后转到侦听端口 80 的 EC2 NGINX。
然后从 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，你的回答帮助我找到了明确的方向，这个 post 显示了应用的确切解决方案（这就是为什么我会在这个 post 上打绿色勾）。
非常感谢和问候。
** 更新 1 - 2019 年 2 月 10 日 17:21 (GMT-3) ** 最后，我这次使用 Application ELB 而不是 Classic ELB（后者已弃用）重新制作了所有内容，并且一切正常预期，不知道为什么一开始 ELB Classic 不起作用（可能是安全组规则配置中的一些错误或类似的错误）。