带有负载均衡器的 aws ssl - ec2 实例 https 请求似乎没有被 ELB 终止
aws ssl with load balancer - ec2 instance https requests seems not terminated by ELB
我在 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 记录。
InService 只会在您在 /var/www/html/ 中创建内容时出现。所以我建议你在那边创建一个index.html文件，等1分钟就可以看到InService了。之后，你必须指出 CNAME 到 elb "address"，它在 Router 53 中必须是小写的。但通常，它不会变得可见，所以只需等待并保持刷新，直到 elb 地址出现在 Router 53 中。我希望它会起作用。
好吧，这是一个愚蠢的错误。在我之前工作的人在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 和
实例，但这是另一个故事。
我想在这里添加我的案例。
ECS集群返回错误，docker容器
通过ECS集群和负载均衡暴露给外部世界
我遇到了与主题中提到的完全相同的错误，
SSL_ERROR_RX_RECORD_TOO_LONG
但是我的 DNS 记录使用了 CNAME 条目（上面的评论中提到了 A），
所以这部分是正确的。
您可以将此错误的故障排除分为两个阶段：
1)
-运行 docker container/s，不要使用http，请求docker容器的URL，
该命令应在 运行s docker container:
的容器实例上执行
curl localhost
or
curl localhost:
在我的例子中，这个阶段过去了，curl 返回了一个 html 响应
2) 检查您的应用程序负载均衡器是否可以处理 https 流量
你可以通过执行命令来做到这一点：
> openssl s_client -connect <连接到负载均衡器的 dns 主机名>: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 侦听器，指向列表中的证书
我帐户中的可用证书数，问题已解决。
我在 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 记录。
InService 只会在您在 /var/www/html/ 中创建内容时出现。所以我建议你在那边创建一个index.html文件，等1分钟就可以看到InService了。之后，你必须指出 CNAME 到 elb "address"，它在 Router 53 中必须是小写的。但通常，它不会变得可见，所以只需等待并保持刷新，直到 elb 地址出现在 Router 53 中。我希望它会起作用。
好吧，这是一个愚蠢的错误。在我之前工作的人在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 和
实例，但这是另一个故事。
我想在这里添加我的案例。 ECS集群返回错误，docker容器 通过ECS集群和负载均衡暴露给外部世界
我遇到了与主题中提到的完全相同的错误，
SSL_ERROR_RX_RECORD_TOO_LONG
但是我的 DNS 记录使用了 CNAME 条目（上面的评论中提到了 A）， 所以这部分是正确的。
您可以将此错误的故障排除分为两个阶段： 1) -运行 docker container/s，不要使用http，请求docker容器的URL， 该命令应在 运行s docker container:
的容器实例上执行curl localhost or curl localhost:
在我的例子中，这个阶段过去了，curl 返回了一个 html 响应
2) 检查您的应用程序负载均衡器是否可以处理 https 流量 你可以通过执行命令来做到这一点：
> openssl s_client -connect <连接到负载均衡器的 dns 主机名>: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 侦听器，指向列表中的证书 我帐户中的可用证书数，问题已解决。