带有负载均衡器的 aws ssl - ec2 实例 https 请求似乎没有被 ELB 终止答案

【问题标题】：aws ssl with load balancer - ec2 instance https requests seems not terminated by ELB带有负载均衡器的 aws ssl - ec2 实例 https 请求似乎没有被 ELB 终止
【发布时间】：2017-08-10 02:43:43
【问题描述】：

我在 aws 中托管一个域，并希望允许对其进行 https 请求。我已经完成了以下步骤。

向 ACM 请求证书，验证电子邮件并颁发。
创建了一个带有 http 和 https 侦听器的经典负载均衡器 (LB)，通过 http(80) 转发到实例。
将证书附加到LB并添加运行网站的实例。
确保附加到实例和 LB 的安全组在入站规则中有 http(80) 和 https(443)。
LB 和实例安全组的唯一出站规则是（所有流量 - 全部 - 全部 - 0.0.0.0/0）。

然后我等待实例“inService”并通过浏览到它的 DNS 并打开它来测试 LB。还打开了 http://mydomain.com，但是当我尝试 https://mydomain.com 时，我收到一条消息，提示浏览器无法访问服务器。
经过一番搜索，我添加了以下 2 条记录。

名称为“mydomain.com”且值为“LB domain.com”的记录。
名称为“www”且值为“mydomain.com”的 CNAME 记录。

我又试了一次，结果和上面一样。最后我得到了一个答案，我应该在我的实例服务器中启用 https。

当我这样做并浏览时，我得到一个“安全连接失败”，错误代码为“SSL_ERROR_RX_RECORD_TOO_LONG”。

看起来 LB 没有终止对我的域的 https 请求。
知道我做错了什么！

更新：我删除了我创建的 A 记录，但是当我进行 DNS 查找时，我发现了一个指向我的弹性 ip 的 A 记录。虽然我有 CNAME 记录，但 DNS 查询显示我没有 CNAME 记录。

【问题讨论】：

“我应该在我的实例服务器中启用 https”不正确。您是否等待 DNS 更改传播？另外你为什么在你的问题标题中提到“ssh”？
是的，域已经在没有 LB 的情况下运行。添加 LB 后，我一直等到实例状态变为“服务中”。这之后我需要等待吗？我的意思是 ssl 我编辑了它
当您进行 DNS 更改时，您必须等待更改传播。这与您的实例在负载均衡器中“服务”完全无关。尝试从本地计算机运行 nslookup 并验证域现在指向负载平衡器。
它返回了与我的实例关联的弹性 IP。它应该返回负载均衡器的 ip 吗？
@AbdoSaiedAnwar 是的，它需要返回负载均衡器的地址。 DNS 更新可见性的延迟取决于您如何在 old DNS 记录上设置 TTL - 在您更改它之前。 “传播”几乎是瞬时的，但旧记录需要超时才能看到新记录。

标签： amazon-web-services ssl amazon-ec2 https elastic-load-balancer

【解决方案1】：

好吧，这是一个愚蠢的错误。在我之前工作的人在godaddy中注册了域名，并使用godaddy上的A记录指向了实例。所以我在 route53 中添加的记录是没有意义的。所以我在godaddy 中创建了一个CNAME 记录，它解析为ELB DNS，现在一切正常。

对于那些可能遇到类似问题的人，我会尝试写一些建议。
首先，当您选择添加负载均衡器时，您的实例不应该直接被客户访问。您应该将用户重定向到 ELB，而 ELB 将完成剩下的工作。如果您从其他地方而不是 AWS 获得 DNS，请按照此答案的第一段进行操作。否则，如果您在 AWS 中有您的域的有效托管区域，则在 Route53 中添加一条 A 记录。
在此步骤之后，如果 https 仍然无法正常工作。您可以检查对您的域的请求是否到达 ELB。您可以使用负载平衡器 log Access 或 cloudwatch 来做到这一点。它们都为您提供到达负载均衡器的请求。 cloudwatch 使用起来更简单，但 log Access 可为您提供有关请求的更多详细信息。
如果请求未到达，则您添加的记录尚未传播，或者您没有将它们添加到正确的位置（就像我一样）。
如果请求确实到达了 ELB 但仍然存在问题，那么您可能错过了设置中的某些内容。确保您完成了问题中提到的 5 个步骤。这个video 在这种情况下会很有帮助。
最后，值得一提的是，如果您使用来自 ACM 的证书，则无需对运行在其上的服务器进行任何更改你的实例使 https 工作，因为在这种情况下，ELB 站在你的实例前面，它为你工作。当然你可以在你的 ELB 和例如，但这是另一个故事。

【讨论】：

【解决方案2】：

只有当您在 /var/www/html/ 中创建内容时，InService 才会出现。所以我建议你在那里创建一个 index.html 文件，然后等待 1 分钟以查看 InService。之后，您必须将 CNAME 指向 elb “地址”，该地址在路由器 53 中必须为小写。但通常，它不会变得可见，因此请等待并不断刷新，直到路由器 53 中出现 elb 地址。我希望它会工作。

【讨论】：

感谢您的回答。我的问题不同，我回答了。

【解决方案3】：

我想在这里添加我的案例。 ECS集群、docker容器中返回错误通过 ECS 集群和负载均衡器向外部世界公开。

我遇到了与主题中提到的完全相同的错误，

SSL_ERROR_RX_RECORD_TOO_LONG

但是我的 DNS 记录使用了 CNAME 条目（上面的评论中提到了 A），所以这部分是正确的。

您可以将此错误的故障排除分为两个阶段： 1) - 运行 docker container/s，不使用 http，请求 docker 容器的 URL，该命令应该在运行 docker 容器的容器实例上执行：

卷曲本地主机要么卷曲本地主机：

在我的情况下，这个阶段过去了，curl 返回了一个 html 响应

2) 检查您的应用负载均衡器是否可以处理 https 流量你可以通过执行命令来做到这一点：

> openssl s_client -connect :443

在我的情况下，应用程序负载平衡器无法正常运行处理 ssl 并处理一系列证书

请找到负载均衡器的命令输出示例无法处理以下 https 流量：

CONNECTED(00000003)
140181833668512:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 289 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1594020928
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

为了解决第二个问题，我重新创建了一个应用负载均衡器，再次配置 https 监听器，从列表中指向一个证书我的帐户中有可用的证书，问题已解决。

【讨论】：