技术上是否可以颁发完全通配符SSL证书？

Question

我希望获得*的SSL证书。也就是说，对于任何域名。我们的想法是使用自定义CA证书对其进行签名，在目标设备上安装该CA证书，并使用该设备连接到基于IP的地址（例如https://192.168.1.123）。没有DNS可用，每次地址可能不同。目标设备上的浏览器应该在没有警告的情况下工作，但只要所提供的通配符证书由已知CA（我们的自定义CA，其设备上安装了证书）签名，以防止任何可能的MITM攻击。

浏览器会理解这样的通配符证书吗？是否有其他可行方法允许使用浏览器连接到任意基于IP的SSL服务器而无需警告并同时使用MITM保护（假设可以自定义CA的客户端列表）？

Answer 1

有关HTTPS的证书身份验证的两个规范：RFC 2818 (the HTTPS specification itself) Section 3.1和RFC 6125（更新的RFC试图协调如何为任何协议执行此操作）。

据我所知，它可以解释RFC 2818，它并不禁止它（虽然我猜它根本不考虑用例）：

  

名称可能包含通配符      字符*，被认为匹配任何单个域名      组件或组件片段。例如， .a.com匹配foo.a.com但是      不是bar.foo.a.com。 f .com匹配foo.com但不匹配bar.com。

RFC 6125通常不鼓励使用通配符证书（section 7.2），并且原则上只在最左边的标签（section 6.4.3）中允许它。这或多或少暗示应该有多个标签。

有一个additional errata for RFC 6125 on the subject：“ RFC6125错误：检查通配符证书时缺少已显示标识符中标签数量的规范”：

  

另请注意，此问题引出的问题是能够确定什么构成所谓的域名“公共后缀”（例如“.com”，“。co.uk”） - 我们不能简单地写在规范中“通配符必须位于最左边的标签位置，并且通配符右侧必须至少有一个？两个？三个？标签”。

除了规格外，这在实践中不太可行。任何商业CA都不应该发布其中之一。他们偶尔会犯错误，但希望没有任何愚蠢的错误。您可以通过部署自己的CA（或者在您批准的MITM代理中使用本地自动CA）来实现此目的。即使是这种情况，一些客户也会拒绝验证此类证书。例如，Chromium even forbids *.com or *.co.uk。

请注意，在这两种情况下，通配符都用于DNS名称，而不是IP地址。根据需要获得*证书无论如何都不适用于您的用例。也许寻找替代DNS解决方案（例如mDNS）以便能够使用名称可能有所帮助。

Answer 2

是的，有外卡证书。您可以请与SSL证书提供商联系以获取更多详细信息。我怀疑这是否可以基于IP

Answer 3

虽然公钥基础结构已损坏，但您获得*证书并且浏览器会接受它并不会破坏。相关的RFC是RFC2818，如果您阅读它，您会看到浏览器接受*.example.com和www*.example.com，但不接受www.*.example.com，www.*.com甚至* 。