How CA Certificates Work

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

Certification authority (CA) certificates are certificates that are issued by one CA to another CA. These CA certificates become a part of the certificate trust hierarchy, the certificate path from end-entity certificates to the trusted root CA certificate.

The first CA certificate issued in a public key infrastructure (PKI) is a root certificate, issued by a CA to itself. Once a root CA has been created, it can be used to issue, sign, and validate CA certificates that are issued to other CAs.

Most commonly, root CAs are used to issue CA certificates to subordinate CAs in a PKI hierarchy. These subordinate CAs, in turn, can issue their own CA or end-entity certificates.

However, CA certificates can also be used to establish trust between two or more PKI hierarchies. CA certificate-based trust relationships can connect PKIs in one organization, in two organizations, or spanning multiple organizations.

Because of their critical role in establishing trust between CAs and in the certificate validation process, CA certificates are extremely powerful and critical elements of an organization’s security strategy. For this reason, CA certificates are typically configured with a variety of policy constraints to strictly define their acceptable use and to prevent their unacceptable use.

The information in the CA Certificates Technical Reference is interrelated with the information in the Certificate Services Technical Reference. The information in these two Technical Reference documents should be taken together to gain a full understanding of how Certificate Services can be implemented in Microsoft Windows 2000 and Windows Server 2003 environments.

Ideal Environment for CA Certificates

In a PKI, trust is established when a valid certification path can be traced from an end-entity certificate to an issuing CA and ending with a trusted root certificate. Trust in CA certificates is established by carefully defining and controlling:

• Where and how certificates can be used.

• The applications that can be configured to use certificates.

• Requirements that must be met before a certificate is issued.

• Acceptable formats for subject names in certificates.

• Equivalence between certificate policies in multiple organizations.

For more information about the mechanisms that are available to define and configure CA certificate restrictions, see the following section, “CA Certificate Architecture.”

CA Certificate Architecture

In many ways, the architecture of CA certificates is identical to the architecture of end-entity certificates. However, CA certificates also have some unique features.

CA Certificate Shared Features

All certificates that are issued in Windows Server 2003 and earlier PKIs are structured to comply with standards established by the Public-Key Infrastructure (X.509) Working Group (PKIX) of the Internet Engineering Tasks Force (IETF). The following figure shows the contents of X.509 version 3 certificates, as implemented in Windows Server 2003.

Structure of an X.509 Certificate

X.509 version 3 certificates are the current certificate format in a Windows Server 2003 PKI. Version 3 certificates support the following fields that have been supported since X.509 version 1:

• Subject. Provides the name of the computer, user, network device, or service that the CA issues the certificate to. The subject name is commonly represented by using an X.500 or Lightweight Directory Access Protocol (LDAP) format.

• Serial Number. Provides a unique identifier for each certificate that a CA issues.

• Issuer. Provides a distinguished name for the CA that issued the certificate. The issuer name is commonly represented by using an X.500 or LDAP format. For a root CA, the Issuer and Subject are identical. For all other CA certificates and for end entity certificates, the Subject and Issuer will be different.

• Valid From. Provides the date and time when the certificate becomes valid.

• Valid To. Provides the date and time when the certificate is no longer considered valid.

  Note

  • The date when an application or service evaluates the certificate must fall between the Valid From and Valid To fields of the certificate for the certificate to be considered valid.

• Public Key. Contains the public key of the key pair that is associated with the certificate.

  In addition to the fields defined in X.509 version 1, X.509 version 3 certificates include optional fields or extensions that provide additional functionality and features to the certificate. These extensions are not necessarily included in each certificate that a CA issues:

• Subject alternative name. A subject can be presented in many different formats. For example, if the certificate must include a user’s account name in the format of an LDAP distinguished name, e-mail name, and a user principal name (UPN), you can include the e-mail name or UPN in a certificate by adding a subject alternative name extension that includes these additional name formats. Subject alternative name is only used in end entity certificates, not in CA certificates.

• Basic constraints. This X509 version 3 extension is used to distinguish between end-entity certificates and CA certificates. There are still some PKI clients today that do not recognize basic constraints, which can make it possible for an end-entity to act as a CA. Windows Server 2003 and Windows 2000 operating systems honor basic constraints in accordance with Internet Engineering Task Force (IETF) Request for Comments (RFC) 2459 and will reject CA certificates that do not contain this extension.

• Name constraints. This extension restricts the namespaces that are permitted or excluded by a qualified subordinate CA and its subordinates when issuing certificates.

• Policies. Defines the list of acceptable issuance and application policies for certificate usage. These policies are identified in the certificate by object identifiers (also known as OIDs).

• Policy mapping. Allows a policy from one domain to be mapped onto a policy of another domain.

• Policy constraints. Restricts the subordination levels in a certificate hierarchy to which a policy is applied. These extensions are used in conjunction with issuance and application policies only.

• Application policy. Defines which applications can be used in conjunction with certain certificates.

• Application policymapping. Identifies equivalence between the application policies of two organizations that cross certify by using certificate application policies.

• Cross certificate distribution points. Identifies where cross certificates related to a particular certificate can be obtained and how often the cross certificates at that location are updated.

• CRL distribution points (CDP). Provides one or more URLs where the application or service can retrieve a certificate revocation list (CRL) from. Used when an application or service must determine whether a certificate has been revoked before its validity period has expired.

• Authority Information Access (AIA). Provides one or more URLs from where an application or service can retrieve the issuing CA certificate. Used to validate the certificate of the CA that issued the certificate — also referred to as the parent CA — for revocation and validity.

• Enhanced Key Usage (EKU). Defines which applications can be used in conjunction with certain certificates. Because some implementations of public key infrastructure (PKI) applications might not understand application policies, both application policies and enhanced key usage sections appear in certificates issued by a Microsoft CA

Many of these extensions are configured using the Certification Authority snap-in, Certreq.exe, and Certutil.exe, which are described in the CA Certificate Tools section. They are also discussed in greater detail in the Certificate Services Technical Reference. Other extensions can be configured by creating CAPolicy.inf and Poliy.inf files that must be installed on a CA as part of the CA setup and renewal process. These extensions and their configuration options are discussed in greater detail in the following section.

CA Certificate Extensions

Many people assume that simply accepting the default configuration options presented by the Setup user interface when configuring a new root CA or a subordinate CA automatically provides a degree of security appropriate for their requirements. In fact, few organizations have identical security requirements.

The CA setup routines only present a portion of the security options that can be used to configure new root and subordinate CAs. Many end-entity certificate configuration options can be included in certificate requests. However, many of the most important configuration constraints must exist on the server hosting the CA before the CA is installed or renewed. These CA-based certificate constraints make it possible to address a variety of security needs and concerns. These CA certificate-based constraint extensions are configured using two files, CAPolicy.inf for root CAs and Policy.inf for subordinate CAs.

Note

• Some of these extensions can also be configured using the command line tools Certutil.exe and Certreq.exe. For a complete understanding of the capabilities of Certutil and Certreq, see the Windows Server 2003 Help.

The following section will describe all the options available in these two files so that you can create CAPolicy.inf and Policy.inf files tailored to your specific needs.

Overview of CAPolicy.inf and Policy.inf

A CAPolicy.inf file is a configuration file that defines the extensions, constraints, and other configuration settings that are applied to a root CA certificate and all certificates issued by the root CA. The CAPolicy.inf file must be installed on a host server before the setup routine for the root CA begins. When the security restrictions on a root CA are to be modified, the root certificate must be renewed and an updated CAPolicy.inf file must be installed on the server before the renewal process begins.

A Policy.inf file is a configuration file that defines the constraints that are applied to a subordinate CA certificate and all certificates issued by the subordinate CA. The constraints can include basic constraints, name constraints, application policies, and certificate policies. If a subordinate CA is being used to issue cross certificates connecting two different PKIs, these restrictions serve an essential role in ensuring that the cross certification process does not detract from security.

CAPolicy.inf and Policy.inf files:

• Are created and defined manually by an administrator.

• Are utilized during the creation of root and subordinate CA certificates.

• Are defined on the signing CA where you sign and issue the certificate, not the CA where the request is generated.

There are, however, important differences between CAPolicy.inf and Policy.inf files. For example, CAPolicy.inf files must be placed in the Systemroot folder before installation begins. Policy.inf, on the other hand, can exist in any folder on the requesting computer. In addition, the Policy.inf file can use any file name, as long as the syntax is correct.

CAPolicy.inf and Policy.inf files make it possible to specify and configure a wide variety of CA attributes and options. This makes it very difficult to define a default template that administrators should use for all purposes. Therefore, the following section will describe all the options in order to enable you to create an .inf file tailored to your specific needs.

The following terms are used to describe the .inf file structure:

• A section is an area in the .inf file that covers a logical group of keys. Section names in .inf files are identified by appearing in brackets. Many, but not all, sections in an .inf file are used to configure certificate extensions.

