Name constraints

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Name constraints

You can use qualified subordinate certification authority (CA) name constraints to restrict a qualified subordinate CA's certificate issuance authority to single or multiple namespaces used within your network or public key infrastructure (PKI), such as those used as Active Directory domains. By constraining the qualified subordinate CA's certificate issuance according to one or more namespaces, you will have greater control over which users and computers receive certificates from your qualified subordinate CAs. For more information, see Qualified subordination.

You can use the following naming and addressing formats to constrain the certificate issuance activities of qualified subordinate CAs:

• Directory name (for example, an Active Directory distinguished name)

• DNS domain name

• E-mail name

• User principal name (UPN)

• Universal Resource Identifier (URI)

• Internet Protocol address

The qualified subordinate CA's name constraints define namespaces within which all user names identified in the certificate requests it receives must be located. Name constraints are organized as permitted or excluded name constraints. If the same name formats used as name constraints are present in the certificate requests received by the qualified subordinate CA, it evaluates them according to its permitted and excluded name constraints.

When using qualified subordination in your PKI deployment, you can leverage the well-planned naming and addressing methods used in your network to support the goals of your PKI. In a sense, you can imprint your trust model onto these existing methods, assigning CAs to different domains and configuring them to issue certificates only to users and computers in those domains. When you deploy a qualified subordinate CA to a network domain, you will need to consider the namespaces and addressing methods used by the resources of that domain, and possibly subdomains and other domains, in order to configure the qualified subordinate CA to issue certificates according to your administrative and security goals.

Choosing permitted and excluded name constraints

When choosing a qualified subordinate CA's name constraints, you need to decide on the users that the qualified subordinate CA will receive certificate requests from. Typically, the qualified subordinate CA will be deployed to an Active Directory domain in your network and be responsible for issuing certificates to the users and computers within that domain and possibly its subdomains. The namespaces used by these domains, including Active Directory names, DNS namespaces, and other namespaces, can be used to define the permitted and excluded name constraints of the qualified subordinate CA.

Excluded name constraints are used to exclude a child namespace of a permitted namespace. For example, your qualified subordinate CA may have a permitted name constraint for the DNS namespace .microsoft.com, but you do not want it to issue certificates for the subdomain .betatest.microsoft.com because that subdomain may be experimenting with software that should not be certified within your PKI. An excluded name constraint of .betatest.microsoft.com removes the qualified subordinate CA's ability to issue certificates to users and computers within the namespace .betatest.microsoft.com.

If an excluded name constraint is used to exclude a parent namespace of a permitted name constraint, it will exclude the entire permitted namespace. For example, if a permitted name constraint is .example.microsoft.com and the excluded name constraint is .microsoft.com, then the entire .microsoft.com namespace is excluded.

It is also important to note that excluded namespaces take precedence over permitted namespaces, guaranteeing that the qualified subordinate CA will not issue a certificate to a user within an excluded namespace even if the user is also within a permitted namespace. For example, a user could be within the permitted Active Directory namespace .microsoft.com but also within the excluded DNS namespace .widgets.microsoft.com. In this example, the excluded DNS namespace overrides the permitted Active Directory namespace and the qualified subordinate CA does not fulfill the user's certificate request.

When choosing permitted and excluded name constraints, you should be aware of how the qualified subordinate CA processes certificate requests. When the qualified subordinate CA is comparing the names identified in a certificate request to its name constraints, all names in a certificate request must be within permitted namespaces and none may be within an excluded namespace. For more information on how a qualified subordinate CA using name constraints when processing certificate requests.

Directory name constraints

Active Directory allows you to use distinguished names as name constraints for your qualified subordinate CAs. Distinguished names identify users and resources on the network in Active Directory. This allows you to constrain a qualified subordinate CA to permit or exclude users in the Active Directory using the users' distinguished names. Active Directory also uses distinguished names to create and reference groups of objects in the directory, such as users and computers. The distinguished names of these object groups can also be used as name constraints, allowing you to constrain a qualified subordinate CA to permit and exclude certificate issuance for entire groups in the directory.

The following table describes types of distinguished names that are used as permitted and excluded names.

X.500 directory names can also be used as name constraints. For example, o=cities,st=Redmond,c=US.

DNS name constraints

You can apply the DNS namespaces used by your network for name resolution as name constraints for a qualified subordinate CA. When the qualified subordinate CA receives a certificate request, it will compare the DNS name associated with the computer requesting the certificate to its DNS name constraints and decide whether or not to issue a certificate. The subordinate CA will apply name constraints to all entities within the DNS namespaces specified as DNS name constraints. The DNS domain names accepted by the subordinate CA must follow the standard DNS naming conventions as specified in RFCs 1034 and 1035. The permitted and excluded DNS name constraints are specified using the information file (.inf) that is used to install the qualified subordinate CA.

There are two different ways to specify a DNS name constraint:

• DNS host name.  Specifies a specific DNS host name as a permitted or excluded name constraint, such as host1.example.microsoft.com.

• DNS namespace.  Specifies a DNS name space wherein all DNS host names are permitted or excluded, such as .example.microsoft.com.

To specify that a DNS name constraint should apply to all entities within a DNS namespace and not host names containing part of the name, you must use a period (.) after the leftmost label in the domain name, such as .example.microsoft.com. This period indicates that all subjects with a DNS name ending in the domain .example.microsoft.com are subject to the DNS name constraint, but the host name host1example.microsoft.com is not a match because host1example contains no period separator between host1 and example.

When the subordinate CA compares the DNS name in a certificate request with its name constraints, it performs a string comparison. The string comparison attempts to locate a match within any part of the names. If the qualified subordinate CA's DNS name constraint is example.microsoft.com and the certificate request contains a DNS host name host1example.microsoft.com, the qualified subordinate CA will consider those names as a match. Using the same DNS name constraint (example.microsoft.com), the domain name www.example.microsoft.com is also considered a match.

With DNS name constraints involving domain names, any subdomain of a name constraint satisfies the constraint. If you apply an excluded DNS name constraint for .example.microsoft.com (notice the leftmost period), then names such as www.example.microsoft.com and us.sales.example.microsoft.com are excluded also. Using the same excluded DNS name constraint, names such as it.microsoft.com and accounts.microsoft.com would not be excluded.

The following table demonstrates the two different DNS name constraint evaluation methods used by a qualified subordinate CA.

When creating DNS constraints, you should consider the hierarchies of the DNS namespaces to avoid conflicts between permitted and excluded DNS constraints. If you are permitting and excluding DNS domains for a qualified subordinate CA, the excluded domain names override the permitted names. If you specify the permitted DNS name constraint www.example.microsoft.com and also specify the excluded DNS name constraint .microsoft.com, the permitted name will be cancelled out by the excluded name because the permitted domain name is a subdomain of the excluded domain name.

A qualified subordinate CA's DNS constraints cannot permit DNS 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 subdomain www.example.microsoft.com.

URI constraints

You can specify Uniform Resource Identifiers (URIs) as name constraints for a qualified subordinate CA. URIs are used to identify resources on the Internet using identifiers such as URL, FTP, HTTP, telnet, mailto, news, and gopher. The URI naming conventions supported by the qualified subordinate CA must follow the syntax specified in RFC 2396.

When validating the URI names in a certificate request, the qualified subordinate CA ignores the protocol element in the URI, such as https:// or ftp://, and uses the domain or host names only. For example, if the URI constraint URL=https://.example.microsoft.com is compared to the name ftp://host1.example.microsoft.com, then the comparison is actually between the URI constraint .example.microsoft.com and the name host1.example.microsoft.com.

Similar to DNS constraints, URI constraints may specify a host or domain. When specifying a domain, URI name constraints must begin with a period (.), such as .example.microsoft.com. This URI constraint also applies to all subdomains of the domain constraint, such as abc.example.microsoft.com or xyz.example.microsoft.com. Using the same example, if the URI name in a certificate request does not contain a period to the left of example, then the constraint does not apply. For example, the certificate request URI name example.microsoft.com (notice that there is no beginning period) does not satisfy the name constraint .example.microsoft.com.

When specifying a host, the beginning period is not used, such as host1example.microsoft.com. Without the beginning period, the name constraint is satisfied only when the subject in the certificate request has the leftmost label (host1example). For example, the name constraint example.microsoft.com would be satisfied by the certificate request name host1example.microsoft.com but not by host1.example.microsoft.com.

