Blog Post

Core Infrastructure and Security Blog
5 MIN READ

Constraints: what they are and how they’re used

Amer_Kamal's avatar
Amer_Kamal
Icon for Microsoft rankMicrosoft
Jan 24, 2020

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

Updated Feb 21, 2020
Version 2.0
  • ajbravo's avatar
    ajbravo
    Copper Contributor

    FWIW, it seems that Microsoft's implementation of adding name constraints with the certreq tool doesn't meet the RFC rules, and at least some non-Microsoft tools (Java 😎 don't work well when name constraints are added.

     

    It looks like when you add name constraints, and you don't specify values for each type of constraint in the "permitted" section, certreq will add the missing types with an "wildcard."  For instance, if you want to limit just the directory name, it still adds email and URL to the permitted section:

     

     

     

    The problem is that Java chokes on these empty fields... the rfc8222 name (email) isn't allowed to be blank in the RFC, for instance.  

    [NameConstraintsPermitted]
    DNS = .contoso.com
    DIRECTORYNAME = "DC=corp, DC=contoso, DC=com"
    
    
    
    ----- What's added to the certificate:
    DNS = .contoso.com
    DIRECTORYNAME = "DC=corp, DC=contoso, DC=com"
    email = 
    URL = /
    IPAddress = 

    The other issue is that although the MS documentation says that the DNS entries should look like:
    DNS=.contoso.com 

     

    The RFC doesn't seem to allow the DNS to start with a . (though that is explicitly listed as valid in for URLs):

    DNS name restrictions are expressed as host.example.com.  Any DNS
       name that can be constructed by simply adding zero or more labels to
       the left-hand side of the name satisfies the name constraint.  For
       example, www.host.example.com would satisfy the constraint but
       host1.example.com would not.