• A key is the name of an entry. It appears to the left of the equal sign.

• A value is the parameter. It appears to the right of the equal sign.

In the following example, [RequestAttributes] is the section, AttributeName1 is the key, and AttributeValue1 is the value:

[RequestAttributes]
AttributeName1 = AttributeValue1

The following table describes the possible sections of CAPolicy.inf and Policy.inf files. It is followed by a more detailed discussion of the configuration options that can be configured using each section of these files.

Section	Explanation	Applies to
[Version]	Identifies the file as an .inf file.	Setup and renewal of root and subordinate CAs
[RequestAttributes]	Defines the certificate template to use when creating new certificates.	Setup and renewal of root and subordinate CAs
[NameConstraintsExtension]	Defines the permitted and excluded namespaces for certificates issued by a subordinate CA.	Setup and renewal of root and subordinate CAs
[PolicyExtension]	Lists user-defined policies	Setup and renewal of root and subordinate CAs
[Policy MappingsExtension]	List of user-defined policy mappings.	Setup and renewal of root and subordinate CAs
[PolicyConstraintsExtension]	Specifies the depth of the CA hierarchy that requires and inhibits policy mapping.	Setup and renewal of root and subordinate CAs
[ApplicationPolicyExtension]	Defines the applications or services a certificate can be used for. An alternate to the Enhanced Key Usage extension	Setup and renewal of root and subordinate CAs
[ApplicationPolicyMappingsExtension]	Lists user-defined application policy mappings.	Setup and renewal of root and subordinate CAs
[ApplicationPolicyConstraintsExtension]	Defines the depth of the CA hierarchy that requires and inhibits policy mapping.	Root and subordinate CAs
[BasicConstraintsExtension]	Sets the maximum subordinate CA path length	Root and subordinate CAs
[CrossCertificateDistributionPointsExtension]	Identifies where cross certificates related to a particular certificate can be obtained and how often that location is updated.	Primarily on subordinate CAs that are used to issue cross certificates.
[EnhancedKeyUsageExtension]	Defines the applications or services a certificate can be used for.	An alternate to the Application Policy extension
[AuthorityInformationAccess]	Specifies the authority information access points .	Initial setup and renewal of a root CA
[CRLDistributionPoints}	Used to specify CRL distribution points (CDPs)	Initial setup and renewal of a root CA
[certsrv_server]	Used to specify renewal key length, the renewal validity period, and the certificate revocation list (CRL) validity period	New CA setup and CA renewal.
[NewRequest]	Used .inf files that serve as templates for new certificate requests.	New CA setup and CA renewal.
[RequestAttribute]	Used in conjunction with [NewRequest] to define additional attributes associated with template-based certificate requests.	New CA setup and CA renewal.

The policy constraint options that you use, and where you choose to implement them, depends on your unique requirements.

Note

• The use of each policy option can be configured as mandatory (Critical = True, Critical=Yes, or Critical=0) or optional (Critical = False, Critical=No, Critical=1). If an extension is marked as critical and the validating computer cannot parse the extension, it must reject the certificate chain. These values are not case sensitive.

Version

The version section identifies the file as an .inf file.

If present, Version must contain the Signature key. The Signature key must be equal to the fixed string “$Windows NT$”

Signature= "$Windows NT$"

Request Attributes

Request attributes are used to pass significant name and value pairs to the policy module of a CA. Any pairs of significant can be passed to a policy module, including pairs that are of use to a customer policy module developed specifically for an organization. For example, request attributes can be used to specify the certificate template to use when creating a new certificate, such as:

CertificateTemplate = CrossCA 

In addition, it can also be used to predefine attributes and values associated with any new certificate, in the format:

AttributeName1 = AttributeValue1
AttributeName2 = AttributeValue2

Name Constraints

Name Constraints is an optional extension that allows organizations to designate which namespaces are either permitted or excluded for certificates issued by a subordinate CA. When you create a new CA, you can define name constraints for the CA by configuring CAPolicy.inf. These name constraints apply to all certificates that are issued in the PKI. Similarly, when you create a Cross Certification Authority certificate, you define name constraints in the Policy.inf file to apply to all certificates issued in the second PKI that will be considered valid in your PKI hierarchy.

Note

• Name constraint validation is performed on the CA, not on the client. However, your clients must run Windows XP or Windows Server 2003 in order to use name constraints.

When a CA that is configured with name constraints receives a request, it compares the names present in the subject and the subject alternate name fields of the request to the configured name constraints, to determine whether the namespace is permitted or excluded.

The following table includes examples of permitted and excluded name constraint settings.

Element	Description	Sample Values
NameConstraints Excluded Name Constraints Extension	Identifies whether permitted name types and excluded name types have been configured.	Include = NameConstraintsPermitted Exclude = NameConstraintsExcluded
[NameConstraintsPermitted]	List of user-defined permitted name formats.	DNS = .corp.contoso.com email = @contoso.com email = @exchange.contoso.com UPN = .corp.contoso.com UPN = @corp.contoso.com DIRECTORYNAME = "DC=com, DC=Contoso, DC=Corp" DIRECTORYNAME = "C=US, S=WA, L=Redmond, O=Contoso" DIRECTORYNAME = "O=Contoso, OU=NorthAmerica"
[NameConstraintsExcluded]	List of user defined excluded name types	DNS = .development.contoso.com email = @development.contoso.com UPN = .development.contoso.com UPN = @development.contoso.com DIRECTORYNAME = "DC=com, DC=Contoso, DC=Development" DIRECTORYNAME = "C=US, O=Contoso, OU=Development"

Before deploying a PKI, organizations need to decide which individual clients and business units are able to enroll for and use certain certificates.

For many organizations, the selected users, computers, and services are members of specific Active Directory domains and subdomains.

Name constraints can be based on any of the following types of name formats:

• X.500 directory name

• DNS domain name

• Universal Resource Identifier (URI)

• E-mail and user principal name

• Internet protocol (IP) address

Additional name constraint forms may be enforced using the Other Name forms, which are identified by name and object identifier that are encoded with UTF8 or ASN.1. Other Names forms can be used to represent names that are outside of the standard name types, such as Rfc822Name, DNS, or X.500 Directory Name. Other Names consist of an object identifier and a binary large object. The most common Other Name is the Universal Principal Name (UPN), which has the constant OID_NT_PRINCIPAL_NAME as the object identifier. The version 2 "Directory 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 globally-unique identifier (GUID) representation of the domain controller as the binary large object. In Windows 2000, only the UPN was present in the other name constraint. However, in Windows Server 2003 operating systems, 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, octet, or ASN.1:

OtherName=1.2.3.4.99.100,{utf8}ssss
OtherName=1.2.3.4.99.101,{octet}ABCD
OtherName=1.2.3.4.99.102,"{asn}BAgAAQIDBAUGBw=="
OtherName=1.3.6.1.4.1.311.25.1

One scenario where this might be useful is when you have cross-forest smartcard logon, wherein the other domain has Windows 2000 domain controllers. In this case, you can provide an additional name constraint as "OtherName=1.3.6.1.4.1.311.25.1" 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.

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 object’s relative distinguished name. The distinguished name can be very specific, where the permitted or excluded relative distinguished name refers to 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. The following table shows some examples of LDAP name constraints and defines what objects the constraints refer to.

Relative Distinguished Name Constraint	Includes
DC=example,DC=contoso,DC=com	All objects in the example.contoso.com domain
CN=Users,DC=example,DC=Contoso,DC=com	All objects in the Users container in the example.contoso.com domain
CN=Brian Komar,CN=Users,DC=contoso,DC=com	The user object Brian Komar in the Users container in the contoso.com domain
OU=Marketing,DC=Contoso,DC=Com	All objects in the Marketing organizational unit (OU) of the Contoso.com domain
CN=Servers,CN=Sites,CN=Configuration,DC=Contoso,DC=Com	All domain controllers in the contoso.com forest
OU=Domain Controllers, DC=Tacoma,DC=Contoso,DC=Com	All domain controllers in the tacoma.contoso.com domain.

The range of characters in the allowed name constraint is defined by the relative distinguished name 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=,email, and so on) support on 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

You can apply the DNS namespaces that your network uses for name resolution as name constraints for a qualified subordinate CA. When the qualified subordinate CA receives a certificate request, it compares the DNS name that is associated with the computer requesting the certificate to its DNS name constraints and decides whether or not to issue a certificate.

DNS name constraints compare any DNS names that are 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 that are 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. For more information about RFCs 1034 and 1035 see the entries in the IETF RFC Database.

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

Note

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

The following table demonstrates the results for submitted DNS names against configured DNS name constraints.

Submitted DNS Name	DNS Name Constraint	Evaluation
www.example.contoso.com	.example.contoso.com	Match
www.south.example.contoso.com	.example.contoso.com	Match
example.contoso.com	.example.contoso.com	No Match
Ourexample.contoso.com	example.contoso.com	No Match
www.example.contoso.com	example.contoso.com	Match

