我想要一个 SSL 证书*。也就是说，对于任何领域。想法是使用自定义 CA 证书对其进行签名，将该 CA 证书安装在目标设备上，并使用该设备连接到基于 ip 的地址（例如https://192.168.1.123）。没有可用的 DNS，并且地址可能每次都不同。目标设备上的浏览器应该在没有警告的情况下工作，但前提是提供的通配符证书由已知 CA（这是我们的自定义 CA，其证书安装在设备上）签名，以防止任何可能的 MITM 攻击。
浏览器会理解这样的通配符证书吗？是否有任何其他解决方法可以允许使用浏览器连接到任意基于 IP 的 SSL 服务器而不会发出警告并同时具有 MITM 保护（假设可以自定义 CA 的客户端列表）？
关于 HTTPS 的证书身份验证有两个规范：RFC 2818（HTTPS 规范本身）第 3.1 节和 RFC 6125（一个更新的 RFC，试图协调对任何协议的验证方式）。
据我可以解释 RFC 2818，它并没有禁止它（尽管我猜它根本不考虑用例）：
名称可能包含通配符 *，它被认为与任何单个域名组件或组件片段匹配。例如，.a.com 匹配 foo.a.com 但不匹配 bar.foo.a.com。f .com 匹配 foo.com 但不匹配 bar.com。
RFC 6125 通常不鼓励使用通配符证书（第 7.2 节），原则上只允许在最左边的标签中使用（第 6.4.3 节）。这或多或少意味着应该有多个标签。
关于主题的 RFC 6125有一个额外的勘误表：“ RFC6125 错误：通配符证书的检查缺少提供的标识符中有多少标签的规范”：
还要注意，这个问题引出了一个问题，即能够确定什么构成所谓的域名“公共后缀”（例如“.com”、“.co.uk”）——我们不能简单地写入规范“通配符必须位于最左侧的标签位置，并且通配符位置右侧必须至少有一个？两个？三个？标签”。
抛开规格不谈，这在实践中不太可能奏效。任何商业 CA 都不应该发布其中之一。他们也许偶尔会犯错，但希望没有这么愚蠢。您可以通过部署自己的 CA（或者在您批准的 MITM 代理中使用本地自动 CA）来实现这一点。即使是这种情况，一些客户端也会简单地拒绝验证此类证书。例如，Chromium 甚至禁止*.com或*.co.uk.
请注意，在这两种情况下，通配符都用于 DNS 名称，而不是 IP 地址。无论如何，拥有您想要的证书对*您的用例不起作用。也许寻找能够使用名称的替代 DNS 解决方案（例如 mDNS）可能会有所帮助。
虽然公钥基础设施已损坏，但您将获得证书*并且浏览器会接受它并没有那么损坏。相关的 RFC 是 RFC2818，如果您阅读它，您会看到浏览器接受*.example.comand www*.example.com，但不接受www.*.example.com，www.*.com甚至不接受*。
是的，有外卡证书。您可以咨询 SSL 证书提供商以获取更多详细信息。我怀疑这是否可以基于 IP