Constraints: what they are and how they’re used

This post has been republished via RSS; it originally appeared at: Core Infrastructure and Security Blog articles.

First published on TECHNET on Mar 05, 2014
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


I f 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

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.