ssl - 颁发全通配符 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 试图协调如何为任何协议(protocol)完成此操作)。

据我所知，RFC 2818 并没有禁止它(尽管我猜它根本没有考虑用例):

Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., .a.com matches foo.a.com but not bar.foo.a.com. f.com matches foo.com but not bar.com.

RFC 6125 通常完全不鼓励使用通配符证书 (section 7.2)，原则上只允许在最左边的标签中使用它 (section 6.4.3)。这或多或少意味着标签应该不止一个。

有一个additional errata for RFC 6125 on the subject :“RFC6125 错误:通配符证书的检查缺少所提供标识符中有多少标签的规范”:

Note also that this issue begs the question of being able to determine what constitutes a so-called domain name "public suffix" (e.g. ".com", ".co.uk") -- we can't simply write into the spec "the wildcard must be in the left-most label position and there must be at least one? two? three? labels to the right of the wildcard's position".

撇开规范不谈，这在实践中不太可能起作用。任何商业 CA 都不应该发布其中之一。也许他们偶尔会犯错误，但希望没有那么愚蠢。您可以通过部署自己的 CA(或者可能在您认可的 MITM 代理中使用本地自动 CA)来实现这一点。即使是这种情况，一些客户也会简单地拒绝验证此类证书。例如，Chromium even forbids *.com or *.co.uk .

请注意，在这两种情况下，通配符都用于 DNS 名称，而不是 IP 地址。无论如何，拥有 * 的证书都不适用于您的用例。或许寻找能够使用名称的替代 DNS 解决方案(例如 mDNS)可能会有所帮助。