☰

尽管向两者都颁发了 HTTPS 证书，为什么以及如何阻止客户端站点范围的策略阻止“example.com”而不是“www.example.com”？

tag-icon • tag-icon group-policy ssl-certificate website
尽管向两者都颁发了 HTTPS 证书，为什么以及如何阻止客户端站点范围的策略阻止“example.com”而不是“www.example.com”？

DNS情况如下：

  • example.com.origin A 记录到 10.9.8.7
  • www.example.com. 是 fred.example.com 的 CNAME
  • fred.example.com A 记录 10.9.8.7
  • mail.example.com A 10.9.8.7

该证书具有

  • 主题：example.com
  • 主题替代名称；
    • DNS 名称 =mail.example.com
    • DNS 名称 = example.com
    • DNS 名称 =www.example.com

客户必须有某种我无法检查甚至无法询问的额外网站范围的政策，让他们的 Web 浏览器拒绝他们认为不安全的网站。在我们的案例中，人们最终能够访问https://www.example.com很好，但不是https://example.com，即使这是证书的主题！

我无法在任何地方重现此问题，因为没有真正的问题。所以我在这里问你是否知道大公司正在部署的最新高度警惕的网站安全装置，然后才产生这些错误的怀疑？

为了解决这个问题，我能想到的唯一改变就是理顺我的 DNS，简化它。也许我应该说：

  • example.com.origin A 记录到 192.0.2.1
  • www.example.com. 是 example.com 的 CNAME

或者也许我应该根本不使用 CNAME 而只是为所有同义词对同一个 IP 地址创建单独的 A 记录？

这是否可以防止偏执的网站安全人员将其中一个地址列入黑名单？

附言：我已经进行了完整的 SSLlabs.com 测试，我们获得了“A”评级。唯一的小警告是

  • DNS CAA 否
  • IE 11 / Win Phone 8.1 R 服务器发送致命警报：handshake_failure
  • Safari 6 / iOS 6.0.1 服务器发送致命警报：handshake_failure
  • Safari 7 / iOS 7.1 R 服务器发送致命警报：handshake_failure
  • Safari 7 / OS X 10.9 R 服务器发送致命警报：handshake_failure
  • Safari 8 / iOS 8.4 R 服务器发送致命警报：handshake_failure
  • Safari 8 / OS X 10.10 R 服务器发送致命警报：handshake_failure

少数例外的浏览器握手问题当然不是问题，现在 DNC CAA 可能很有趣。但它会影响 example.com 和www.example.com

相关内容