Uniform Resource Identifier Constraints

Uniform Resource Identifiers (URIs) are used to identify resources on the Internet by means of identifiers such as URL, FTP, HTTP, telnet, mailto, news, and gopher. URLs in CAPolicy.inf should use the replaceable parameter syntax that also appears in the Extensions tab of the Certification Authority snap-in. If you don't use the replaceable parameter syntax, then CDP and AIA extensions in renewed CA root certificates might point to the same location that was specified in the previous CA root certificate.

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 only the domain or host names.

The URI naming conventions supported for name constraints must follow the syntax specified in RFC 2396. For more information about name constraints, see RFC 2396 in the IETF RFC Database.

When a qualified subordinate CA validates a URI name, it ignores the protocol element in the URI. For example, if the submitted URI is https://www.example.contoso.com and the URI name constraint is URL=ftp://.example.contoso.com, the actual comparison performed is between the host name www.example.contoso.com and the name constraint .example.contoso.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.contoso.com, then matches are achieved for west.example.contoso.com and for east.example.contoso.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 https://www.contoso.com and the qualified subordinate CAs permitted URI name constraint is URL=https://www.contoso.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 = "https://.contoso.com"

RFC 822, E-mail, and UPN Constraints

You can specify RFC 822, e-mail and UPN name constraints for an individual subject, such as person@example.contoso.com, or you can specify constraints for all subjects whose e-mail names or UPNs end in a specific name, such as @example.contoso.com. Typically, you need to specify e-mail or UPN name constraints for all subjects whose e-mail addresses and UPNs end in a specific name.

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.

The following table shows some examples of RFC 822, e-mail, and UPN constraints and how they are evaluated.

Submitted Address	UPN/E-Mail Constraint	Evaluation
jsmith@nwtraders.com	jsmith@nwtraders.com	Match
bjsmith@nwtraders.com	jsmith@nwtraders.com	Match
jsmith@nwtraders.com	@nwtraders.com	Match
jbsmith@nwtraders.com	bjsmith@nwtraders.com	No Match

Note

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

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 192.168.3.0 network, the constraint would be 192.168.3.0/255.255.255.0.

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

IPADDRESS = 192.168.3.0/255.255.255.0
IPADDRESS = 192.168.2.254/255.255.255.255
IPADDRESS = 172.16.8.0/255.255.248.0

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

Name constraints can be configured to result in the following outcomes:

• Permitted. The certificate request contains all names that are listed as permitted in the CA name constraints extension of the issuer.

• Not permitted. The certificate request contains a name that is not listed as permitted in the name constraints extension of the issuer.

• Excluded. The certificate request contains a name that is listed as excluded in the name constraints extension of the issuer.

When name constraints are added to a CA certificate, the following rules are applied to the subject name and alternate subject name fields:

• Excluded namespaces take precedence over permitted namespaces. A 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 might be within the permitted Active Directory namespace .xyz.com but also within the excluded DNS namespace .uvw.xyz.com. The excluded DNS namespace overrides the permitted Active Directory namespace and the certificate request of the user fails.

• If the name constraints extension exists in a CA certificate, all name constraints must be present in the appropriate format. Any name formats that are not included are considered to be wildcards that match all possibilities. For example, if the DNS name constraint is absent, the entry is treated as DNS="".

  Note

  • You can disable this requirement by modifying the following registry setting: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\ProtectedRoots . For more information, see “CA Certificate Tools and Settings.”

• All name constraints are considered, even if they are not specified. No precedence is applied to the listed name constraints. For this reason, name constraints that are not present are treated as wildcards. For example if you only restrict the DNS name space, the Name Constraints extension sets the remaining name constraints to allow all name spaces.

• Name constraints are applied to the Subject Name extension and any existing Subject Alternate Name extensions. For example, if a user can be identified by a DNS domain name and an alternate e-mail name, name constraints apply to both.

• Name constraints apply to all names contained in a certificate request. 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 certificate request that includes a subject name or subject alternate name that does not match a listed name type is rejected.

• Name constraints are not case sensitive. 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.

• 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 .contoso.com, then its qualified subordinate CA cannot permit the DNS sub-domain .example.contoso.com.

• 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:

  [NameConstraintsExtension]
  Include = NameConstraintsPermitted
  Exclude = NameConstraintsExcluded
  
  [NameConstraintsPermitted]
  DirectoryName = "DC=Contoso, DC=Com"
  email = @contoso.com
  UPN = .contoso.com
  UPN = @contoso.com
  
  [NameConstraintsExcluded]
  

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=Contoso,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.

Note

• 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 issuer’s 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 issuer’s 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.

Note

• 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

Policy

You can use issuance policies to define the extent to which your organization trusts the identity presented in a certificate. For example, you can set an issuance policy stipulating that you only trust certificates that were issued during a face-to-face meeting with a network administrator, such as when a smart card certificate is issued.

Note

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

An object identifier must describe every issuance policy that you define. The inclusion of an issuance policy object identifier in an issued certificate indicates that the certificate was issued in a manner that meets the issuance requirements associated with the issuance policy object identifier.

Note

• Issuance policy is only available on Windows Server 2003 CAs. Windows 2000 does not provide issuance policy.

The following table includes examples of issuance policy settings.

Element	Description	Sample Values
[PolicyStatementExtension]	Lists the policies that have been defined by the organization, and whether they are optional or mandatory	Policies = MediumAssurancePolicy, LowAssurancePolicy, RequireCertificatePolicy
[MediumAssurancePolicy]	Requires that each policy that is included must be identified by an object identifier. In addition, a Notice or URL key can be included for each policy.	OID = 1.3.6.1.4.1.311.21.8.1308480216.1095248452.3429159812.3095816201.1472143667.3857372322 Notice = "Legal policy statement text"
[LowAssurancePolicy]	Requires that each policy that is included must be identified by an object identifier. In addition, a Notice or URL key can be included for each policy.	OID = 1.3.6.1.4.1.311.21.8.1308480216.1095248452.3429159812.3095816201.1585704526.3613270325 URL = "https://http.site.com/some where/default.asp" URL = "ftp://ftp.site.com/some where else/default.asp" Notice = "Limited use policy statement text." URL = "ldap://ldap.site.com/some where else again/default.asp"
[RequireCertificatePolicy]	Requires that each policy that is included must be identified by an object identifier. In addition, a Notice or URL key can be included for each policy.	OID = 1.3.6.1.4.1.311.21.15 URL = https://extra.site.com/Extra Policy/default.asp [oidpolicy] OID = 1.3.6.1.4.1.311.21.55
[LegalPolicy]	Requires that an organization’s legal policy documents must be identified with at least one object identifier, and zero or more Notice and URL keys. Legal policy statements usually need to be identified in all certificates an organization issues or accepts.	OID = 1.3.6.1.4.1.311.21.43 Notice = "Legal policy statement text"
[LimitedUsePolicy]	Used by many organizations to limit the allowed uses of certificates they issue or accept. These usage limitations can be identified with at least one object identifier and 0 or more Notice and URL keys.	OID = 1.3.6.1.4.1.311.21.47 URL = "https://http.site.com/some where/default.asp" URL = "ftp://ftp.site.com/some where else/default.asp" Notice = "Limited use policy statement text." URL = "ldap://ldap.site.com/some where else again/default.asp"
[ExtraPolicy]	Used by organizations to define additional policies beyond legal and use restrictions. These can also be defined with at least one object identifier and 0 or more Notice and URL keys.	OID = 1.3.6.1.4.1.311.21.53 URL = https://extra.site.com/Extra Policy/default.asp

You can use a specific certificate template to define one or more issuance policy object identifiers that need to be included in any certificates issued. Windows Server 2003 includes four predefined issuance policies:

• All Issuance (2.5.29.32.0). The all issuance policy indicates that the issuance policy contains all other issuance policies. Typically, this object identifier is only assigned to CA certificates. A root CA automatically implies that all issuance policies are defined.

  Note

  • The x.y.z portion of the object identifier in these examples is a randomly-generated numeric sequence that is unique for each Windows Server 2003 forest.

• **Low Assurance (1.3.6.1.4.1.311.21.8.***x.y.z.*1.400). The low assurance object identifier represents certificates that are issued with no additional security requirements.

• Medium Assurance (1.3.6.1.4.1.311.21.8*.x.y.z.*1.401). The medium assurance object identifier represents certificates that have additional security requirements for issuance. For example, a smart card certificate that is issued in a face to face meeting with a smart card issuer might be considered a medium assurance certificate and contain the medium assurance object identifier.

• High Assurance (1.3.6.1.4.1.311.21.8*.x.y.z.*1.402). The high assurance object identifier represents certificates that are issued with the highest security. For example, the issuance of a key recovery agent certificate might require additional background checks and a digital signature from a designated approver, because a person holding this certificate can recover private key material from a Windows Server 2003, Enterprise Edition CA.

