Windows PKI blog

News and information for public key infrastructure (PKI) and Active Directory Certificate Services (AD CS) professionals

Constraints: what they are and how they’re used

Constraints: what they are and how they’re used

  • Comments 4
  • Likes

Hey everyone this is Wes Hammond from Premier Field Engineering and I wanted to share with you some info that I have gathered about setting up constraints.

What are Constraints?

Constraints are used to restrict certificate authorities that you DO NOT TRUST that are part of your chain.  They come in the form of rules placed on the certificate authority that permit or restrict the certificates issued by the CA based on the criteria provided in the request.

Where to apply Constraints?

This is a great question.  While Constraints can be defined at any level of a PKI, it’s recommended that they be applied at a subordinate (hopefully a Policy CA) and not a Root CA.  Setting this in subordinate CA allows the PKI to maintain flexibility.   If set at the Root CA, this would require a redeployment of the hierarchy in the event a change in the constraint or policy is desired.

Basic Constraints

Basic Constraints limit the path length for a certificate chain.  This type of constraint limits the number of CAs that exist below the CA (depth) where the constraint is defined.  See the diagram below.

 

Specifying a basic constraint of 1 at the policy CA ensures that the maximum path length for certificates that chain to the Policy CA is 1 level deep.  If a subordinate certificate is requested from one of the issuing CA’s, the request will fail.

Applying Basic Constraints

Basic Constraints can be applied with 2 different methods.

CAPolicy.inf

Applying Basic Constraints in the CAPolicy.inf allows the CA Manager to specify the constraint during installation or renewal from the CA where the constraint is being set.

Sample:

[Version]

Signature= "$Windows NT$"

 

[BasicConstraintsExtension]

PathLength=1

Critical=Yes

 

Policy.inf

The administrator of a parent CA can set basic constraints on a subordinate by applying a policy to the request delivered from the subordinate before it is issued.  The syntax is the same as that in the CAPolicy.inf.

Examples:

Here is an example of a request containing Basic Constraints

Naming Constraints

Naming constraints ensure that a certificate request presented to the Certificate Authority must conform to set of naming rules.  All name forms included in the request must be in the permitted namespace and must not be in the excluded namespace.  See the diagram below:



Types of Naming Constraints

 

Relative distinguished name

DIRECTORYNAME = “DC=contoso, DC=com”

DNS domain name

DNS = .contoso.com

Universal Resource Identifiers (URI)

URL = http://.contoso.com

E-mail name and User principal name (UPN)

Email = .contoso.com
UPN = .contoso.com

IP address

IP Address constraints limit the IP or IP ranges that can successfully receive certificates.  The IP(s) must include both the IP address and the subnet mask.

More examples of name constraint and their syntax can be found here:
http://technet.microsoft.com/en-us/library/cc737026(v=WS.10).aspx

Applying Naming Constraints

CAPolicy.inf

Applying Name Constraints in the CAPolicy.inf allows the CA Manager to specify the constraint during installation or renewal from the CA where the constraint is being set by using the [extensions] syntax.  Below is an example that contains both permitted and excluded Name Constraints.

Sample:

[Version]

Signature= "$Windows NT$"

 

[Strings]

szOID_NAME_CONSTRAINTS = "2.5.29.30"

 

[Extensions]

Critical = %szOID_NAME_CONSTRAINTS%

%szOID_NAME_CONSTRAINTS% = "{text}"

_continue_ = "SubTree=Include&"

_continue_ = "UPN = .contoso.com&"

_continue_ = "email = .contoso.com&"

_continue_ = "DNS = .contoso.com&"

_continue_ = "DIRECTORYNAME = DC=corp, DC=contoso, DC=com"&"

_continue_ = "URL = .contoso.com&"

 

_continue_ = "SubTree=Exclude&"

_continue_ = "UPN = east.corp.contoso.com&"

_continue_ = "email = .east.corp.contoso.com&"

_continue_ = "DNS = .east.corp.contoso.com&"

_continue_ = "DIRECTORYNAME = DC=east, DC=corp, DC=contoso, DC=com&"

_continue_ = "URL = .east.corp.contoso.com&"

 

Policy.inf

