通过 HTTPS 访问用户指定主机的应用程序是否应该尝试通过查找其 FQDN 来提供帮助？

通过HTTPS访问用户指定主机的应用程序是一个常见的需求，但在实际应用中可能会遇到一些困惑。对于这个问题，php小编香蕉认为应该尝试通过查找FQDN来提供帮助。FQDN（Fully Qualified Domain Name）是一个完全限定的域名，包含主机名和域名。通过查找FQDN，可以确保准确地定位到用户指定的主机，从而提供准确的帮助和服务。因此，在进行HTTPS访问时，查找FQDN是一个有益的策略。

问题内容

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

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

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

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

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

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

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

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

所以我的问题是：

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

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

谢谢！

解决方法

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

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

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

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

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