信息安全 - subjAltName X.509 扩展中的 URI - 吾爱随笔录

subjAltName X.509 扩展中的 URI

信息安全 tls 证书公钥基础设施 x.509

2021-08-19 22:44:23

X.509 证书的 subjAltTag 扩展可以接收域名、电子邮件地址、URI 等。我在玩 X.509，它的 subjAltTag 中只有一个 URI 似乎不起作用。这是一个屏幕截图：

FF的X.509解码

地址栏中的 URI（位于顶部）与证书中的 URI 相同。我更新了我的主机文件以将 www.google.com 指向 localhost。他们的证书几乎是 google.com 的证书已辞职。

我的问题是......为什么它不起作用？浏览器只支持域名吗？

附上 X.509 证书及其对应的 RSA 私钥：

这是 Firefox 给我的具体错误：

The certificate is not trusted because it is self-signed.
The certificate is not valid for any server names.

有任何想法吗？

1个回答

建立 HTTPS 连接时，用于验证服务器身份的规则仍然是RFC 2818（第 3.1 节）中给出的规则：

如果存在 dNSName 类型的 subjectAltName 扩展，则必须
将其用作身份。
否则，必须使用证书主题字段中的（最具体的）通用名称字段。尽管
使用通用名称是现有的做法，但它已被弃用，并且鼓励证书颁发机构使用 dNSName 代替。

[...]

在某些情况下，URI 被指定为 IP 地址而不是主机名。在这种情况下，iPAddress subjectAltName 必须出现
在证书中，并且必须与 URI 中的 IP 完全匹配。

在您的证书中，不存在 DNS ( ) 类型的主题备用名称 (SAN) 扩展dNSName。因此，它回退到主题 DN 的通用名称。

更新的规范 ( RFC 6125 ) 协调了跨其他协议的主机名验证过程。但是，它尚未广泛实施。

它允许使用 URI，并说明了这一点（除其他外）：

[...] 因此，本文档仅将统一资源标识符 [URI] 作为一种与 DNS 域名（通过 URI“主机”组件或其等效项）进行通信的方式进行讨论，而不是作为一种与服务的其他方面进行通信的方式，例如作为特定资源（通过 URI“路径”组件）或参数（通过 URI“查询”组件）。

本质上，只有方案和主机名真正从该 URI 中使用。这意味着它仅比 DNS SAN 条目更具体，通过将使用限制为特定协议（据我快速阅读，甚至不是端口）。

该规范仅在大约一年前完成，时间不长。目前尚不清楚它将被广泛采用。为了澄清和协调现有实践，这当然值得付出努力，但我想 CA 和实施者需要更好地了解它并找到使用 URI SAN 颁发证书的需求，因为它没有映射到以前使用的规范（RFC 2818)。我想服务提供商的需求会很小，因为无论如何很少有客户支持它。

许多浏览器并没有完全实现 RFC 2818（例如，对主题名称 CN 中的 IP 地址更宽松，没有 SAN）。

（附带说明一下，从客户端证书的角度来看，您可能对WebID 项目感兴趣，该项目探索了 PKIX 以外的其他方法来验证客户端证书并在 SAN 中使用 URI。）

其它你可能感兴趣的问题

上一篇TrueCrypt 哈希可以减慢吗？下一篇从安全角度来看，硬件配置的哪些方面很重要？