In addition, you can create your own object identifiers to represent custom issuance policies. For example, two organizations that are involved in a purchaser and seller relationship can define custom object identifiers to represent digital signature certificates for specific purchase amounts. In such a case, an object identifier can be defined for purchase between $100,000 and $500,000 and another object identifier can be defined for purchases greater than $500,000. Applications can then use these object identifiers to recognize whether a person had the appropriate signing authority for a specific volume purchase.

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:

[LegalPolicy]
OID = 1.3.6.1.4.1.311.21.43
Notice = "Legal policy statement text"
URL = "https://www.example.contoso.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.

It is recommended that URLs rather than notice text be implemented for certificate practice statements. This allows practice statements to be modified without having to re-issue the CA certificate. In addition, URLs do not dramatically increase the size of certificates compared to notice text.

Policy Mappings

You can use policy mappings to explicitly state the comparability of certificate policies in two PKI hierarchies. Policy mapping is commonly used to cross-certify two PKIs, such as between two organizations.

In many cases, the administrators of two PKIs define their own policies and object identifiers. In some cases, these policies are identical, but in most cases there are small differences between them. For example, one organization might stipulate that one physical form of identification is sufficient to grant a certificate request, while a second organization requires three forms of physical identification to grant a similar request. In these cases, you need to negotiate with the administrators of the other PKI to define terms of equivalence before the cross-certified relationship can be established. This is called policy mapping.

Policy mapping enables interoperability between two organizations that apply similar issuance and application policies, but have deployed different object identifiers.

The following table includes examples of policy mappings.

Element	Description	Sample Values
[PolicyMappingsExtension]	Each entry maps one foreign policy object identifier to a local policy object identifier.	1.3.6.1.4.1.311.21.53 = 1.2.3.4.87 1.3.6.1.4.1.311.21.54 = 1.2.3.4.89

The first object identifier is foreign, the second is local. If the policy object identifier (for example, 1.2.3.4) of one company represents a specific function, and the policy object identifier of another company (for example, 11.22.33.44) represents the same function, they can be mapped, so that 11.22.33.44 and 1.2.3.4 are interchangeable.

The qualified subordinate CA that contains this mapping is called the issuer CA and the subordinate CA whose policies have been mapped is called the subject CA. In mapping some or all of the policies of the subject CA to the policies of the issuer, the issuer CA effectively subordinates the subject CA. The result of this mapping is that users and computers in the issuer CA trust hierarchy can use their own certification paths to validate certificates from users and computers in the subject CA trust hierarchy. The separate trust hierarchy can be within the same intranet or in separate PKI environments over an extranet.

Policy mappings can be applied by:

• Identifying the trust hierarchies that are to be linked with a trust relationship.

• Establishing equivalence in the assurance levels that are used by the two trust hierarchies involved in the trust relationship.

• Obtaining the issuance and application policy object identifiers used in both trust hierarchies involved in the trust relationship.

• Mapping the issuance and application policy object identifiers in the separate trust hierarchies, and defining policy constraints in the CA certificate request for the qualified subordinate CA that you are installing in your trust hierarchy.

• Installing the qualified subordinate CA with the policies, policy mappings, and policy constraints in your trust hierarchy.

Policy Constraints

The policy constraints extension specifies the depth of the CA hierarchy that requires and inhibits policy mapping. Require policy constraints define the levels of a PKI hierarchy where foreign certificates with mapped policy can be used. Inhibit policy constraints specify the boundaries beyond which these certificates cannot be used.

The following table includes examples of policy constraints settings.

Element	Description	Sample Values
[PolicyConstraintsExtension]	Specifies the depth of the CA hierarchy that requires policy mapping	RequirePolicyMapping = 3
	Specifies the depth of the CA hierarchy that inhibits policy mapping.	InhibitPolicyConstraints = 5

You can refine policy mapping by setting parameters for how the issuance policy defined in qualified subordination affects other CAs below the qualified subordinate CA. These parameters can help to limit unplanned trust relationships. The following two settings define this relationship:

• Require explicit policy. Specifies the number of certificates that can exist in the hierarchy below a certificate before an explicit policy must exist. For example, if the explicit policy is configured with a setting of 3, the defined issuance policy must exist for three layers of the hierarchy. The CA on which the qualified subordination is defined is 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. For example, an inhibit policy mapping value of 3 restricts the policy mapping to only three levels of CAs below the qualified subordinate CA.

Application Policy

Certificates provide important information that is not specific to an application. However, you might need to define which applications can be used in conjunction with certain certificates. Application policy allows you to ensure that certificates are only used with the applications that you specify.

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.

Each application policy has one object identifier, and can include Notice and URL keys, as in the examples in the following table.

Element	Description	Sample Values
[ApplicationPolicyStatementExtension]	Specifies the application policies that apply to the specified certificates.	Policies = AppLegalPolicy, AppLimitedUsePolicy, AppExtraPolicy, AppOIDPolicy
[AppLegalPolicy]	Specifies specific legal requirements and implications of the certificate. The notice spells out these legal requirements and implications in terms understandable by the user.	OID = 1.3.6.1.4.1.311.21.54 Notice = "Application Legal policy statement text"
[AppLimitedUsePolicy]	Many certificates will be issued for restricted uses, such as for signing purchase orders up to a certain value. The sample URLs would provide explanatory text for these usage restrictions.	OID = 1.3.6.1.4.1.311.21.58 URL = "https://http.contoso.com/application some where/default.asp" URL = "ftp://ftp.contoso.com/application some where else/default.asp" Notice = "Application Limited use policy statement text." URL = "ldap://ldap.contoso.com/application some where else again/default.asp"
[AppExtraPolicy]	Many certificates will be issued for restricted uses, such as for signing purchase orders up to a certain value. The sample URLs would provide explanatory text for these usage restrictions.	OID = 1.3.6.1.4.1.311.21.64 URL = https://extra.contoso.com/Application Extra Policy/default.asp
[Appoidpolicy]	An optional format to use for an application policy.	OID = 1.3.6.1.4.1.311.21.66

Application policy is Microsoft-specific and is treated much like Extended Key Usage. Because some implementations of PKI applications might not understand application policies, both application policies and enhanced key usage sections appear in certificates issued by a Microsoft CA.

If a certificate has an extension containing an application policy and also has an EKU extension, the EKU extension is ignored. If, however, a certificate has only an EKU extension, the EKU extension is treated like an application policy extension. 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.

Note

• You can view all defined application policy object identifiers in the Certificate Templates console. To do this, in the console tree, right-click Certificate Templates and click View Object Identifiers.

After you define the object identifiers for your organization’s certificate policies, obtain the complementary object identifiers from the partner organization. Obtain the partner’s object identifiers because the object identifiers differ between the two organizations.

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

• Server Authentication (1.3.6.1.5.5.7.3.1)

• Client Authentication (1.3.6.1.5.5.7.3.2)

• Code Signing (1.3.6.1.5.5.7.3.3)

• Secure E-mail (1.3.6.1.5.5.7.3.4)

• IP Security End System (1.3.6.1.5.5.7.3.5)

• IP Security Tunnel Endpoint (1.3.6.1.5.5.7.3.6)

• IP Security User (1.3.6.1.5.5.7.3.7)

• Time Stamping (1.3.6.1.5.5.7.3.8)

• IP Security IKE Intermediate (1.3.6.1.5.5.8.2.2)

• All Application Policies (1.3.6.1.4.1.311.10.12.1)

• Microsoft Trust List Signing (1.3.6.1.4.1.311.10.3.1)

• Qualified Subordination (1.3.6.1.4.1.311.10.3.10)

• Key Recovery (1.3.6.1.4.1.311.10.3.11)

• Document Signing (1.3.6.1.4.1.311.10.3.12)

Note

• A list of available object identifiers can be viewed in the Certificate Templates console. To do this, in the console tree, right-click Certificate Templates and click View Object Identifiers. Alternatively, custom application policy object identifiers can be defined and used in custom-developed applications.

Application Policy Mappings

When qualified subordination is configured between two CAs that use certificate application policies, you must map the object identifiers between the two organizations in the policy file that you create. Application policy mapping ensures that only authorized application policy object identifiers from a partner organization are allowed in certificates that the partner organization issues. Application policy mapping associates the partner organization’s application policy object identifiers with application policy object identifiers that are defined in your organization’s PKI.

The following example shows how application policy mappings are configured in CAPolicy.inf or a Policy.inf file. Each entry maps one foreign application policy object identifier to one local application policy object identifier. The first object identifier is foreign, the second is local.

Element	Description	Sample Values
[ApplicationPolicyMappingsExtension]	List of user defined application policy mappings.	1.3.6.1.4.1.311.21.64 = 1.2.3.4.98 1.3.6.1.4.1.311.21.65 = 1.2.3.4.100

