我正在使用由我们的内部CA生成的签名的SSL证书。 我已经添加了主题替代名称，以便myserver.example.net和myserver都对该站点有效。 这在Firefox和IE中都能正常工作，但在Chrome用户使用短名称myserver时，仍然会收到[1]警告消息（“此站点的身份未validation”）。 安装了CA，Chrom在使用FQDN时发现它很好。 在使用SAN的一部分主机名（“uname -n”）时，证书未经validation。 如上所述，产生的错误是不一样的。 根据我读过的内容，如果有一个SAN，通用名称应该被忽略，这似乎是这样的。 在SAN中列出的FQDN似乎工作，只有在SAN中find的节点名称导致此问题。 这里使用的CA来自一个拥有数千个客户端和数百个服务器的大型（多个A类networking）公司。 这里stream行的浏览器是IE浏览器，我想说的是，如果我们没有看到一个问题，我们做这个大规模部署的方式，那么Chrome并不像IE那样行事，担心。
我的问题是，是否有任何方式让用户使用myserver而不在Chrome中获得SSL警告？
错误截图。
1. http://imageshack.us/a/img259/9624/certerror.png
无视谷歌的初步报告，没有上游的帮助。
2. http://productforums.google.com/d/msg/chrome/FWAtO5uikuE/0zVo9FU9pakJ
实际上Chrome正在这里做一些事情。 证书中的所有SAN应该是正向的，并且可以通过公共DNS反向parsing。 内部名称以及私有IP地址（比如RfC1918）在证书中是一个坏主意。 证书的概念是明确地certificate一个实体的身份。 由于有多个主机（称为192.168.0.1）以及多个名为“mail”或“unix”的主机，因此这些主机的证书仅对部分networking有效。
CA /浏览器论坛早些时候不推荐使用带有SAN的证书。 他们发表了一篇专门描述这个问题的论文 在客户端执行这一点也是有道理的，Google似乎是第一个遵循新标准的人。