HTTPS访问短主机名证书验证失败，是否需自动解析FQDN？

我正在开发一个Go语言应用，通过HTTPS从同一Google Cloud项目的GCE实例访问Dataproc集群（无特殊域名配置）。服务器使用自签名证书，已手动安装在客户端。服务器与客户端均为该项目下的GCE实例，其FQDN格式为<hostname>.c.<project_id>.internal。

当使用Go的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，仅当传入完整FQDN时才有效）？
2. 开发需分发的应用时，最佳实践是什么？是否应添加逻辑自动将短主机名转换为FQDN以适配自签名证书，还是让调用者自行处理该错误？

注：我不想跳过证书验证，仅希望了解问题原因及最佳实践。

1. 短主机名验证失败的原因 #

SSL证书的通配符匹配是严格按字符串层级规则执行的：

• 证书中的*.c.<project_id>.internal定义的是匹配三级域名，即任何以.c.<project_id>.internal结尾的完整域名。
• 短主机名<server_hostname>是无后缀的单段字符串，和通配符的层级结构完全不匹配。SSL证书验证环节只会直接对比你传入的主机名字符串与证书的SAN/CN字段，不会自动将短主机名解析为FQDN再做匹配——哪怕DNS能解析出对应FQDN，证书验证也不会做这个转换，只认你传入的原始字符串是否符合通配符规则。

简单来说：你传的是abc，证书认的是*.xxx.yyy，两者字符串结构不符，自然无法通过验证。

2. 分发应用的最佳实践 #

推荐在应用内部自动处理短主机名到FQDN的转换，理由如下：

• 降低使用门槛：调用者无需额外了解GCE内部域名规则，使用更便捷。
• 避免重复错误：若让每个调用者自行处理，容易出现域名后缀拼写错误等问题。
• 兼顾安全性：无需跳过证书验证，同时适配内部环境的域名使用习惯。

具体可参考两种实现方式：

• DNS解析获取FQDN：使用Go的net.LookupHost或net.LookupCNAME方法解析短主机名，拿到对应的FQDN后再发起HTTPS请求，适合跨项目的灵活场景。
• 固定后缀拼接：若确定应用仅在同一GCP项目内使用，可直接将短主机名拼接为<hostname>.c.<project_id>.internal（项目ID可通过环境变量或配置文件传入），这种方式更高效。

内容的提问来源于stack exchange，提问作者user2671688