x.509 V3 扩展基本约束和创建 CA 证书的密钥用法有什么区别？答案

【问题标题】：What is the difference between the x.509 V3 extensions Basic Constraints and Key Usage to create a CA certificate?x.509 V3 扩展基本约束和创建 CA 证书的密钥用法有什么区别？
【发布时间】：2011-08-13 07:23:33
【问题描述】：

这两个动作似乎做的一样：

在 X.509 证书中使用 Basic Constraints 扩展来表示它是 CA 证书并且
使用 Key Usage 扩展，例如表示公钥可用于证书签名。

这些扩展有什么区别？
它们的用途相同还是相辅相成？

【问题讨论】：

你的问题解决了吗？那么请采纳最佳答案。否则，请在此处提及仍然缺少的内容。

标签： security encryption ssl cryptography x509certificate

【解决方案1】：

密钥用法描述了证书的预期用途。

Basic Constraints 扩展描述了具有顶部证书的证书链的深度。换句话说，当颁发子 CA 证书时，CA 使用此扩展来限制其子 CA 的活动。如果顶级 CA 获得了 sub-CA，它允许 sub-CA 颁发最终用户证书，但不允许 sub-CA 拥有自己的 sub-CA。

【讨论】：

@Eugene：我们能否拥有一个具有密钥用法扩展的证书，它可以签署证书，但缺少基本约束？这与拥有一个具有基本约束的证书是 CA 相同吗？无限证书路径？
@user384706 来自 RFC 5280，第 4.2.1.9 节：“符合标准的 CA 必须在所有 CA 证书中包含此扩展，这些证书包含用于验证证书上的数字签名的公钥，并且必须将扩展标记为关键证书。”所以看起来你的问题的答案是“这将违反标准”。但是，我确实看到了没有此类扩展名的证书。
@Eugene:Java 的 PKIX api（用 Java6u23 检查过）确实接受只有 KeyUsage（不是基本约束）的 CA 证书。这是否意味着java违反了RFC？
@user384706 我是谁来评判他们？我引用了 RFC，它说扩展名必须存在。但是，不接受这样的证书会导致兼容性问题，所以我猜 Java 创建者接受不兼容的证书（至少默认情况下）。
@Eugene: 兼容性问题？介于什么之间？合规和不合规的实现？

【解决方案2】：

“密钥用法”定义了可以使用证书中包含的密钥执行的操作。使用示例包括：加密、签名、签署证书、签署 CRL。

“基本约束”标识证书的主体是否是允许颁发子证书的 CA。

对于可用于签署证书的证书，信息在某种意义上是重复的：

X509v3 基本约束：CA：TRUE --- 可以签署证书
X509v3 密钥用法：密钥证书签名 --- 可以签署证书

但“基本约束”也会指定有效认证链的最大深度。

根据RFC 3280 --- X.509，虽然它是重复的，但您需要同时指定两者。这是来自 RFC（第 29 页）的相关段落：

keyCertSign 位在主题公钥为用于验证公钥证书上的签名。如果 keyCertSign 位被置位，然后在基本的 cA 位约束扩展（第 4.2.1.10 节）也必须被断言。

【讨论】：

“信息在某种意义上是重复的”你知道如果实现进行验证，在进行证书路径验证时接受基本约束或密钥用法来表示 CA？
@user384706：不，两者都需要。我已经用信息更新了我的答案。
也有可能是非CA证书颁发的证书：见RFC 3820 - not 3280