Application Policy Constraints

The application policy constraints extension specifies the depth of the CA hierarchy that requires and inhibits policy mapping. Require application policy constraints define the levels of a PKI hierarchy where foreign certificates with mapped policy can be used. Inhibit application policy constraints specify the boundaries beyond which these certificates cannot be used.

Policy qualifiers are typically URLs that provide information directly or provide links to information that describe the purpose of the certificate policy. The following table shows examples of application policy constraints:

Element	Description	Sample Values
[ApplicationPolicyConstraintsExtension]	Defines the depth of the CA hierarchy that requires application policy mapping	RequirePolicyMapping = 6
	Defines the depth of the CA hierarchy that inhibits policy constraints	InhibitPolicyConstraints = 10

Basic Constraints

A basic constraint defines which CAs your organization trusts in a partner’s CA hierarchy by limiting the path length for a certificate chain.

The following table shows examples of basic constraints:

Element	Description	Sample Values
[BasicConstraintsExtension]	Defines the path limits for validating certificate chains.	PathLength = 3
[EnhancedKeyUsageExtension]		OID = 1.3.6.1.5.5.7.3.4 Secure E-mail OID = 1.3.6.1.5.5.7.3.1 Server Authentication

Basic constraints allow an application to determine whether a certificate is a CA certificate, which can then be used by the certificate chain engine to build certification paths, or an end-certificate, which cannot.

You can also use basic constraints to limit the maximum number of CA certificates that can be included in a CA path. For example, setting a path length of 0 in the basic constraints section of the CAPolicy.inf file allows only certificates issued by that specific CA to be included in the CA path. A path length of 2 allows only a total of three CA certificates in a certification path. In the latter case, any certification paths that include more than three CAs are discarded.

Use basic constraints if you do not want to trust additional CAs that are created lower in the CA hierarchy of your organization. You can also use basic constraints in cross-certified relationships if you trust your business partner and the certificates from all their existing CAs, but you do not want to trust certificates from any additional CAs that they authorize.

Cross Certificate Distribution Points

The cross certificate distribution point (CCDP) extension identifies where cross certificates related to a particular certificate can be obtained and how often that location is updated. Windows XP and later operating systems use this extension for the discovery of cross-certificates that might be used during the path discovery and chain building process.

Note

• The CCDP extension is unique to Windows CAs.

The following table shows examples of configuration options for cross certificate distribution point extensions.

Element	Description	Sample Values
CrossCertDistPoints	One or more locations where the cross certificates related to a particular certificate can be found.	URL = https://%1/Public/My CA.crt URL = ftp://contoso.com/Public/MyCA.crt URL = file://\\%1\Public\My CA.crt
syncDeltaTime	An optional integer field that specifies the delta between when this location will be refreshed. If syncDeltaTime is present, CrossCertDistPointNames must also be present.	SyncDeltaTime = 24

This extension should be non-critical, but support for this extension by CAs and applications is recommended.

Enhanced Key Usage

Application policies are sometimes called extended key usage or enhanced key usage. Because some implementations of PKI applications might not understand application policies, both application policies and enhanced key usage sections appear in certificates issued by a Microsoft CA.

If a certificate has an extension containing an application policy and also has an EKU extension, the EKU extension is ignored. If, however, a certificate has only an EKU extension, the EKU extension is treated like an application policy extension. 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.

This section can be used during CA setup or CA certificate renewal, but is only used if you are setting up a root CA or renewing a root CA certificate. The Enhanced Key Usage extension for a subordinate CA is determined by the CA which issued the subordinate CA's certificate. An example of this section is:

[EnhancedKeyUsage]
OID=1.2.3.4.5
OID=1.2.3.4.6

Authority Information Access

You can specify the authority information access points in CAPolicy.inf.   This section is only used if you are setting up a root CA or renewing a root CA certificate. Subordinate CA authority information access extensions are determined by the CA which issued the subordinate CA's certificate. This section can be used during CA setup or CA certificate renewal.

Multiple URLs are supported. HTTP, FILE, FTP, and LDAP URLs are supported. If no URLs are specified (in other words, if the Authority Information Access section is empty), the default Authority Information Access extension will be suppressed.

The syntax is: [AuthorityInformationAccess]URL="https://CompanyWebSite/Public/myCA.crl"

CRL Distribution Points

You can specify CRL distribution points (CDPs) in CAPolicy.inf. Any CDP in CAPolicy.inf will take precedence for certificate verifiers over the CDP's specified in the CA policy module.

Some additional notes about the CRL section:

• Multiple URLs are supported.

• HTTP, file, FTP, and LDAP URLs are supported.

• This section can be used during CA setup or CA certificate renewal.

• This section is only used if you are setting up a root CA or renewing a root CA certificate. Subordinate CA CRL distribution point extensions are determined by the CA that issued the subordinate CA's certificate.

• URLs with spaces must be surrounded by quotes.

• If no URLs are specified (in other words, if the CRL Distribution Point section is empty), the default CRL Distribution Point extension will be suppressed.

If you want to specify the CDP using CAPolicy.inf, a sample of the syntax is:

[CRLDistributionPoint]
URL="https://CompanyWebSite/Public/myCA.crl"

Replacement tokens are used to retain the configuration of distribution points flexible. You can use replacement tokens in the CAPolicy.inf file and in the Certification Authority MMC in CA Extensions.

A replacement token consists of the percent sign and a number. This behavior occurs if you use replacement tokens in the Certificate Services MMC or if you use them in a Certutil.exe command. If replacement tokens are used in a batch file, and you use the percent sign (%), you must use another escape sign when needed, because the Windows shell typically interprets a percent sign as a command-line parameter.

The mapping of replacement tokens is different in versions of Windows later than Windows 2000 Server. You can use the following tokens for CRLDistributionPoint, AuthorityInformationAccess, and CrossCertificateDistributionPointsExtension URLs. The following table describes the replacement token options for Windows 2000 and Windows Server 2003.

Token name	Description	Windows 2000 map value	Windows Server 2003 map value
ServerDNSName	The DNS name of the CA server	%1	%1
ServerShortName	The NetBIOS name of the CA server	%2	%2
CaName	The name of the CA	%3	%3
Cert_Suffix	The renewal extension of the CA	%4	Not applicable.
CertificateName		Not applicable.	%4
Domain_Name	The location of the domain root in Active Directory	%5	N/A
(Not used)		N/A	%5
ConfigurationContainer	The location of the configuration container in Active Directory	%6	%6
CATruncatedName	The "sanitized" name of the CA, 32 characters with a hash on the end	%7	%7
CRLNameSuffix	The renewal extension for the CRL	%8	%8
DeltaCRLAllowed			%9
CDPObjectClass			%10
CAObjectClass			%11

The Certification Server setup process replaces all %number% sequences with the appropriate value.

certsrv_server

Another section of CApolicy.inf that is not used frequently is [certsrv_server], which is used to specify renewal key length, the renewal validity period, and the certificate revocation list (CRL) validity period for a CA that is being renewed or installed.

Options that can be configured in this section include:

• RenewalKeyLength, which sets key size for renewal only. This is only used when CA renewal generates new keys.

• RenewalValidityPeriod and RenewalValidityPeriodUnits, which establish the lifetime of new root CA certificate when renewing the old CA certificate.

• CRLPeriod and CRLPeriodUnits, which establish the validity period for the full CRL, while CRLDeltaPeriod and CRLDeltaPeriodUnits establish the validity period for the delta CRL.

• RenewalKeyLength, RenewalValidityPeriod and RenewalValidityPeriodUnits, which are only processed when the CA is being renewed.

• LoadDefaultTemplates, which is not processed when the CA is a subordinate CA.

An example would be:

