实际上，密码软件是否接受*.com，甚至是*。证书？

Question

假设这将通过您自己的PKI完成，而不是一个公共信任的CA。

考虑到*.sub.domain.com是有效的，而*.domain.com也是有效的，那么在技术上是否有可能颁发*.com甚至*.证书？

我正在调查的证书是“*”证书用于任何其他域名，如"https://google.com“，然后执行MITM攻击。

任何证书验证框架是否支持*.证书？它是否会被彻底拒绝，或者是否适用正常的验证规则？

Answer 1

来自TLS上的RFC-2818-HTTP：

使用RFC2459指定的匹配规则执行匹配。如果证书中存在多个给定类型的标识(例如，多个dNSName名称，则认为可以接受其中任何一个集合中的匹配)。名称可能包含通配符*，该字符被认为与任何单个域名组件或组件片段相匹配。例如，*.a.com与foo.a.com匹配，但bar.foo.a.com不匹配。f*.com与foo.com匹配，但与bar.com匹配。

因此，我相信可以做一些事情，比如拥有一个与各种URLS相匹配的证书：*.com、www.*.com和ssl.*.com。您可能希望尝试双通配符证书 (例如，匹配*.*.com)，但大多数浏览器不会(也不应该)接受它们。

如果现代浏览器不允许下一个级别的外卡从顶级域(例如*.com)下降，我也不会感到惊讶。

Answer 2

从技术上讲，可以制作一个包含名称"*.com“的证书，但根据RFC 2818 (第3.1节)，通配符匹配的是一个域组件，而不是多个域组件(即它对"example.com”有效，但对“www.example.com”无效)。但是，规范与实现者对其所做的工作有区别。有些浏览器接受将通配符与多个域组件相匹配的报告 (即"*.example.com“匹配"sub.www.example.com")。

此外，大多数现代Web浏览器都包含故障安全，它拒绝过于宽泛的通配符证书。参见这个问题："*.com“甚至"*.co.uk”将被浏览器拒绝，即使RFC 2818不会出现任何问题。