应该通过查找应用程序的完全合格域名（FQDN）来提供帮助，以便通过 HTTPS 访问用户指定的主机

有志者，事竟成！如果你在学习Golang，那么本文《应该通过查找应用程序的完全合格域名（FQDN）来提供帮助，以便通过 HTTPS 访问用户指定的主机》，就很适合你！文章讲解的知识点主要包括，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

我正在使用一个 golang 应用程序，该应用程序通过另一台主机上的 HTTPS 与服务器进行通信。具体来说，如果上下文很重要：从同一 Google Cloud 项目中的 GCE 实例与 Dataproc 集群进行通信（无需特殊的域设置）。

服务器生成一个自签名证书，我已在客户端手动安装该证书。

服务器和客户端都是我的 Google 云项目上的 GCE 实例（它们的 FQDN 为 .c..internal）

如果我尝试使用 golang 的 http.Client 从客户端连接到服务器，我会收到如下错误：

failed to verify certificate: x509: certificate is valid for *.c.<project_id>.internal, not <server_hostname>

但是，如果我将其 FQDN 传递给它（.c..internal），则它可以开箱即用。

仅供参考，此行为与我运行 cURL 时看到的一致：

curl: (60) SSL: no alternative certificate subject name matches target host name '<server_hostname>'

所以我的问题是：

1. 为什么它不适用于短/部分主机名？它位于同一域中，因此它是 *.c..internal 的一部分，并且开箱即用，不是吗？或者它是否总是要求使用传入的字符串来实际匹配通配符字符串（这意味着它不进行查找，并且仅在您传入 fqdn 时才有效）？
2. 构建要分发的应用时，最佳实践是什么？我是否应该添加一些逻辑来让它计算 FQDN，以便它可以将短名称转换为更可能与自签名证书一起使用的长名称，或者将其留给调用者来找出神秘的错误消息？李>

注意：我不想跳过验证 - 我只是想更好地了解正在发生的事情，并知道这里的最佳实践是什么。

谢谢！

正确答案

1. 证书根据其中包含的名称与域/主机进行匹配，因此即使 和 .c..internal 解析为相同的内容，证书仅包含第二个（或与其匹配的通配符） 。由于这些是自行生成的，因此您可以在其中添加短名称作为 SAN（主题备用名称）。 OpenSSL 的附加标志：

-addext "subjectAltName = DNS:localhost,DNS:<server_hostname>"

公共 CA 不太可能为您提供具有不可公开解析的 SAN 的证书。 （有些可能，我没试过）

作为示例，您不希望从 google.com.someevildomain.org 提供或信任 google.com，因此这是一项安全功能。

1. 这要看情况。如果您可以控制证书，则只需添加您希望使用的名称即可。这可能最终成为具有许多 SAN 的单个证书，在这种情况下，让每个人都使用 FQDN 进行交谈可能会更干净。如果您可以导入许多证书，那么最好让每个服务都有自己的带有 FQDN 和短名称的证书。

好了，本文到此结束，带大家了解了《应该通过查找应用程序的完全合格域名（FQDN）来提供帮助，以便通过 HTTPS 访问用户指定的主机》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！