[certsrv_server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5
CRLPeriod=Days
CRLPeriodUnits=2
CRLDeltaPeriod=Hours
CRLDeltaPeriodUnits=4

NewRequest

The [NewRequest] section is mandatory for an .inf file that acts as a template for a new certificate request. If this section is missing, the following error message is displayed:

INF file line not found 0xe0000102 (INF: -536870654)

This section requires at least one key with a value. If this section is empty and has no keys, the following error message is displayed:

Incorrect function. 0x1 (WIN32: 1)

The following options can be associated with a new certificate request.

EncipherOnly

This parameter has an impact on the functional capabilities of the public-private key pair. If the value is set to True, the key can exclusively be used for encryption. If this is set to False, the key can be used for encryption and other purposes. This parameter refers only to the key type in CryptoAPI and has only an indirect relationship to the Key Usage extension that might be included in an issued x.509 certificate. The default value of the certificate enrollment control is set to False. This setting only affects AT_KEYEXCHANGE key types and then correspondingly limits the key usage to key encryption or data encryption. The digital signature and non-repudiation key usages will be disallowed.

Summary Information	Details
Syntax	EncipherOnly={Boolean}
Values	True or False
Default value	False
Sample	EncipherOnly = True
Supported with CA type	Windows 2000 Windows Server 2003
Can be manipulated in a pending request	Yes (through the key usage extension)

Exportable

This parameter is ignored when the UseExistingKeySet key is set to True because you can set the exportable flag only when a new key is created. You cannot change this flag for an existing key. If this attribute is set to True, the private key can be exported together with the certificate. To ensure a high level of security, private keys should not be exportable, however in some cases it might be required to make the private key exportable if several computers or users must share the same private key. For example, a Web-server that runs Secure Sockets Layer (SSL) and is published with Microsoft Internet Security and Acceleration Server to the Internet requires a certificate with an exportable key, because the certificate and key must be installed on the Web-server and the computer running ISA Server as well. Also, if you want to manage and back up the keys, they must be exportable to provide for this functionality.

This setting correlates with the template configuration if a Windows Server 2003 enterprise CA is used. A certificate template administrator can explicitly define if private keys should be exportable or not. The template setting for exportable has no effect on the exportability properties of a key generated through the certreq.exe -new command.

Summary Information	Details
Syntax	Exportable = {Boolean}
Values	True or False
Default value	False
Sample	Exportable = True
Supported with CA type	Windows 2000 Windows Server 2003
Can be manipulated in a pending request	No

KeyContainer

It is not recommended to set this parameter for new requests where new key material is generated. The key container is automatically generated and maintained by the system.

For requests where the existing key-material should be used, this value can be set to the key-container name of the existing key.

If the UseExistingKeySet key is set to True, the key container must be set explicitly in the .inf file or in the renewal certificate.

Summary Information	Details
Syntax	KeyContainer = {Key_containerName}
Values	Random string value (GUID)
Default value	None
Sample	KeyContainer = {C347BD28-7F69-4090-AA16-BC58CF4D749C}
Supported with CA type	Windows 2000 Windows Server 2003
Can be manipulated in a pending request	No

KeyLength

The key length defines the length of the public and private key. The key length has an impact on the security-level of the certificate. Greater key length provides usually a higher security level, however some applications might have limitations regarding the key length.

Summary Information	Details
Syntax	KeyLength = {integer}
Values	Any valid key length that is supported by the cryptographic service provider
Default value	1024 (depends on CSP)
Sample	KeyLength=2048
Supported with CA type	Windows 2000 Windows Server 2003
Can be manipulated in a pending request	No

KeySpec

KeySpec determines if the key can be used for signatures, for exchange (encryption) or for both. If the KeySpec is set to a value of 2, the EncipherOnly key is ignored.

Summary Information	Details
Syntax	KeySpec = {integer}
Values	AT_EXCHANGE: 1 AT_SIGNATURE: 2
Default value	2
Sample	KeySpec=1
Supported with CA type	Windows 2000 Windows Server 2003
Can be manipulated in a pending request	No

KeyUsage

Key usage defines what the certificate key should be used for. The value is a bit field that is composed of the key usage flags as they are defined in the Windows Platform Software Development Kit.

Note

• The key usage extension has an indirect dependency with the extended key usage extension, so these two extensions need to align. For example, if you specify “Encrypting File System” as the extended key usage, you should also specify “Key Encipherment” as the key usage.

To combine multiple key usages, summarize the values of the individual key usages by performing hexadecimal arithmetic. The default key usage is set to Digital Signature (0x80) and Non-Repudiation (0x40). The hexadecimal sum of 0x80 and 0x40 results in 0xC0.

The key usage parameter is primarily useful if certificate requests are submitted to stand-alone CAs. Only enterprise CAs have certificate key usages predefined through certificate templates. The key usage extension is set to Critical by default.

Summary Information	Details
Syntax	KeyUsage = {hexadecimal_value}
Values	CERT_DIGITAL_SIGNATURE_KEY_USAGE:    0x80 CERT_NON_REPUDIATION_KEY_USAGE:    0x40 CERT_KEY_ENCIPHERMENT_KEY_USAGE:    0x20 CERT_DATA_ENCIPHERMENT_KEY_USAGE:    0x10 CERT_KEY_AGREEMENT_KEY_USAGE:    0x08 CERT_KEY_CERT_SIGN_KEY_USAGE:    0x04 CERT_OFFLINE_CRL_SIGN_KEY_USAGE:0x02 CERT_CRL_SIGN_KEY_USAGE:    0x02 CERT_ENCIPHER_ONLY_KEY_USAGE:    0x01
Default value	0xC0    for    AT_SIGNATURE    (default) For    AT_KEYEXCHANGE,    EncipherOnly = TRUE:    0x30 For    AT_KEYEXCHANGE,    EncipherOnly = FALSE:    0xf0
Sample	KeyUsage=0xa0
Supported with CA type	Windows 2000 Windows Server 2003
Can be manipulated in a pending request	Yes

MachineKeySet

This key is important when you need to create certificates that are owned by the computer and not a user. The key-material that is generated is maintained in the security context of the security principal (user or computer account) that has created the request. When a CA administrator creates a certificate request on behalf of a computer, the key-material must be created in the machines security context and not the administrators’ security context. Otherwise, the computer cannot access its private key, since it would be in the administrator’s security context.

You must set this key to True, if you are creating requests for domain controllers, Web servers or any other service that runs in the computer’s security context.

Summary Information	Details
Syntax	MachineKeySet = {Boolean}
Values	True or False
Default value	FALSE
Sample	MachineKeySet = True
Supported with CA type	Windows 2000 Windows Server 2003
Can be manipulated in a pending request	No

PrivateKeyArchive

The PrivateKeyArchive setting works only if the corresponding RequestType is set to CMC**,** because only the CMC request format allows for securely transferring the requester’s private key to the CA for key archival. Only the Windows Server 2003 enterprise CA supports private key archival. The Windows Server 2003 enterprise CA must be online and accessible to retrieve the CA encryption certificate directly during this process.

Summary Information	Details
Syntax	PrivateKeyArchive = {Boolean}
Values	True or False
Default value	False
Sample	PrivateKeyArchive = True
Supported with CA type	Windows Server 2003
Can be manipulated in a pending request	No

ProviderName

The provider name is the display name of the certificate service provider (CSP). If you do not know the provider name of the CSP you are using, run certutil –csplist at a command line prompt. The command displays the names of all CSPs that are available on the local system.

Summary Information	Details
Syntax	ProviderName = {CSP_stringname}
Values	The descriptive name of the certificate service provider
Default value	Microsoft Strong Cryptographic Provider
Sample	ProviderName=Microsoft RSA SChannel Cryptographic Provider
Supported with CA type	Windows 2000 Windows Server 2003
Can be manipulated in a pending request	No

ProviderType

The provider type is used to select specific providers based on specific algorithm capability such as “RSA Full”. If you do not know the provider type of the CSP you are using, type certutil –csplist at a command-line prompt. The command displays the provider type of all CSPs that are available on the local system.

Summary Information	Details
Syntax	ProviderType = {integer}
Values	The number that describes the provider type
Default value	12
Sample	ProviderType=13
Supported with CA type	Windows 2000 Windows Server 2003
Can be manipulated in a pending request	No

RenewalCert

If a CA administrator needs to renew a certificate that exists on the system where the certificate request is generated, the CA administrator must specify its certificate hash as a value for this key. You can only renew certificates that have not expired. Certificates that have expired cannot be renewed and must be replaced with a new certificate.

Note

• If you do not know the certificate hash, use the Certificates MMC Snap-In and look at the certificate that should be renewed. Open the certificate properties and see the Thumbprint attribute of the certificate. Certificate renewal requires either a PKCS#7 or a CMC request format.

Summary Information	Details
Syntax	RenewalCert={CertificateHash}
Values	The certificate hash of any certificate that is available at the computer where the certificate request is created
Default value	Not applicable.
Sample	RenewalCert=4EDF274BD2919C6E9EC6A522F0F3B153E9B1582D (You must use double quotes if white space is used between pairs of hexadecimal values)
Supported with CA type	Windows 2000 Windows Server 2003
Can be manipulated in a pending request	No

Requestername

The requester name can be specified for certificate requests if the RequestType is set to PKCS7 or CMC. If the RequestType is set to PKCS10, this key will be ignored. The Requestername can only be set as part of the request. CA administrators cannot manipulate the Requestername in a pending request.

Summary Information	Details
Syntax	Requestername=samAccountName in Active Directory
Values	The domain name of the user who requested the certificate.
Default value	Not applicable.
Sample	Requestername = “DOMAINNAME\username”
Supported with CA type	Windows 2000 (with a PKCS#7 request type only) Windows Server 2003
Can be manipulated in a pending request	No

RequestType

The RequestType determines the standard that is used to generate and send the certificate request.

Summary Information	Details
Syntax	RequestType={string value}
Values	CMC PKCS10 PKCS10- PKCS7
Default value	PKCS10
Sample	RequestType = CMC
Supported with CA type	Windows 2000 (except CMC request type) Windows Server 2003
Can be manipulated in a pending request	No

Silent

By default, the Silent option gives the CSP access to the interactive user desktop of the CA administrator and request information such as a smartcard personal identification number (PIN) from the CA administrator. If this key is set to True, the CSP must not interact with the desktop and will be blocked from displaying any user interface to the CA administrator.

Summary Information	Details
Syntax	Silent={Boolean}
Values	True or False
Default value	False
Sample	Silent = True
Supported with CA type	Windows 2000 Windows Server 2003
Can be manipulated in a pending request	No

Subject

Several applications rely on the subject information in a certificate. Thus, it is recommended to specify a value for this key. If the subject is not set here, you should include a subject name as part of the Subject Alternate Name certificate extension.

Summary Information	Details
Syntax	Subject={String}
Values	Relative distinguished name string values
Default value	Not applicable.
Sample	Subject=CN=computer1.contoso.com Subject=CN=John Smith,CN=Users,DC=Contoso,DC=com x
Supported with CA type	Windows 2000 Windows Server 2003
Can be manipulated in a pending request	Yes

UseExistingKeySet

The UseExistingKeySet parameter is used to specify that an existing key pair should be used in building a certificate request. If this key is set to True, you must also specify a value for the RenewalCert key or the KeyContainer name. You must not set the key to Exportable because you cannot change the properties of an existing key. In this case, no key-material is generated when the certificate request is built.

Summary Information	Details
Syntax	UseExistingKeySet={Boolean}
Values	True or False
Default value	False
Sample	UseExistingKeySet=True
Supported with CA type	Windows 2000 Windows Server 2003
Can be manipulated in a pending request	No

UserProtected

If this key is set to True, a password must be set and typed in whenever a private key is used. The CA administrator can choose to protect the key with a password when the key is generated or choose to display a password dialog box only when the key is used within an application.

Summary Information	Details
Syntax	UserProtected={Boolean}
Values	True or False
Default value	False
Sample	UserProtected=True
Supported with CA type	Windows 2000 Windows Server 2003
Can be manipulated in a pending request	No

[RequestAttributes]

This section is used in conjunction with the New Request attribute to define additional attributes associated with the certificate request. All keys from this section can be specified as part of the certreq -submit -attrib command. For example, instead of specifying the CertificateTemplate in the .inf instruction file, a CA administrator could enter the following at a command-line prompt:

certreq -submit -attrib "CertificateTemplate:Domaincontroller" dcname.req

CertificateTemplate

The value of this key instructs the CA which certificate template to use when processing the certificate request. The name must be specified as the common name of the certificate template or the object identifier of the template, not the template display name.

Summary Information	Details
Syntax	CertificateTemplate = {Templatename}
Values	Any valid certificate template name
Default value	Not applicable.
Sample value	Critical = “DomainController”
Can be manipulated in a pending request	Yes

SAN

The subject alternate name (SAN) can be specified in various ways. An SPN is specified as a UPN value.

Summary Information	Details
Syntax	SAN = “{tag}={value}&{tag}={value}]…” Always include double quotes around values
Values	A list of valid subject alternate name extension tags. email, upn, dns, guid, url, ipaddress, oid Alternatively, any valid object identifier can be specified.
Default value	Not applicable.
Sample value	See the following table for sample values.
Can be manipulated in a pending request	Yes

The value is a string type by default but can be prefixed with a tag in section brackets ({}) that determines the data type of the value explicitly as exemplified in the following table:

SAN string:	Explanation
2.5.29.17={octet}MBmCF1cySzMtQk8tREMuY29udG9zbzIuY29t	An ASN.1 string is put into the SAN as with one or several encoded extensions. The octet is a wrapper around a base64 string that is encoded in binary format
1.2.3.4={utf8}SomeReadableText	An ASN.1 string is put into the SAN as with one or several encoded extensions. The value is a string encoded with a UTF8 wrapper.
2.5.29.17={asn}=3019821757	An ASN.1 string is put into the SAN as with one or several encoded extensions.
email=John.Smith@contoso.com	The user’s e-mail address is put into the SAN.
dns=w2k3bodc.contoso.com	The DNS name is set to computers FQDN.
dn="CN=W2K3BODC,OU=Domain Controllers,DC=contoso,DC=com"	The distinguished name is set to the domain controller’s distinguished name.
url="https://www.contoso.com/default.html"	The URL is set to an HTTP URL.
ipaddress=172.134.10.134	The IP is put into the SAN.
oid=2.5.29.17	A given object identifier is put into the SAN.
upn=John.Smith@contoso.com	The UPN name represents the user.
guid=f7c3ac41-b8ce-4fb4-aa58-3d1dc0e36b39	A GUID is put into the SAN.

Combining Extensions

Many of the configuration options in the CA certificate extensions that are described above overlap. For example, you might need to decide whether to configure certain policy restrictions in the Policy Extension or in the Application Policy Extension. In addition, with many of these extensions and restrictions, organizations might need to decide whether to implement them at the root CA level or in a subordinate CA.

As a general rule, policy should be configured as high in the PKI hierarchy as possible. However, it is rare to put constraints in the root CA certificate itself. Instead, if a policy applies to the entire PKI, such policy constraints should be applied at the root level, when the CA certificate for a subordinate CA is created.

Policies that apply only to a portion of the PKI can be applied by establishing multiple subordinate policy CAs below the root CA.

Policy constraints are the most useful of the constraint options, both internally and externally. Name and path constraints might not provide you with sufficient protection in certain cross-certified relationships if the security standards of your business partners are not as strong as yours. For example, Organization A might have a policy that all user certificates must be approved manually by an administrator, while Organization B approves certificate requests automatically as long as the user has an e-mail account. The security administrators for Organization A must ensure that the certificates that users in Organization B use to access resources meet the higher security standards that are necessary in Organization A. They can accomplish this by using policy constraints.

You can use name constraints to limit unplanned domain-based trusts. If your organization has more than one domain — such as contoso.com and subdomain.contoso.com — you might only want cross-certificates to map to CAs in the contoso.com domain and not to CAs in the subdomain.contoso.com domain. On the other hand, if you have five different domains and want your cross-certificates to apply to three of them, path constraints provide a more flexible solution.

Use path constraints if transitive trusts create problems for your organization — for example, if you have an environment in which users can freely install subordinate CAs and you do not have strong security guidelines governing CA creation and management.

Use policy mapping if the organization that you are cross-certifying with has policies that are similar to those of your organization. Policy mapping is less useful when the policies of your organization are stricter than the policies of the other organization, or vice versa. If this is the case, use policy constraints to restrict your trust relationship instead of using policy mapping.

CA Certificate Processes and Interactions

Two types of processes and interactions are associated with CA certificates:

• Processes and interactions that are common to end entity certificates as well as CA certificates.

• Processes and interactions that are unique to CA certificates.

All certificates are validated essentially the same way -- by a series of checks involving

• Certificate discovery. The process of collecting CA certificates from Group Policy, Enterprise Policy, and AIA pointers in issued certificates, and the process of enrolling certificates.

• Path validation. The process by which public key certificates and their issuer certificates are processed in a hierarchical fashion until the certificate chain terminates at a trusted, self-signed certificate. Typically, this is the root CA certificate.

• Revocation checking. Each certificate in the certificate chain is verified to ensure that none of the certificates are revoked. The revocation checking can take place either in conjunction with the chain building process or after the chain is built.

For more information about these processes, see “How Certificates Work” in the Technical Reference.

Where CA certificates differ significantly from end entity certificates is how they are created, and the relationships between them established, from the trusted root CA certificate to subordinate CA certificates and cross certificates. The following sections describe these processes:

• How root CA certificates are created.

• How root CA certificates are renewed.

• How cross certificates are created.

• How subordinate CA certificates are created.

• How policies are applied for qualified subordination.

How Root CA Certificates are Created

The creation of a root CA certificate is inseparable from the process of setting up Certificate Services on the first CA in a PKI hierarchy. Certificate Services provides components that process subsequent certificate requests and enable you to manage certificate use. The root certificate, on the other hand, provides the foundation and establishes the basic rules that government certificate issuance and use. Where the root certificate defines standards for what is acceptable and unacceptable in the PKI hierarchy, Certificate Services applies those standards throughout its processes.

An issued certificate typically inherits properties from a certificate template that is provided by the issuing CA. (Some examples are certificate lifetime, the distribution point of the CRL, and other parameters.) Since the root CA requires a certificate for itself, the root CA must self-sign the root CA certificate because there is no parent CA that could issue the CA certificate.

Before the CA certificate is generated, you must have completed any custom configuration of the CAPolicy.inf file that is relevant to the CA certificate. The CAPolicy.inf file should contain all configuration information that is required to generate the self signed CA certificate according to the organization’s needs.

Process for Creating Root CA Certificates

To ensure that the CAPolicy.inf file is correctly processed:

• The ASCII text file must be available on the local computer before the CA setup procedure starts or before CA certificate renewal is attempted.

• The file must be placed in the Systemroot folder on the local computer on which the CA is installed.

For the specific syntax, see “CA Certificate Physical Structure,” in this document.

Note

• There is no syntax or error-checking message mechanism if the CAPolicy.inf file is not in the correct format.

The public and private keys are then generated by the CSP. If you use the default CSP, the keys are written to the local computer’s key store. If you did not use a hardware security module (HSM), the key is generated by CryptoAPI and is stored in the profile of the system account on the local computer. The length of time that is required to generate the key depends on both the size of the key that is generated and the CPU performance of the local computer. If an HSM is installed and selected, the key is generated in the HSM and stored according to the HSM specific architecture. Since no certificate templates are available on a stand-alone CA server that is a member of a workgroup, the CA certificate needs to be built from configuration information in the registry.

The following default key usage extension values are added to the CA certificate:

• Digital signature

• Certificate signing

• Certificate offline CRL signing

• Certificate CRL signing

However, if a root CA is installed on a computer that is running either a Windows 2000 or a Windows Server 2003 operating system, and that computer is a domain member, the CA inherits the Enhanced Key Usage extension settings from the CA template in Active Directory, even if the CA is installed as a stand-alone CA. If no Active Directory is available, the Enhanced Key Usage settings are also taken out of the configuration that is available in the registry.

How Root CA Certificates are Renewed

Root CA certificates need to have a longer lifetime than any other certificates in a PKI hierarchy. However, even root CA certificates will expire eventually. If they are not renewed, then every other certificate in the hierarchy is invalidated as well.

In addition, root CA certificates can be renewed before this is necessary in order to:

• Change the key used by the CA. (This is used in case of actual or suspected compromise.)

• Add certificate policies to the CA for qualified subordination.

• Change the CDP or Authority Information Access (AIA) paths.

• Partition a CRL.

Note that it is good practice to change the CA key at each renewal

Before the renewal process begins, the CAPolicy.inf file must be edited to reflect any changes, such as using a larger encryption key.

Note

• With root CA certificates, you cannot change the cryptographic service provider, reduce the key size, or shorten the validity period.

This updated information is then combined with the unchanged configuration information in the expiring root CA certificate to create the renewed root CA certificate, as illustrated in the following figure.

Process for Renewing Root CA Certificates

Both the expiring root CA certificate and the renewed root CA certificate continue to play critical roles in the PKI hierarchy:

• The original root CA certificate remains the ultimate foundation of trust for the hierarchy, and helps to validate the certificate chains for all certificates that have been issued under the original hierarchy.

• The renewed root CA certificate provides the foundation of trust for all certificates that are issued in the hierarchy from the renewal date forward.

To support both of these scenarios, by default, the root CA renewal process creates a pair of cross CA certificates that establish the trust relationship between the original and renewed root certificate:

• One verifies that the original root CA certificate trusts the renewed CA certificate

• The second verifies that the renewed CA certificate trusts the original root certificate.

The following figure illustrates this relationship.

How Root CA Certificates Use Cross Certificates

Note

• Although the certificates linking the original and renewed root certificate are referred to as cross certificates, they are not the same as the cross certificates used to establish trust between two separate PKI hierarchies.

Stand-alone CAs generate self -signed cross certificates when CA keys are changed. A cross certificate is generated for each key transition, for the period where the lifetimes of each root certificate overlap.

How Subordinate CA Certificates Are Created

The process for creating subordinate CA certificates in many ways resembles the process for creating a root CA certificate. Policy.inf must be in place on the server before you start Certificate Services setup, and the configuration data in Policy.inf is combined with configuration options that you select during Certificate Services setup.

At this point the two processes diverge, and the setup code for a subordinate CA generates a subordinate CA certificate request, which must be processed on the parent CA. After the parent CA has processed the request and generated the subordinate CA certificate, it can be transferred using the Certification Authority snap-in or Certutil.exe onto the subordinate CA. The following figure illustrates this process.

Process for Creating Subordinate CA Certificates

The process for obtaining a subordinate CA certificate from the root CA differs, depending on whether the parent CA is available online.

• If a parent CA is available online, the request can be sent directly to the root CA over the network.

• If a parent CA is not available online, the request must be saved to a file, which must be physically transferred to the parent CA to be processed.

At a minimum, the parent CA should provide a file that contains the subordinate CA's newly-issued certificate and, preferably, its full certification path. If a subordinate CA certificate does not include the full certification path, you must install the parent CA's certificate in the Intermediate Certification Authorities certificate store of the computer (if the parent CA is not a root CA), as well as the certificates of any other intermediate CA in the chain. You must also install the certificate of the root CA in the chain into the Trusted Root Certification Authorities store. These certificates should be installed in the certificate store before the CA certificate is installed on the new subordinate CA so that the new subordinate CA can build a valid CA chain when it starts.

How Policies Are Applied for Qualified Subordination

You can use CA certificates to implement qualified subordination, the process used to clearly define which certificates issued in one CA hierarchy are trusted in another CA hierarchy. Qualified subordination, which is also commonly called cross certification, can be used to link PKIs when two organizations merge or following an acquisition, or to facilitate closer business relationships between two organizations such as joint development agreements or consulting arrangements.

Qualified subordination is applied by issuing CA certificates from a CA in one PKI to a CA in a second PKI in order to establish a one-way trust relationship. If a CA in the second PKI issues a similar CA certificate to a CA in the first PKI, there will be a two-way trust relationship between the two hierarchies. Most likely, administrators in each hierarchy would configure these cross certificates using basic, policy, naming, and application constraints to limit which certificates are accepted from the other PKI, and the purposes for which they can be used.

Note

• In Windows 2000 operating systems, true cross-certification of CA hierarchies is not possible. Instead, you can define Certificate Trust Lists (CTLs) that trust specific CAs and use restricted certificates.

For example, consider the two PKIs illustrated in the following figure.

How Cross Certificates Establish Trust Between PKI Hierarchies

In this example, cross certificates are issued by Subordinate CA 2 to Subordinate  CA A, which makes it possible for user certificates issued by Issuing CA A to be used in the PKI anchored by Root CA 1, and by Subordinate CA A to Subordinate CA 2, which makes it possible for certificates issued by Issuing CA 1 to be used in the PKI anchored by Root CA 2.

Cross CA certificates such as this can also be issued from one root CA to a second root CA, by a root to a subordinate CA, by a subordinate CA to a root, or by a third “bridge” root CA to a root or subordinate CA in each of the organizations that wish to have a cross relationship. However, in any of these cases, it is likely that various name and policy constraints will be used to define and limit the usage of certificates issued in the partner’s CA hierarchy.

The key to understanding the use of cross certificates is that when a certificate issued by Issuing CA 1 is presented for use in the root CA 2 hierarchy, it is not validated against root CA 2. Instead, its certificate validation chain now includes the Sub CA A cross certificate, Subordinate CA 2, and Root CA 1. However, the cross certificate itself also must be validated, so the user certificate still ends up being validated for use --indirectly, in the case of the partner organization) for use.