The administrator of a parent CA can set Name Constraints on a subordinate by applying a policy to the request delivered from the subordinate before it is issued.  The syntax is the same as that in the CAPolicy.inf.  However, an alternative syntax is also supported such as that seen below.

[Version]

Signature= "$Windows NT$"

 

[NameConstraintsExtension]

Include = NameConstraintsPermitted

Exclude = NameConstraintsExcluded

Critical = True

 

[NameConstraintsPermitted]

DNS = .contoso.com

email = .contoso.com

UPN = .contoso.com

DIRECTORYNAME = "DC=corp, DC=contoso, DC=com"

URL = .contoso.com

 

[NameConstraintsExcluded]

DNS = .east.corp.contoso.com

email = .east.corp.contoso.com

UPN = east.corp.contoso.com

URL = .east.corp.contoso.com

DIRECTORYNAME = "DC=east, DC=corp, DC=contoso, DC=com"

 

Examples:

Here is an example of a request that contains Name Constraints.

Application Policy

 

A typical subordinate CA can issue an end entity certificate for “ANY” purpose.  Applying Application Policy allows restriction on the Enhanced Key Usage for certificates issued by a subordinate.  See the diagram below:

Applying Application Policy

CApolicy.inf

Applying Application Policy in the CAPolicy.inf allows the CA Manager to specify the constraint during installation or renewal from the CA where the constraint is being set.

Sample:

[Version]

Signature= "$Windows NT$"

 

[ApplicationPolicyStatementExtension]

Policies = AppEmailPolicy, AppCodeSignPolicy, AppClAuthPolicy, AppSeAuthPolicy

CRITICAL = FALSE

 

[AppEmailPolicy]

OID = 1.3.6.1.5.5.7.3.4 ; Secure Email

[AppCodeSignPolicy]

OID = 1.3.6.1.5.5.7.3.3 ; Code Signing

[AppClAuthPolicy]

OID = 1.3.6.1.5.5.7.3.2 ; Client Authentication

[AppSeAuthPolicy]

OID = 1.3.6.1.5.5.7.3.1 ; Server Authentication


Policy.inf

The administrator of a parent CA can set the Application Policy on a subordinate by applying a policy to the request delivered from the subordinate before it is issued.  The syntax is the same as that in the CAPolicy.inf

Examples:

Here is an example of a request that contains Enhanced Key Usage and/or Application Policy. 

Applying Policy.inf to a request


If you would like to apply a policy.inf to a request use the command line below:

Certreq -policy originalrequest.req policy.inf modifiedrequest.req

originalrequest.req – the original request file provided by the subordinate to the parent CA
policy.inf - The policy file containing the settings you want to be applied to the request
modifiedrequest.inf - This is the output file that will contain the original request and has been modified by the policy.  This file will be supplied to the parent CA instead of the originalrequest.req

Comments
  • I've advocated Domain Name Constraints for X.509 forever. The mechanism is in the standard, but no commercial PKI authority will implement it. If they did it, they would only be able to issue you a single certificate for your in-house PKI Certificate Authority. The problem is that you need at least Windows XP to be able to recognize name constraints in digital certificates and many companies recently ran older versions of Windows.

    After that, your private CA would be able to issue unlimited child certificates which would be trusted globally. That would prevent the PKI CA racket from charging you $50 to $700 for per SSL certificate and it will be a cold day in hell that the public CAs will ever allow this. What they will currently do is sign your private CA so that you have signing rights for any domain. That means you could theoretically issue unathorized certificates for any other domain in the world. But the public CAs will charge you $40,000 and revoke your signing rights if you violate it.

    But this doesn't prevent accidental security breaches and the entire PKI trust model which fundamentally trusts any signing authority is dubious. We have DNSSEC which integrates a proper hierarchical PKI model but who knows when that becomes a universal standard. So we're stuck paying for every SSL cert.

  • Thank you for posting this. I linked this as an answer to my question on ServerFault

    http://serverfault.com/q/576651/51457

  • George, you can unlock yourself from the CA tie in by using DANE

    TLDR: You publish your SSL root into DNS

    http://tools.ietf.org/html/rfc6698

  • Nice article Wes.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment