信息安全 - 具有扩展密钥用法字段的根 CA - 吾爱随笔录

具有扩展密钥用法字段的根 CA

信息安全证书公钥基础设施证书颁发机构

2021-08-28 18:43:15

我最近开始使用 AWS 的证书管理器为我的负载均衡器获取免费的 TLS 证书。当我检查证书链时，我注意到根 CA（Starfield Class 2 Certification Authority）具有以下扩展密钥使用值：

SSL 客户端
SSL 服务器
网景 SSL 服务器
S/MIME 签名
S/MIME 加密
CRL 签名
任何目的
OCSP 助手
时间戳签名

然后，我在我拥有的 Windows 笔记本电脑上打开了受信任的根证书颁发机构商店，并开始查看几个根 CA。事实证明，它们中的许多具有相同或非常相似的 EKU 值。我理解为什么存在 CRL 和 OCSP（即使我认为根目录会保持离线状态，这会使 OCSP 变得更加困难），但是为什么还有其他的呢？这是否意味着 CA 除了颁发证书之外，还可以签署代码、执行 S/MIME 功能等？或者这些值的存在是否意味着来自该根 CA 的证书最多只能用于那些 EKU 值？

我简要浏览了 RFC 5280的扩展密钥用法部分，我在该主题上看到的唯一内容是：

一般来说，这个扩展只会出现在终端实体证书中。

总结我的问题：

将这些 EKU 值放在根 CA 证书中是否表明从该根下降的最终实体证书最多可以具有这些 EKU 值？
如果不是 1，为什么这些值会出现在多个根 CA 中？是不是这些 CA 也可以用于这些目的？如果是这样，为什么要这样做而不是使用这些 EKU 颁发最终实体证书？

3个回答

您看到该ExtendedKeyUsage列表的原因仅仅是您问题中链接的网站使用的应用程序转储证书的文本表示。

如果您再次查看该页面，您将看到证书的 Base-64 编码表示。将其复制并粘贴到文件中并保存。使用 OpenSSL 转储证书的文本表示，您将看到以下内容。

注意：如果您运行的是 Windows，请使用.cer或.crt扩展名保存它并双击它。Windows 将在 GUI 中显示证书，显示类似的信息。

$ openssl x509 -noout -text -in StarField.cer
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority
        Validity
            Not Before: Jun 29 17:39:16 2004 GMT
            Not After : Jun 29 17:39:16 2034 GMT
        Subject: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b7:32:c8:fe:e9:71:a6:04:85:ad:0c:11:64:df:
                    ce:4d:ef:c8:03:18:87:3f:a1:ab:fb:3c:a6:9f:f0:
                    c3:a1:da:d4:d8:6e:2b:53:90:fb:24:a4:3e:84:f0:
                    9e:e8:5f:ec:e5:27:44:f5:28:a6:3f:7b:de:e0:2a:
                    f0:c8:af:53:2f:9e:ca:05:01:93:1e:8f:66:1c:39:
                    a7:4d:fa:5a:b6:73:04:25:66:eb:77:7f:e7:59:c6:
                    4a:99:25:14:54:eb:26:c7:f3:7f:19:d5:30:70:8f:
                    af:b0:46:2a:ff:ad:eb:29:ed:d7:9f:aa:04:87:a3:
                    d4:f9:89:a5:34:5f:db:43:91:82:36:d9:66:3c:b1:
                    b8:b9:82:fd:9c:3a:3e:10:c8:3b:ef:06:65:66:7a:
                    9b:19:18:3d:ff:71:51:3c:30:2e:5f:be:3d:77:73:
                    b2:5d:06:6c:c3:23:56:9a:2b:85:26:92:1c:a7:02:
                    b3:e4:3f:0d:af:08:79:82:b8:36:3d:ea:9c:d3:35:
                    b3:bc:69:ca:f5:cc:9d:e8:fd:64:8d:17:80:33:6e:
                    5e:4a:5d:99:c9:1e:87:b4:9d:1a:c0:d5:6e:13:35:
                    23:5e:df:9b:5f:3d:ef:d6:f7:76:c2:ea:3e:bb:78:
                    0d:1c:42:67:6b:04:d8:f8:d6:da:6f:8b:f2:44:a0:
                    01:ab
                Exponent: 3 (0x3)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                BF:5F:B7:D1:CE:DD:1F:86:F4:5B:55:AC:DC:D7:10:C2:0E:A9:88:E7
            X509v3 Authority Key Identifier: 
                keyid:BF:5F:B7:D1:CE:DD:1F:86:F4:5B:55:AC:DC:D7:10:C2:0E:A9:88:E7
                DirName:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
                serial:00

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: sha1WithRSAEncryption
         05:9d:3f:88:9d:d1:c9:1a:55:a1:ac:69:f3:f3:59:da:9b:01:
         87:1a:4f:57:a9:a1:79:09:2a:db:f7:2f:b2:1e:cc:c7:5e:6a:
         d8:83:87:a1:97:ef:49:35:3e:77:06:41:58:62:bf:8e:58:b8:
         0a:67:3f:ec:b3:dd:21:66:1f:c9:54:fa:72:cc:3d:4c:40:d8:
         81:af:77:9e:83:7a:bb:a2:c7:f5:34:17:8e:d9:11:40:f4:fc:
         2c:2a:4d:15:7f:a7:62:5d:2e:25:d3:00:0b:20:1a:1d:68:f9:
         17:b8:f4:bd:8b:ed:28:59:dd:4d:16:8b:17:83:c8:b2:65:c7:
         2d:7a:a5:aa:bc:53:86:6d:dd:57:a4:ca:f8:20:41:0b:68:f0:
         f4:fb:74:be:56:5d:7a:79:f5:f9:1d:85:e3:2d:95:be:f5:71:
         90:43:cc:8d:1f:9a:00:0a:87:29:e9:55:22:58:00:23:ea:e3:
         12:43:29:5b:47:08:dd:8c:41:6a:65:06:a8:e5:21:aa:41:b4:
         95:21:95:b9:7d:d1:34:ab:13:d6:ad:bc:dc:e2:3d:39:cd:bd:
         3e:75:70:a1:18:59:03:c9:22:b4:8f:9c:d5:5e:2a:d7:a5:b6:
         d4:0a:6d:f8:b7:40:11:46:9a:1f:79:0e:62:bf:0f:97:ec:e0:
         2f:1f:17:94

这是应该预期的 - 否KeyUsage或ExtendedKeyUsage

根 CA 证书不应真正包含任何扩展（除了可选的SubjectKeyUsage和AuthorityKeyUsage用于帮助构建链的扩展），因为它限制了证书在其整个较长生命周期内的用途。应在从属 CA 级别添加此类限制。

正如您在问题中所述，这 ExtendedKeyUsage是针对特定证书，而不是针对链（与策略和名称约束不同）。

将这些 EKU 值放在根 CA 证书中是否表明从该根下降的最终实体证书最多可以具有这些 EKU 值？

这是对的。特定证书的有效 EKU（大致）是整个证书链中 EKU 扩展限制的交集。因此，如果 CA 证书具有包含 OID1 和 OID2 的 EKU 扩展，则它不能颁发对任何其他 EKU OID 有效的证书。

但是，这不是严格的规则，它取决于执行证书验证的客户端应用程序。例如，为了验证 OCSP 签名证书，OCSP Signing (1.3.6.1.5.5.7.3.9)仅具有叶（签名）证书就足够了。不需要整个链对OCSP Signing usage.

如果颁发的证书包含另一个 EKU OID，并且客户端应用程序询问该证书是否对指定用途有效，则证书链接引擎将不会认为该证书对该 OID 有效。

2018 年 9 月 26 日更新：

上面的声明不是 RFC 的一部分。事实上，RFC 并没有限制 CA 签发 EKU。

这只是关于主要供应商的实施。系统和浏览器通常实现内部证书存储（证书存储、KeyChain、TrustStore 等），证书存储实现存储附加属性，您或供应商可以在其中为证书分配附加属性，而无需修改签名证书。这就是在您的示例证书中处理 EKU 约束的方式。如果您打开证书，您将不会在其中找到任何 EKU 扩展：

但是，它以某种方式包含约束：

以下是通过 Windows 证书存储设置约束的方式：

就像我说的，通过链的 EKU 验证是特定于应用程序的。如果应用程序通过链请求 EKU 验证，并且路径中的每个 CA 证书都不允许 EKU，则验证将失败。如果应用程序仅在叶证书中需要特定的 EKU，并且提供了指定的 EKU，则验证将成功。

ps 在 Windows 上，您不需要使用 OpenSSL 转储证书，而是可以使用内置的 certutil.exe 工具：

certutil -dump path\certfile.cer

据我了解，您的第一个问题的答案是肯定的——至少对于遵循CA/浏览器论坛发布的基线要求的 CA 和软件。具体来说，第 7.1.5 节（“名称约束”）的第一段说：

对于被视为技术约束的从属 CA 证书，证书必须包含扩展密钥使用 (EKU) 扩展，指定授权从属 CA 证书为其颁发证书的所有扩展密钥使用。anyExtendedKeyUsage KeyPurposeId 不得出现在此扩展中。

第 7.1.2 节（“证书内容和扩展”）中也有一些相关评论，包括一个脚注，承认 EKU 扩展的这种使用不符合 RFC 5820。

（我的回答基于基线要求的 1.7.3 版。）

其它你可能感兴趣的问题

上一篇Firejail和Apparmor的比较下一篇Android 消息网络和隐私