To prevent undesired trust from being established, you can use:

• Basic constraints. These define which CAs your organization trusts in a partner’s CA hierarchy by limiting the path length for a certificate chain.. For example, in the cross certificate issued by Subordinate CA 2, basic constraints could prevent the acceptance and use of certificates issued by any CAs beyond Subordinate CAB — or certificates issued by Subordinate CA B itself.

• Name constraints. These prevent acceptance of certificates from the other organization in undesired namespaces. For example, if Subordinate CA 1 serves certificate requests for users and computers in a domain for a separate division of the organization, it would be undesirable for certificates issued in Organization A for use in a relationship with the organization supported by Subordinate CA 2 to be used elsewhere in the organization.

• Application constraints. These prevent the use of the partner organization’s certificates from being used for unapproved purposes. The cross certificate issued by Subordinate CA A might specify that certificates issued in the partner organization can only be used for e-mail signing, or for computer authentication, and specifically exclude other uses, such as key recovery.

• Policy constraints. These define the level of trust or assurance associated with the partner organization’s certificates. In many organizations, certificates can have significant legal implications, such as for signing purchase orders up to, but not exceeding, certain amounts. For example, Sub CA Cross Certificate can include a policy constraint specifying that certificates issued in the partner organization can only used to sign purchase orders up to $1,000. In a case such as this, it would likely also be valuable to include a policy mapping to an Organization 2 policy defining policy limits, such as legal liability, associated with certificates issued in the Root CA 2 hierarchy.

Related Information

The following resources contain additional information that is relevant to this section.

• “How Certificates Work” in Certificates Technical Reference

• “How Certificate Services Works” in Certificate Services Technical Reference