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