首先，让我们解决“基本约束”（RFC 5280，第 4.2.1.9 节）。这些主要是为了为 CA 颁发证书。RFC 5280 只定义了两个这样的“约束”：

• 您（此证书的主体）是 CA，是还是不是？

这个很简单。根据定义，CA 证书必须具有将此cA布尔值设置为“true”的基本约束扩展，才能成为CA。

• 假设您是CA，您可以颁发多长的证书路径？

这是pathLenConstraint值，它是一个值为零或更大的数字。假设我想使用我的 CA 证书向您颁发 CA 证书，但我想确保您反过来不能使用该 CA 证书来颁发其他CA 证书。我会将基本约束扩展添加到您的 CA 证书，其值为cA“true” ，pathLenConstraint值为“0”。 pathLenConstraint是可以从您的 CA 获得的“非自行颁发的中间证书”的数量。请注意，最终证书（通常是服务器或客户端证书）不计入此数字的一部分。所以通过使用pathLenConstraint我颁发给您的 CA 证书中的“0”，您可以使用该证书颁发其他最终证书，但不能颁发任何中间证书。如果pathLenConstraint在基本约束扩展中没有定义任何值，则不会施加这样的限制。

现在，让我们看一下“策略约束”（RFC 5280，第 4.2.1.11 节）。根据 RFC 5280，策略约束扩展适用于颁发给 CA 的证书；因此，此扩展对于最终证书（例如客户端/服务器证书）并不是真正有用。RFC 说这个扩展是为了在“策略”方面限制对 CA 的路径验证；那么这些政策是什么？

理解这一点需要我们查看证书策略和策略映射。“证书策略”是一种奇特的说法，即“我作为 CA 组织有一些特定的策略/条款；它由这个 OID 标识”。因此，每个证书策略都有一个 OID，通常还有一些指向有关该策略的更多信息的 URI。RFC 5280 定义了一个“认证实践声明”（CPS）证书策略，例如，它包含一个指向 CA 处理要求的 URI（例如，他们对获得他们颁发的证书的要求是什么）。我认为它们是法律术语的使用条款/最终用户许可协议类型的指针。

现在，每个不同的 CA 组织都会有略微（甚至非常）不同的策略，但是人们会问 CA“你的策略 X 与其他 CA 的策略 Y 有什么关系？” 尤其是在 X509 交叉签名方面（有关详细信息，请参阅RFC 4158）。因此，CA 证书需要能够说“我的证书策略 X 等同于该证书策略 Y”；这是使用策略映射扩展来完成的，它将证书策略 X 的 OID“映射”到证书策略 Y 的 OID。

现在我们有了证书策略，并且我们有从一个证书策略到另一个证书策略的映射。然后，策略约束扩展使用这些来设置限制/要求，在策略（和策略的映射）方面，当遍历证书列表时，从最终证书通过中间 CA 到根/受信任的 CA。限制之一是inhibitPolicyMappings“忽略路径中第 N 个中间证书之后的任何策略映射”；另一个，requireExplicitPolicy说“如果该路径中有超过 N 个中间证书，则要求它们都具有 X 策略”。

因此，总结一下：基本约束决定了您是否是 CA ( cA = true)，如果是，您可以创建多长的信任路径（受 限制pathLenConstraint）。策略约束都是关于如何走这条信任路径：允许多少中间证书具有策略映射，之后中间证书的策略映射被忽略（inhibitPolicyMapping = ...），和/或信任路径可以多长时间，之前需要特定的策略 ( requireExplicitPolicy = ...)。

回到我发给你的那个 CA 证书，它的pathLenConstraint基本约束设置为零。这将禁止您颁发自己的中间证书。在这种情况下，在该 CA 证书中放置任何策略约束都将毫无用处，因为策略约束会修改中间证书的处理（您将无法颁发/创建）。同样，对非 CA 证书（以及客户端/服务器的最终证书）的策略限制将无用，原因相同：它们不能颁发/创建中间证书。

以上就是全部理论了；有关所有这些实际情况的更多信息，在实现等方面，我强烈推荐 Peter Gutmann 的 PKI 资料，例如他的X509 Style Guide。

希望这可以帮助！