共用方式為

Constraints: what they are and how they’re used

  • 發行項

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=1Critical=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 = https://.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:
https://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 supportedsuch as that seen below.

[Version]Signature= "$Windows NT$" [NameConstraintsExtension]Include = NameConstraintsPermittedExclude = NameConstraintsExcludedCritical = True [NameConstraintsPermitted]DNS = .contoso.comemail = .contoso.comUPN = .contoso.comDIRECTORYNAME = "DC=corp, DC=contoso, DC=com"URL = .contoso.com [NameConstraintsExcluded]DNS = .east.corp.contoso.comemail = .east.corp.contoso.comUPN = east.corp.contoso.comURL = .east.corp.contoso.comDIRECTORYNAME = "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, AppSeAuthPolicyCRITICAL = 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

  • Anonymous
    March 06, 2014
    The comment has been removed
  • Anonymous
    March 06, 2014
    Thank you for posting this. I linked this as an answer to my question on ServerFault

    http://serverfault.com/q/576651/51457
  • Anonymous
    March 06, 2014
    The comment has been removed
  • Anonymous
    March 18, 2014
    Nice article Wes.
  • Anonymous
    June 08, 2016
    Will these constraints work on a subordinate CA certificate issued to a Mcafee web gateway used for SSL filtering?
  • Anonymous
    July 05, 2016
    The comment has been removed
  • Anonymous
    September 06, 2016
    The comment has been removed