Sollten Anwendungen, die über HTTPS auf einen vom Benutzer angegebenen Host zugreifen, versuchen, Hilfe zu leisten, indem sie dessen FQDN nachschlagen?

通过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）

如果我尝试使用 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 和短名称的证书。

Das obige ist der detaillierte Inhalt vonSollten Anwendungen, die über HTTPS auf einen vom Benutzer angegebenen Host zugreifen, versuchen, Hilfe zu leisten, indem sie dessen FQDN nachschlagen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!