Google Cloud TCP 外部负载平衡器和 TLS 未自签名答案

【问题标题】：Google Cloud TCP external load balancer and TLS not self signedGoogle Cloud TCP 外部负载平衡器和 TLS 未自签名
【发布时间】：2020-09-29 00:38:29
【问题描述】：

是否可以使用公共证书直接公开 L4 负载均衡器后面的服务器？

此服务器位于 Kubernetes pod 中。它前面有一个 TCP 负载均衡器服务，它创建外部 L4 LB。

我的问题是 TLS 流量没有到达 pod 内的容器。因此，如果您成功使用了类似的配置，我很想知道。

更新

我没有提到流量是GRPC。

这是我所做的：我有一个域和相应的官方证书。我想保护 grpc 连接。

我尝试了两种方法：

使用 google ESP 容器，我将证书作为 nginx 机密，将其传递给容器，设置 ssl 端口。在同一个 pod 中的 ESP 后面，我有我的 grpc 服务器

在这种情况下，我在客户端收到这样的消息：

D0610 14:38:46.246248584 32401 security_handshaker.cc:176] 安全握手失败： {"created":"@1591792726.246234613","description":"握手失败","文件":"../deps/grpc/src/core/lib/security/transport/security_handshaker.cc","file_line":291,"tsi_code":10,"tsi_error":"TSI_PROTOCOL_FAILURE"}

我看到一些与 wireshark 的 TLS 交换，但特别是没有登录。

没有 ESP，我将证书放在我的 GRPC 服务器中。 GRPC 服务器出现如下故障：

错误：1408F10B：SSL 例程：ssl3_get_record：错误的版本号

在google ESP documentation我看到我必须证明该域属于我并上传证书（但在哪里）？

更新 2

截至今天，我没有看到任何证据表明它是可行的。

IMO，主要问题是L4具有与证书域名对应的IP。因此，Pod 没有正确的 IP 来证明他们可以使用证书，因此他们对根的请求被拒绝（我没有证据证明这一点，因为我无法从 ESP 中的 nginx 获取调试信息。我看到了使用纯 GRPC 服务器解决方案请求）。

【问题讨论】：

绝对有可能。到目前为止你做了什么？
L4 不会终止 TLS 连接，它会将其转发到您的 pod。您的服务需要公开端口 443，并且您的 pod 必须允许 SSL 终止
您的 pod 需要托管 TLS 证书（例如使用 Apache 或 nginx）以执行通信握手
@suren 感谢您的反馈，我更新了我的问题
所以，为了确认一下，您想公开一个 gRPC 服务器，它位于一个 pod 内部，在 pod 级别终止 TLS，在 GKE 集群中公开为 LoadBalancer，是否正确？另外，分享您在其中看到 ESP 要求您通过上传证书来证明证书是您的链接。您关注的所有链接也都很好。我正在尝试重现您的问题，此信息将非常有价值，否则我将为您提供 GKE 上 gRPC + ESP 的示例好吗？

标签： ssl google-cloud-platform load-balancing google-kubernetes-engine gke-networking

【解决方案1】：

问题出在 TLS 交换中。

通过在 ESP 中安装证书，它可以在 Web 浏览器中正常工作，并且证书被指示有效，而对于 GRPC 客户端，TLS 握手失败。添加额外的跟踪信息会有所帮助。

通过检查我的证书（不是自签名但附加到我的域），我发现它提供了一个中间证书。我将它与域证书一起安装（在同一个 crt 文件中），然后它就可以工作了。

我不知道它为什么会这样，但可能是由于 grpc 客户端库中的 root_cert 文件太旧了。

顺便说一句，对于域证书，证书的 CN 和 subjectAltName 没有具体要求。没有它也可以工作。所以它必须只适用于我在其他地方看到的自签名证书。

我还有一个问题干扰了我的任务：注意不要将 L4 负载均衡器的服务端口命名为内部带有“http2”。我有一些副作用，因此导致另一个部署失败。其实在做https的时候，不要把http2放在名字里。

无论如何，它现在正在工作并回答赏金请求。感谢所有试图提供帮助的人:)

【讨论】：

通常情况下，服务器必须提供完整的证书链，但一些 TLS 客户端（例如基于 Microsoft 的 SecureChannel 的任何东西）仍然接受没有证书链的证书，如果他们可以在其中找到中间证书和根证书他们的证书存储，因为这是一个常见的部署错误。换句话说，当你的浏览器说证书没问题时，它是在撒谎。其他 TLS 客户端（例如，基于 OpenSSL 的任何东西）更加严格并且会拒绝它。一个简单的检查方法是运行 openssl s_client -showcerts -connect $host:$port 并在输出中查找验证错误。