我正在使用一个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>字符串
但是，如果我传递它的值x（<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的一部分，只是开箱即用，不是吗？或者它总是要求传入的字符串与*.c.<project_id>.internal字符串实际匹配（这意味着它不做查找，只有当你传入fqdn时才能工作）？
1.在构建要分发的应用程序时，围绕这一点的最佳实践是什么？我应该添加一些逻辑来让它计算一个证书，这样它就可以将短名称转换为更有可能与自签名证书一起使用的长名称，或者让调用者自己找出隐藏的错误消息？
注意：我不想跳过验证-我只是想更好地了解正在发生的事情，并知道这里的最佳实践是什么。
谢谢你，谢谢
1条答案
按热度按时间qxsslcnc1#
1.证书与域/主机中包含的名称相匹配，因此即使
<server_hostname>和<server_hostname>.c.<project_id>.internal解析为相同的内容，证书也只包含第二个（或与之匹配的证书名）。由于这些证书名是自己生成的，因此您可以在其中添加短名称作为SAN（主题备用名称）。OpenSSL的其他标志：字符串
公共CA不太可能给予您一个SAN上的证书，但是它不能解析。（有些可能，我还没有尝试过这个）
例如，您不希望
google.com由google.com.someevildomain.org提供服务或信任，因此这是一种安全特性。1.这取决于您是否可以控制证书。如果您可以控制证书，您可以只添加您希望使用的名称。这可能最终会成为一个具有多个SAN的单一证书，在这种情况下，让每个人都使用CDN进行对话可能会更干净。如果您可以导入许多证书，那么让每个服务都有自己的证书，并使用CDN和短名称可能会更好。