The most frequent application of URI name constraints is the validation of certificate requests for subjects wanting to access to a secure Web server. For example, if the Web server certificate request has a name of https://www.microsoft.comand the qualified subordinate CA's permitted URI name constraint is URL=https://www.microsoft.com, then this URI constraint would permit the certificate request for the Web server certificate.

E-mail and UPN constraints

Both e-mail and UPN naming conventions follow a similar format that must be followed when you format name constraints. E-mail extensions and UPNs used as name constraints follow the naming conventions specified in RFC 822.

You can specify e-mail and UPN name constraints for an individual subject, such as mikedan@example.microsoft.com, or you can specify constraints for all subjects whose e-mail names or UPNs end in a specific name, such as @example.microsoft.com. Typically, you will specify e-mail or UPN name constraints for all subjects whose e-mail addresses and UPNs end in a specific name.

The difference in specifying these two name constraints is the at sign (@). If the name constraint contains any characters to the left of the @, the qualified subordinate CA regards the name constraint as applying to a single subject. Conversely, if there are no characters to the left of the @, then the qualified subordinate CA regards the name constraint as applying to all subjects whose e-mail addresses or UPNs end in the name constraint.

Note

• If UPN and e-mail permitted name constraints are not defined when defining the permitted name constraints for a qualified subordinate CA certificate request, then the UPN and e-mail permitted name constraints are automatically entered by the issuing CA's policy module when it creates the qualified subordinate CA certificate. The UPN and e-mail permitted name constraints are left unspecified and therefore permit all names. If you want to apply UPN and e-mail permitted name constraints, you must specify the UPN and e-mail permitted constraints when defining the permitted name constraints for a qualified subordinate CA certificate request.

IP address constraints

You can specify IP addresses and IP address ranges as name constraints on a qualified subordinate CA. IP address name constraints follow the formatting conventions specified in RFCs 791 (IPv4) and 1883 (IPv6). The IP addresses that are contained in the certificate requests that are made to a qualified subordinate CA will be compared to the IP addresses in the qualified subordinate CA's name constraints.

Name constraint processing rules

For a certificate request to be successful, all names that are identified in a certificate request must be within permitted name spaces and none may be within an excluded namespace. Each permitted and excluded name constraint is processed separately.

Name constraints are processed by the qualified subordinate CA according to the following rules:

• Constraints apply only when the namespace types specified as name constraints are present in the certificate request.

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

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

• A certificate request containing names that can not be matched with either the permitted or excluded names is considered excluded and is failed.

• Comparison of the name identifying the subject entity with the qualified subordinate CA's name constraints is performed using Unicode. The comparison is not case sensitive.

To find a match, the qualified subordinate CA starts at the rightmost part of the name in the certificate request and compares that name to its list of permitted and excluded name constraints. For example, when the CA receives a certificate request with the DNS name example.microsoft.com it will attempt to find a name constraint match starting with .com, then microsoft.com, and then example.microsoft.com. The exceptions to this are distinguished names (DNs), where the qualified subordinate CA starts from the leftmost name, and IP addresses, where it attempts to find a match starting with the network address and then the host address.

For a certificate request to be accepted by the qualified subordinate CA, each name in the certificate request should match at least one of the qualified subordinate CA's name constraints of the same name type. If there are two permitted distinguished names on the qualified subordinate CA, then the certificate request subject's name should match at least one of these distinguished names. No comparisons are performed between different types of names.

Excluded names take precedence over permitted names. If a permitted DNS name constraint allows users from the DNS domain .example.microsoft.com, but the same name is listed as an excluded name constraint, then users from the DNS domain .example.microsoft.com are excluded and the qualified subordinate CA will fail their certificate requests. This processing rule requires that you pay close attention to the hierarchy of the different name conventions. For example, if a permitted DNS name constraint permits users from the DNS domain .example.microsoft.com, but the parent domain .microsoft.com is listed as an excluded name constraint, then users from the DNS domain .example.microsoft.com are excluded because .example.microsoft.com is a child domain of .microsoft.com.