技术上可以发出完全通配的SSL证书吗？

我想获得*的SSL证书。也就是说，对于任何领域。这个想法是用自定义CA证书签名，在目标设备上安装该CA证书，并使用该设备连接到基于IP的地址（例如https://192.168.1.123）。没有可用的DNS，并且地址可能每次都有所不同。目标设备上的浏览器应该没有警告地工作，但是只有当通配符证书由已知CA（这是我们的自定义CA，其证书已安装在设备上）签名时才会工作，以防止任何可能的MITM攻击。技术上可以发出完全通配的SSL证书吗？

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

来源

2014-02-10 dragonroot

如果您能够将CA添加到目标设备，为什么您无法调整该设备上的DNS以知道源服务器的地址？这通常与修改'/ etc/hosts'或本地等价物一样简单。 – SingleNegationElimination

这个问题似乎是脱离主题，因为它不是关于编程。 –

是的，有通配符证书。您可以咨询SSL证书提供商以获取更多详细信息。我怀疑这是否可以基于IP

来源

2014-02-10 17:16:37

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

来源

2014-02-10 17:57:26

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）能够使用名称可能会有所帮助。

来源

2014-02-11 13:23:32 Bruno

技术上可以发出完全通配的SSL证书吗？

回答

相关问题