Was this page helpful?
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

Understanding Constraints

Updated: August 13, 2009

Applies To: Windows Server 2003 with SP1

The key to qualified subordination is restricting what certificates issued by the qualified subordinate CA, or by CAs that chain through the qualified subordinate CA, are trusted by your organization. This is accomplished by defining basic constraints, name constraints, issuance policy constraints, or application policy constraints in one of two ways:

  • Constraints can be defined during the installation of the CA. By including the sections defined below in the CAPolicy.inf file, the basic constraints, name constraints, issuance policy constraints, and application policy constraints are defined at the CA during the installation of the CA or during the certificate renewal process at a CA.

  • Constraints can also be defined during the cross-certificate request process by defining the constraints in the Policy.inf file. The Policy.inf file defines the constraints implemented in the cross-certification certificate used to define the qualified subordination.

Appendix A contains an example of a Policy.inf file. Appendix B contains a sample of the CAPolicy.inf file.

Constraints are defined in section 4.2 "Standard Certificate Extensions" in RFC 2459.

For more information about how the certificate chaining engine uses constraint information when building certificate chains, see Certificate Revocation and Status Checking (http://go.microsoft.com/fwlink/?LinkID=27081).

Basic Constraints

Basic constraints allow a CA administrator to limit path length for a certificate chain. You can specify a basic constraint that defines the maximum number of CAs that can exist below the CA where the basic constraint is assigned. For example, if you define a path length of zero, the CA can only issue end-entity certificates and is not permitted to issue SubCA certificates.

Figure 1 shows a CA where a basic constraint is applied that limits the path length to two.

Art Image

Figure 1: Applying Basic Constraints

The basic constraint ensures that the maximum path length for certificates that chain to the CorpCA that are trusted is two deep. This means that only two more layers of CAs can exist below the CA where the basic constraint is defined. In this example, the AsiaCA is restricted so that it can only issue trusted end-entity certificates. If a certificate issued to the JapanCA or any certificate issued by the JapanCA is presented, the chain would fail chain verification, because the certificate would result in a chain with a path length greater than two. Whenever a CA issues a certificate to another CA, it can reduce the path length, but never increase the permitted length.

Basic constraints are fully defined in section of RFC 2459.

Best Practice A best practice that can be applied in regards to basic constraints is to only restrict the path length in a subordinate CA certificate, not a root CA certificate. The reason this is more commonly employed is that a change in the root requires a complete redeployment of the hierarchy and the root certificate should a change in the path length be desired. Therefore, in the previous example, the RegionCA certificate would be issued with a PathLength = 1 and have no length defined in the root CA certificate.

Name Constraints

Name constraints allow you to designate which namespaces are either permitted or excluded for certificates issued by CA where qualified subordination is defined. When a request is received at the qualified CA, the names present in the subject and the subject alternate name fields are compared to the configured name constraints to determine whether the namespace is permitted or excluded. In other words, the CA enforces all constraints defined in the CA certificate.

If the name presented in the request is not present in the list of constraints, the request will be rejected by the qualified CA. All names in a certificate request must be within permitted namespaces and none may be within an excluded namespace for the certificate to be issued.

Name constraints allow you to control what namespaces are managed by each CA in your organization and those that you trust from other organizations. When you deploy a qualified subordinate CA, you must carefully consider what namespaces you wish to allow the CA to issue, and more importantly in some cases, what namespaces you wish to prevent the qualified subordinate CA from supporting.

For example, when you configure qualified subordination between your organization and a partner organization, you would typically not want your partners CA infrastructure to issue certificates containing names in your organizations namespace. Remember that a valid certificate that contains a UPN for your organization is mapped to the user account with the UPN as an attribute. It does not matter which CA issues the certificate, only that the certificate chains to a CA certificate in the NTAuth store. The use of name constraints can ensure that your namespace, and all recognized formats of your namespace, are excluded for certificates issued by your partners CA hierarchy.

In the case where both permitted and excluded name constraints exist, the excluded name constraints will always take precedence. For example, if you create a permitted DNS name constraint for the namespace .microsoft.com and an excluded DNS name constraint for .subdomain.microsoft.com, all certificates for subdomain.microsoft.com will be rejected, even though the microsoft.com namespace is permitted.

The default policy of a Microsoft client validating a certificate with name constraints asserted is that all names have to be explicitly permitted. For example, if a name constraint does not specify the e-mail name as a permitted type, and a certificate request contains an e-mail name, the request will be rejected. It is possible to relax this policy and implicitly allow names not defined in the name constraint extension by configuring the CA policy in the registry.

The certificate request is only accepted if each name in the certificate request matches at least one of the permitted name constraints configured at the qualified subordinate CA. In other words, if the certificate request contains the requestors name in both an LDAP distinguished name format and in a UPN format, both names must match permitted name constraints. If one of the presented names does not match, the certificate request fails.

Name Constraint Processing

When a certificate request is presented to a subordinate CA under qualified subordination rules, all name forms in the certificate request must be within the permitted namespaces. In addition, the subject names must not be within an excluded namespace. The permitted and excluded name constraints are processed separately.

The following rules are followed by the qualified subordinate CA:

  • A certificate request is successful if all names in the certificate request succeed in matching the corresponding permitted name constraints.

  • A certificate request is unsuccessful if any names in the certificate request succeed in matching the corresponding excluded name constraint.

  • A certificate request containing names that cannot be matched with either the permitted or excluded names is considered excluded and fails.

  • Comparison of the name identifying the subject entity with the qualified subordinate CA's name constraints is performed using the following rules:

    • The comparison is not case-sensitive if the name or part of the name is encoded with an IA5 string. If it is encoded as a Unicode or UTF8 string, the comparison will be a binary match of the content.

    • Name constraints are applied to the Subject name field and any existing Subject Alternate Name extensions.

    • A qualified subordinate CA's name constraints cannot permit names excluded by its parent CA. For example, if the parent CA excludes the DNS name .microsoft.com, then its qualified subordinate CA cannot permit the DNS sub-domain .example.microsoft.com. The name constraints are checked by the CA to ensure that its chain is valid by calling CryptoAPI.

    • Name constraints apply to all names contained in subject and subject alternate name extensions in an end certificate. Each name in the subject or subject alternate name extensions must match at least one of the name constraints listed for that name type. A subject name or subject alternate name that does not match a listed name type is rejected.

    • Constraints apply only when the namespace types specified as name constraints are present in the certificate request. If no namespace of the specified types is in the certificate request, the certificate is acceptable. For example, a CA is configured with the following name constraints:

      Include = NameConstraintsPermitted
      Exclude = NameConstraintsExcluded
      Critical = True
      DirectoryName = "DC=Microsoft, DC=Com"
      email = @microsoft.com
      UPN = .microsoft.com
      UPN = @microsoft.com
    In this configuration, if the CA receives a request with the e-mail name of user1@northwindtraders.com, the request would be rejected. Likewise, the request would be rejected if the subject alternate name contained user1@northwindtraders.com while the subject name contained CN=user1,OU=Contractors,DC=Microsoft,DC=Com. Remember that all subject names must match the name constraints for a certificate to be issued. The default policy as mentioned previously requires all names to be defined unless otherwise configured on the certification authority.

If you do not specify permitted or excluded names, you are creating a wildcard (*) name constraint for those name constraint formats.

When the name constraint processing is completed, the validation process will result in one of the following outcomes:

  • Permitted The end certificate contains a name that is listed as permitted in an issuers name constraints extension.

  • Not permitted The end certificate contains a name that is not listed as permitted in an issuers name constraints extension.

  • Excluded The end certificate contains a name that is listed as excluded in an issuers name constraints extension.

  • Not Defined The issuer certificate does not list a constraint for a specific name type (such as Directory Name or IP Address).

Windows Server 2003 CAs will have constraints set to permit all namespaces for a particular name type, unless specified otherwise in the name constraints extension in the Policy.inf file.

Applying Name Constraints

The following naming and addressing format are natively supported for use in Policy.inf when defining name constraints:

  • Relative distinguished name

  • DNS domain name

  • Universal Resource Identifiers (URI)

  • E-mail name and User principal name (UPN)

  • IP address

Additional name constraint forms may be enforced using the Other Name forms, which are identified by name and object identifier that are UTF8 or ASN.1 encoded. Other Names can be used to represent names that are outside of the standard name types such as Rfc822Name, DNS, or X.500 Directory Name. It consists of an object identifier and a binary blob. The most common Other Name is the Universal Principal Name (UPN) Name, which has the constant OID_NT_PRINCIPAL_NAME as the object identifier. The version 2 "Domain E-mail Replication" template certificates and the Version 1 "Domain controller" certificates have a subjectaltname extension that contains the constant OID_NTDS_REPLICATION as other name type and the GUID representation of the DC as the blob. In Windows 2000, only the UPN was present in the other name constraint. However, now in Windows Server 2003, the other name constraint has been expanded to support even the domain controller GUIDs. The following is the syntax where the first part is the object identifier, followed by a qualifier identifying the encoding of the following data as UTF8 or octet or ASN.1:





One scenario where this may be useful is when you have smartcard logon across forests, wherein the other domain has Windows 2000 domain controllers. In this case, you can provide an additional name constraint as "OtherName=" to allow all Domain e-mail replication certificates and restrict the namespace using the DNS name constraint. It is technically possible to restrict the GUID of a domain controller as another name but that would not be a generic constraint but a specific constraint to only one domain controller.


The name constraints are configured in one of two locations. When creating a new CA, you can define name constraints for that CA by configuring CAPolicy.inf to impose name constraints. Likewise, if you are creating a qualified subordinate CA certificate, you would define name constraints in the Policy.inf file. In both cases, the following syntax is used:

Include = NameConstraintsPermitted
Exclude = NameConstraintsExcluded
Critical = TrUe

DNS = ""

DNS = .nwtraders.com
email = @nwtraders.com
UPN = .nwtraders.com
UPN = @nwtraders.com
URI = ftp://.nwtraders.com
DIRECTORYNAME = "DC=NWtraders, DC=com"
The critical = True in the [NameConstraintsExtension] indicates that this extension is marked as critical. If the validating computer cannot parse the extension, it must reject the certificate chain.

Relative Distinguished Name Constraints

Relative distinguished names are used to identify the names of objects stored in directories such as Active Directory or X.500 directories. Using Relative distinguished name constraints allows you to restrict a qualified subordinate CA to issue certificates only to specific users or computers in Active Directory by using the objects Relative distinguished name. The distinguished name can be very specific, where the permitted or excluded Relative distinguished name references a specific object. Or, the distinguished name can be a wildcard value that references all the objects within a specific container, domain, or organizational unit.

The name constraint must be included in either the Policy.inf file used to create a qualified subordinate CA or in the CAPolicy.inf file used when installing a new subordinate CA. Table 1 shows some examples of LDAP name constraints and defines what objects the constraints refer to.

Table 1 Name Constraint Examples


Relative Distinguished Name Constraint Includes

All objects in the example.microsoft.com domain


All objects in the Users container in the example.microsoft.com domain

CN=Brian Komar,CN=Users,DC=microsoft,DC=com

The user object Brian Komar in the Users container in the microsoft.com domain


All objects in the Marketing OU of the Microsoft.com domain


All domain controllers in the microsoft.com forest

OU=Domain Controllers, DC=Redmond,DC=Microsoft,DC=Com

All domain controllers in the Redmond.microsoft.Com domain.

The range of characters in the allowed name constraint is defined by the relative distinguished name (also known as RDN) type. Most relative distinguished names (such as O=, OU=,CN=, and so on) support international (UTF8) characters, where relative distinguished names that include (DC=,C=,e-mail, and so on) support IA5 character types. A Relative name constraint will appear in either the permitted or excluded name constraints using the following format:

DIRECTORYNAME = "DC=NWtraders, DC=com"

DNS Name Constraints

DNS name constraints compare any DNS names contained in certificate requests to the list of permitted and excluded DNS name constraints. As with LDAP distinguished name constraints, the name in the certificate request must match one of the permitted names for the certificate to be issued.

The DNS domain names accepted by the subordinate CA must follow the standard DNS naming conventions as specified in RFCs 1034 and 1035, and are listed in either the Policy.inf or CAPolicy.inf file used. Therefore, the DNS name constraint cannot contain international character sets.

When configuring a DNS name constraint, you can either designate a specific DNS host name, for example, host.example.microsoft.com, or you can designate a DNS namespace. For example, the DNS name constraint .example.microsoft.com indicates all hosts that have a DNS name that ends with example.microsoft.com. The preceding period (.) indicates that any DNS name that ends with example.microsoft.com matches the name constraint.

This does not include a host that does not have a period preceding example.microsoft.com. For example, the host named ourexample.microsoft.com would not result in a match when compared to the name constraint .example.microsoft.com.

Table 2 demonstrates the results for submitted DNS names against configured DNS name constraints.

Table 2 Evaluating DNS Name Constraints


Submitted DNS Name DNS Name Constraint Evaluation





No Match


No Match



Evaluate your DNS constraints carefully. Remember that all excluded name constraints take precedence over a permitted name constraint. For example, if you permitted .example.microsoft.com and excluded .microsoft.com, a request from www.example.microsoft.com will be rejected. This DNS name matches both the excluded and permitted name constraints. Because there is a match on the excluded name constraint, the permitted name constraint is not observed.

A DNS name constraint will appear in either the permitted or excluded name constraints using the following format:

DNS = .nwtraders.com

Uniform Resource Identifier (URI) Constraints

Uniform Resource Identifiers (URIs) identify resources on the Internet that use identifiers such as URL, FTP, HTTP, telnet, mailto, news, and gopher. The URI naming conventions supported for name constraints must follow the syntax specified in RFC 2396.

When a qualified subordinate CA validates a URI name, the protocol element in the URI is ignored. For example, if the submitted URI is http://www.example.microsoft.com and the URI name constraint is URL=ftp://.example.microsoft.com, the actual comparison performed is between the host name www.example.microsoft.com and the name constraint .example.microsoft.com. In this case, the result would be a match, even though the protocols differ.

As with DNS constraints, a URI constraint can reference either a host or a domain. If a preceding period is included in the URI constraint, the domain name must include the entire suffix defined in the name constraint. For example, if the URI constraint is .example.microsoft.com, then matches are achieved for west.example.microsoft.com and for east.example.microsoft.com.

The most frequent application of URI name constraints is the validation of certificate requests for Web Server certificates, where the Web servers URL is submitted in the certificate request. For example, if the Web Server certificate request has a name of http://www.microsoft.com and the qualified subordinate CA's permitted URI name constraint is URL=http://www.microsoft.com, then this URI constraint would permit the certificate request for the Web Server certificate.

A URI name constraint will appear in either the permitted or excluded name constraints using the following format:

URL = "http://.microsoft.com"

RFC 822, E-mail, and UPN Constraints

RFC 822 and e-mail constraints must follow RFC 822 naming conventions and use IA5 encoding of character strings. User Principal Names (UPNs) use the same syntax but are encoded using UTF8. Although RFC 822 names, UPNs, and E-mail addresses share the same syntax, you must provide separate examples in the name constraints listing of Policy.inf to differentiate between requests using e-mail addresses and requests using UPN names.

When defining RFC 822, E-mail, or UPN constraints, you can specify constraints for individual addresses or for addresses that end with a specific domain.

For example, to create a name constraint for the e-mail address for a Joe Smith at Northwind Traders, you could create a E-mail address constraint for jsmith@nwtraders.com. To create a name constraint for all e-mail users at Northwind Traders, you would set the e-mail constraint to be @nwtraders.com. By not placing any text to the left of the ampersand, the e-mail constraint becomes a wildcard representing all e-mail addresses in the nwtraders.com domain.

Table 3 shows some examples of RFC822, E-mail, and UPN constraints and how they evaluate.

Table 3 RFC 822, E-mail, and UPN Constraint Evaluation


Submitted Address UPN/E-Mail Constraint Evaluation







No Match

UPN name constraints should always be entered as two separate entries in the list of name constraints. One entry should include the ampersand character (such as @nwtraders.com); the second entry should replace the ampersand with a period (.), so this entry would be .nwtraders.com. This format allows for the possibility of having a UPN of subdomain.nwtraders.msft.

E-mail and UPN name constraints will appear in either the permitted or excluded name constraints using the following format:

email = @nwtraders.com
UPN = .nwtraders.com
UPN = @nwtraders.com

IP Address Constraints

IP address constraints allow you to specify either specific IP addresses or ranges of IP addresses that a CA can successfully receive certificates from a qualified subordinate CA. The format of the IP addresses in the constraints must follow either RFC 791 (for IPv4 addresses) or RFC 2460.

When a certificate request is received by a qualified subordinate CA, the source IP address in the certificate request is compared to the IP address constraints to determine if the IP address is permitted or excluded by the name constraints.

To specify a range of IP addresses, you must specify both the IP address and associated subnet mask in each constraint. For example, if you wanted to create an IP address constraint for the network, the constraint would be

An IP address constraint will appear in either the permitted or excluded name constraints using the following format:


The first constraint includes all computers in the network. The second constraint is a host-specific constraint that only includes the host with IP address The final constraint is a Classless Internet Domain Routing (CIDR) example that includes all hosts with addresses between and

Issuance Policy

Issuance policies are used to identify the extent to which your organization trusts the identity presented in a certificate issued by another organizations CA hierarchy. For example, an issuance policy may describe that you only trust certificates that were issued during a face-to-face meeting with a network administrator, such as the issuance of a smartcard certificate. Each issuance policy is described by an object identifier. The inclusion of an issuance policy object identifier in an issued certificate indicates that the certificate was issued meeting the issuance requirements associated with the issuance policy object identifier.

Issuance policy is the Microsoft term for Certificate Policies defined in part in RFC 2459 and is contained in the certificatePolicies extension of a certificate.

For a specific certificate template, you can define one or more issuance policy object identifiers that are included in issued certificates. There is a special issuance policy, the All issuance Policies object identifier, commonly reserved for CA certificates, that indicates the issuance policy contains all other issuance policies.

Windows Server 2003 includes four predefined issuance policies:

  • All Issuance ( The all issuance Policy indicates that the issuance policy contains all other issuance policies. Typically, this object identifier is only assigned to CA certificates.

  • Low Assurance ( The low assurance object identifier is used to represent certificates that are issued with no additional security requirements. The x.y.z portion of the object identifier is a randomly generated numeric sequence that is unique for each Windows Server 2003 forest.

  • Medium Assurance ( The medium assurance object identifier is used to represent certificates that may have additional security requirements for issuance. For example, a smartcard certificate that is issued in a face-to-face meeting with a smartcard issuer could be considered a medium assurance certificate and contain the medium assurance object identifier. The x.y.z portion of the object identifier is a randomly generated numeric sequence that is unique for each Windows Server 2003 forest.

  • High Assurance ( The high assurance object identifier is used to represent certificates that are issued with the utmost security. For example, a key recovery agent certificate allows the holder to recover private key material from a Windows Server 2003 Enterprise Edition CA. The issuance of a key recovery agent certificate may require additional background checks and a digital signature from a designated approver. The x.y.z portion of the object identifier is a randomly generated numeric sequence that is unique for each Windows Server 2003 forest.

  • Best Practice Technically, Issuance Policies can be added to any version 2 template that is issued from a Windows Server 2003 certification authority running Enterprise Edition. However, it is a best practice to apply issuance policies in the Policy.inf file for the qualified subordinate CA to ensure consistent policy for the CA. This is to avoid issuing templates with different policies unintentionally.

A root CA automatically implies that all issuance policies are defined. For understanding how policy is evaluated in certificate chains, see the Certificate Status and Revocation white paper at http://www.microsoft.com/technet/security/topics/crypto/tshtcrl.mspx

If your organization has existing object identifiers issued, they may be used for this purpose. In addition, you can create your own object identifiers to represent custom issuance policies. For example, two organizations involved in a purchaser/seller relationship may define custom object identifiers to represent digital signature certificates for specific purchase amounts. For example, object identifiers may be defined for purchase between $100,000 and $500,000, and another object identifier for purchases greater than $500,000. These object identifiers could then be used by applications to recognize whether a person had the appropriate signing authority for a specific volume purchase.

Policies = HighAssurancePolicy, MediumAssurancePolicy, LowAssurancePolicy



Issuance policy extensions are only recognized by Windows XP and Windows Server 2003 clients. If the extension is marked critical, CAPI passes the extensions to the application. It is up to the calling application to understand the extension when it calls with a specific policy provider. The behavior will vary by application. In the case of Outlook on Windows 2000, a critical issuance policy will cause Outlook to generate an error as it does not understand the extension. But on Windows XP, the issuance policy is recognized and does not cause an error.

Policy Mapping

When qualified subordination is configured between two CAs that use issuance policy, the object identifiers between the two organizations must be mapped. Policy mapping establishes what object identifiers in one organization are equivalent to object identifiers defined in a different organization's CA hierarchy. The policy mapping allows the object identifiers generated in certificates in one organization to be recognized in another organization through the creation of cross-certification certificates.

Policy mapping ensures that only authorized object identifiers from a partner organization are allowed in certificates issued by the partner organization. The policy mapping will associate the partner organization's object identifier with an object identifier defined in your organization's PKI hierarchy.

Figure 2 shows how policy mapping is defined in the Policy.inf file when cross certificates are issued to allow certificates to be used between the two CA hierarchies.

Art Image

Figure 2: Policy Mapping

In this figure, the Northwind Traders is configured with an issuance policy named MillionDollar that has been assigned the object identifier This issuance policy is mapped to the issuance policy named BigOrder configured at the Contoso Consulting CA.

If a certificate is issued by the Northwind Traders CA with an issuance policy other than the MillionDollar policy, the certificate is rejected by the Contoso CA because the policy does not map to an approved issuance policy object identifier.

When cross certificates are created to link the two organizations' CA hierarchies, the code snippets shown in the figure must be included in the Policy.inf files used to generate the cross-certification certificate at each CA. The Policy.inf files exist at the issuer CA. The object identifier that is mapped is the object identifier from the subject CA that is the object identifier for the matching issuance policy at the partner organization.

Before you perform the policy mapping, you must configure the issuer CA with the issuance policies and associated object IDs. This is done by configuring the CAPolicy.inf file and either installing the CA or renewing the CA certificate using the configured CAPolicy.inf file with the required object identifiers as shown in the following code sample:

Policies = HighAssurancePolicy, MediumAssurancePolicy, LowAssurancePolicy




In this example, the High, Medium, and Low Assurance issuance policies are defined at the subject CA. The object identifiers can be retrieved from the Certificate Templates console by right-clicking Certificate Templates in the console tree and selecting View Object Identifiers from the pop-up menu.

Appendix B contains a sample CAPolicy.inf file.

The renewal of the CA certificate using the CAPolicy.inf file ensures that the issuance policies are now defined at the CA. At this point, the cross certificates can be generated that perform the policy mapping between the two organizations. The following process is used to perform the qualified subordination between the two CA hierarchies:

  1. Determine the organization with which you want to establish a trust relationship. If more than two organizations exist in the relationship, the trust relationships must be defined in pairs.

  2. Through discussions with the partner organization, establish the equivalence between the assurance levels used by the two organizations involved in the trust relationship.

  3. Exchange the issuance policy object identifiers defined for each assurance level used in both organizations involved in the trust relationship.

  4. Map the issuance policy object identifiers in the separate organizations in the Policy.inf file at each CA and define their policy constraints in the CA certificate request for the qualified subordinate CA you are installing for your organization.

  5. Install the qualified subordinate CA with the policies, policy mappings, and policy constraints you wish to deploy in your organization.

When a user or computer in the organization where the issuing CA exists receives a file signed by a user in the organization where the subject CA exists, the certificate will be chained to the root CA in the issuing CA using the qualified subordination path. If the object identifier for the issuance policy in the certificate maps to the required issuance policy object ID in your organization, the certificate chain is considered valid. If the user or computer in the issuing CAs organization receives a certificate with a non-mapped object identifier, the certificate chain is assigned a lesser value by the validation process and is typically rejected by the application.

Constraining Policy Mapping to Prevent Unexpected Trust

You can further constrain issuance policy by defining parameters that define how the issuance policy defined in the qualified subordination affects other CAs below the qualified subordinate CA. There are two settings that can define the relationship:

  • Require explicit policy Specifies the number of certificates that can exist in the hierarchy below the certificate with the policy constraint extension. For example, if the explicit policy is configured with a value of three, this means that the defined issuance policy must exist for three layers of the hierarchy with the CA, where the qualified subordination is defined being the first level.

  • Inhibit policy mapping Specifies the number of additional certificates that can appear in the path before policy mapping is no longer permitted. An inhibit policy mapping value of three only restricts the policy mapping to three levels of CAs below the qualified subordinate CA.

These settings exist to prevent unexpected trust relationships. For example, Figure 3 shows the same qualified subordination configured previously between Northwind Traders and Contoso Consulting with the addition of a new CA at Fabrikam Corporation.

Art Image

Figure 3: Preventing Unexpected Trust

If qualified subordination is configured between the Contoso Consulting CA and the Fabrikam Corp CA, mapping the BigOrder issuance policy to the SpecialSig issuance policy, it is possible that a certificate issued by the Fabrikam Corp CA could be accepted by the Northwind Traders CA. This is because the object identifier for SpecialSig would be mapped first to the BigOrder object identifier. Then, the BigOrder object identifier would be mapped to the MillionDollar object identifier.

This behavior is prevented by configuring the following Policy Constraint Extensions at the Northwind Traders CA.

RequireExplicitPolicy = 1
InhibitPolicyMapping = 1

By assigning InhibitPolicyMapping a value of one, only certificates issued by the ContosoCA are recognized through the MillionDollar object identifier mapping defined at the Northwind Traders CA. A certificate issued by the Fabrikam Corp CA with the SpecialSig object identifier will fail the InhibitPolicyMapping =1 setting defined at the Northwind Traders CA. This prevents the certificate issued by the Fabrikam Corp CA from being accepted by the Northwind Traders CA.

Policy Qualifiers

You can provide additional information about the Issuance policies implemented at a CA by configuring policy qualifiers. Policy qualifiers provide information directly, or provide links to information, that describe the purpose of the issuance policy. The following code shows both formats of the policy qualifier:

Notice = "Legal policy statement text"
URL = "http://www.example.microsoft.com/policy/isspolicy.asp"

When viewing the certificate in an application, a person can follow the URL and read the description of the issuance policy in a Web browser. If a text message is used as a policy qualifier, the application will display the message.

Best Practice: It is recommended that URLs be implemented for certificate practice statements, rather than to use notice text. This provides several key benefits.

  • It allows modification of the practice statement without having to re-issue the CA certificate.

  • URLs do not dramatically increase the size of the certificate, unlike notice text.

Application Policy

Application policies included in certificates allow applications to determine if a certificate can be used when authenticating a user, encrypting data, or signing a device driver. An application can be coded to only accept certificates that contain specific application policies. When the application receives signed information from a user, the application will review the certificate associated with the private key used to sign the information and verify that the certificate chain has the required object identifier as a valid application policy.

Application policies are similar to the Enhanced Key Usage (EKU) extension in a certificate as both use one or more object identifiers to prescribe how the public key in a certificate must be used. EKU is still supported by Windows XP and the Windows Server 2003 family to provide for PKIs that use this extension, but application policies are a replacement. The following rules are used when combining EKU and Application Policy extensions:

  • If a certificate is presented that contains an EKU extension, but does not contain a separate Application Policy extension, the EKU extension will be treated as an Application Policy extension by Windows XP and Windows Server 2003 clients.

  • If a certificate has an extension containing an application policy and also has an EKU extension, the EKU extension is ignored.

  • If a certificate has an Application Policy extension and an EKU property, the effective policy for the certificate is the common policy between the EKU property object identifiers and the application policy object identifiers.

If issuing certificates that include both Application Policy and EKU extensions, ensure that the two extensions are identical in their assignment of object identifiers so that the two extensions do not conflict with each other. This ensures consistent application of policy, when either Application Policy or EKU extensions are used. This is especially important in issuing cross certificates or in using templates that do not have predefined application policies.

Application policies may be defined in qualified subordination certificates to limit what purposes certificates from a trusted organization can be used for. For example, you can create an application policy that only allows certificates with the Secure Mail object identifier to be recognized if they chain through the qualified subordinate CA.

When application policy is defined for a CA, the object identifiers associated with the application policy are included in all issued certificates.

The All Applications object identifier indicates that the application policy includes all application policies. This application policy is normally reserved for certificates issued to CAs. For understanding how policy is evaluated in certificate chains, see the Certificate Status and Revocation white paper at http://www.microsoft.com/technet/security/topics/crypto/tshtcrl.mspx

The following Application Policy object identifiers are recognized by Windows Server 2003.


  • Server Authentication (

  • Client Authentication (

  • Code Signing (

  • Secure E-mail (

  • IP Security End System (

  • IP Security Tunnel Endpoint (

  • IP Security User (

  • Time Stamping (

  • IP Security IKE Intermediate (

  • All Application Policies (

  • Microsoft Trust List Signing (

  • Qualified Subordination (

  • Key Recovery (

  • Document Signing (

A list of available object identifiers can be viewed in the Certificate Templates console by right-clicking Certificate Templates in the console tree and selecting View Object Identifiers from the pop-up menu. Alternatively, custom application policy object identifiers can be defined and used in custom-developed applications.

To define application policies in a Policy.inf file, the following sections must be created:

Policies = AppEmailPolicy, AppCodeSignPolicy, AppAuthPolicy

OID = ; Secure Email

OID = ; Code Signing

OID = ; Client Authentication

The [ApplicationPolicyStatementExtension] section defines all application policy setting sections that exist in the Policy.inf file. In this case, three application policy sections are defined. For each [AppPolicy] section, the object identifier associated with the application policy is defined.

If a custom application policy object identifier is defined, an [ApplicationPolicyMappingsExtension] section must be defined. This section uses the same format, where the local object identifier is mapped to the object identifier used by the other organization participating in the qualified subordination as shown in the following code sample:

[ApplicationPolicyMappingsExtension] = =
critical = true

As with issuance policies, you can also configure limitations on how deep in the hierarchy explicit policy must exist and whether the defined application policies can be mapped to other application policies. These settings are defined in the [ApplicationPolicyConstraintsExtension] section as follows:

; consists of two optional DWORDs
; They refer to the depth of the CA hierarchy that requires explicit policy
; and inhibits Policy Mapping
RequireExplicitPolicy  = 6
InhibitPolicyMapping = 10
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

© 2015 Microsoft