Could someone please explain the difference between Policy Constraints and Basic Constraints?

It appears to me that they are either redundant, or two names for the same thing. I would love some clarification as Google searches aren't helping.

  • They're not the same thing. Basic constraints are simple. Just two variables. One that says CA/not-CA and one that limits pathlength. Policy constraints I don't know. They're defined in the same RFC 5280, but I can only guess at the true usefulness of them. Maybe somebody else can shed light on that. Commented Jan 15, 2016 at 7:07
  • Per RFC5280 "The policy constraints extension can be used in certificates issued to CAs. The policy constraints extension constrains path validation in two ways. It can be used to prohibit policy mapping or require that each certificate in a path contain an acceptable policy identifier." I don't understand what that means, but I found an example of it's use here link Could someone help me interperate? Commented Jan 18, 2016 at 2:19

1 Answer 1


First, let's tackle "Basic Constraints" (RFC 5280, Section These are mostly for the sake of certificates issued for CAs. RFC 5280 only defines two such "constraints":

  • Are you (the subject of this certificate) a CA, yes or no?

This one is pretty straightforward. A CA certificate, by definition, must have a basic constraints extension with this cA boolean value set to "true" in order to be a CA.

  • Assuming you are a CA, how long of path of certificates can you issue?

This is the pathLenConstraint value, which is a number whose value is zero or greater. Let's say I wanted to issue to you a CA certificate using my CA certificate, but I wanted to make sure you in turn could not use that CA certificate to issue other CA certificates. I would add the basic constraints extension to your CA certificate, with the cA value of "true" and the pathLenConstraint value of "0". pathLenConstraint is the number of "non-self-issued intermediate certificates" that could follow from your CA. Note that the end certificate (usually a server or client certificate) does not count as part of this number. So by using a pathLenConstraint of "0" in the CA certificate I issue to you, you can use that certificate to issue other end certificates, but not any intermediate certificates. If no pathLenConstraint value is defined in the basic constraints extension, then no such limit is imposed.

Now, let's look at "Policy Constraints" (RFC 5280, Section The policy constraints extension, per RFC 5280, is for certificates that are issued to CAs; this extension is thus not really useful for end certificates (e.g. client/server certificates). The RFC says that this extension is for constraining path validation to the CA in terms of "policies"; what then are these policies?

Understanding this requires that we look at Certificate Policies, and Policy Mappings. A "certificate policy" is a fancy way of saying "I, as the CA organization, have some specific policy/terms; it is identified by this OID". Thus each certificate policy has an OID, and usually some URI that points to more information about that policy. RFC 5280 defines a "Certification Practice Statement" (CPS) certificate policy, for example, which contains a URI to the processing requirements of the CA (e.g. what their requirements are for getting a certificate issued by them). I think of them as pointers to the terms of use/end user license agreement types of legalese.

Now, each different CA organization will have slightly (to wildly) different policies, but folks will ask a CA "how do your policy X relate to that other CA's policy Y?" Especially when it comes to X509 cross signing (see RFC 4158 for gory details). Thus there is the need for a CA certificate to be able to say "my certificate policy X is equivalent to that certificate policy Y"; this is done using the policy mapping extension, which "maps" the OID of certificate policy X to the OID of certificate policy Y.

Now we have certificate policies, and we have mappings from one certificate policy to another. The policy constraints extension, then, uses these to set limits/requirements, in terms of policies (and mappings of policies), when walking the list of certificates, from end certificate through the intermediate CAs to the root/trusted CA. One of the limits, inhibitPolicyMappings, says "ignore any policy mappings after the Nth intermediate certificate in the path"; the other, requireExplicitPolicy, says "if there are more than N intermediate certificates in that path, require that all of them have X policy".

So, to sum up: basic constraints determine if you are a CA (cA = true), and if so, how long of a trust path can you create (limited by pathLenConstraint). Policy constraints are all about how walking that trust path happens: how many of the intermediates certificates are allowed to have policy mappings, after which the policy mappings of intermediate certificates are ignored (inhibitPolicyMapping = ...), and/or how long can the trust path be, before a specific policy is required (requireExplicitPolicy = ...).

Back to that CA certificate I issued to you, whose pathLenConstraint basic constraint was set to zero. That would prohibit you from issuing your own intermediate certificates. And in that case, placing any policy constraints in that CA certificate would be rather useless, as policy constraints modify the handling of intermediate certificates (which you would be unable to issue/create). Likewise, policy constraints on a non-CA certificate (and end certificate for a client/server) would be useless, for the same reason: they cannot issue/create intermediate certificates.

Now the above is all of the theory; for more information on the actual reality of all of this, in terms of implementations and such, I can highly recommend Peter Gutmann's materials on PKI, such as his X509 Style Guide.

Hope this helps!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .