14.6 CA trust definition
In the following sections we look at how you can define PKI CA trust relationships in Windows Server 2003. We examine how to set up hierarchical, cross-certified, and constrained PKI trust relationships.
14.6.1 Defining Hierarchical Trust Relationships
A hierarchical trust relationship between a parent and a subordinate CA is defined as part of the Windows Server 2003 CA installation process. In the CA type dialog box, you can select whether the CA will be a root or a sub- ordinate CA (as illustrated in Figure 14.23 for a stand-alone CA). For a sub- ordinate CA you have the choice to submit the certificate request (the *.req file—which contains a PKCS#10 or CMC formatted request blob) immediately to the parent CA (if the CA is visible in AD and online) or provide it to the parent CA manually (e.g., using a floppy disk).
Figure 14.23: CA type dialog box.
Figure 14.24 gives a typical hierarchical trust example: an internal PKI for HP made up of a root CA and three regonial CAs: one for the Americas, one for EMEA, and one for AsiaPac.
Figure 14.24: Hierarchical trust example.
14.6.2 Defining cross-certified trust relationships
Contrary to a hierarchical trust relationship, a cross-certification trust relationship can be set up at any time after the CA installation. Cross-certification is typically done between the CAs of different organizations. Figure14.25 gives an interorganizational cross-certified trust example: The Compaq CA has issued a cross-certificate to the HP CA; the HP CA does the same thing the other way around.
Figure 14.25: Cross-certified trust example.
A cross-certification trust relationship can be set up between different types of CAs: they can be enterprise or stand-alone CAs, they can be root or subordinate CAs, and so forth. Figure 14.26 gives some sample scenarios.
Figure 14.26: Cross-certification scenarios.
A basic cross-certification example
Next we discuss the different steps needed to set up a basic bidirectional cross-certified trust relationship between the Compaq CA and the HP CA of Figure 14.25. Basic in this context means without defining any trust constraints. Although the chances are relatively small that organizations will ever set up such an unconstrained trust relationship, this example will facilitate the understanding of how to set up more complex constrained cross- certified trust relationships.
In order for the HP CA to generate a cross-certification certificate for the Compaq CA, you need to do the following:
-
Obtain a copy of the Compaq CA certificate and the HP CA policy.inf file. Store these files in a folder on the HP CA computer. The policy.inf file, which is normally used to specify trust constraints, is in this case almost empty. It contains the following information:
[Version] Signature= "$Windows NT$"
-
Make sure that the administrator that is generating the cross-certification request for the Compaq CA has a Qualified Subordination Signing certificate. We need this because the certificate template for a Cross Certification Authority requires the request to be signed using a certificate that has a Qualified Subordination Application Policy (as illustrated in Figure 14.27).
Figure 14.27: Issuance requirements for cross-certification authority certificate.The steps needed to generate a Qualified Subordination Signing certificate differ depending on whether the HP CA is a stand- alone or an enterprise CA:
-
If the HP CA is an enterprise CA, you will need to generate a new certificate template (Windows Server 2003 PKI, by default, does not include a template for Qualified Subordination Signing certificates) and then request a new certificate using that template. To generate a new certificate template for Qualified Subordination Signing, do the following:
-
Open the Certificate Templates MMC snap-in and duplicate the Enrollment Agent template.
-
Call the new template Qualified Subordination Signing (in the General tab) and make sure the following template properties are set:
Request Handling tab: Purpose: Signature.
Subject Name tab: Subject name format: Fully Distinguished Name/User principal name (UPN) checkbox enabled.
Issuance Requirements tab: CA certificate manager approval enabled.
Extensions tab: Remove the Certificate Request Agent
Application Policy/Add the Qualified Subordination Policy.
-
-
If the HP CA is a stand-alone CA, you can request a Qualified Subordination Signing certificate by including the Qualified Subordination OID in an advanced certificate request. To do so, initiate an advanced certificate request using the CA’s Web enrollment interface (/certsrv">http://<servername>/certsrv) and fill in the following OID:1.3.6.1.4.1.311.10.3.10 in the OID box (accessible when Type of Certificate Needed\Other is selected).
-
-
Run the following command from the folder where you copied the above files:
certreq.exe –policy—attrib CertificateTemplate:CrossCA
The certreq.exe utility will then:
-
Prompt you to open the Compaq CA’s request file (which is the Compaq CA’s certificate—this file normally has a *.cer extension) and the HP CA’s policy.inf file.
-
Ask you to select a Qualified Subordination signing certificate.
-
Ask you for a name and path to save the cross-certification request (file with *.req extension).
-
To let the HP CA process the cross-certification request and generate the cross-certification certificate, perform the following steps:
-
Open the Certification Authority MMC snap-in.
-
Right-click the CA object and select All Tasks\Submit new request.
-
In the Open Request File dialog box, select the cross-certification request file that was generated in step 3, and click Open.
-
The next step is different depending on whether the HP CA is a stand-alone or an enterprise CA:
-
If the HP CA is an enterprise CA, it will generate the cross- certificate, ask for a name and path to save the cross-certificate, and publish the cross-certificate in the Active Directory Configuration Naming Context.
-
If the HP CA is a stand-alone CA, it will add the request to the pending requests queue. The CA administrator can then manually approve the request (by right-clicking the request and selecting Issue) to issue the certificate. Unlike an enterprise CA, a stand-alone CA will not automatically publish the cross-certificate in the Active Directory. The CA administrator can do this manually by first exporting the cross-certificate from the CA database (use the Issued Certificates CA container) and then using the following command line (where xcert.crt is the name of the cross-certification certificate):
Certutil –dspublish –f <xcert.crt> CrossCA
At the end of this process, the HP Active Directory must contain a cross-certificate for the Compaq CA. The cross-certificate is stored in the crossCertificatePair attribute of the CA object for the Compaq CA in the \Services\Public Key Services\AIA AD Configuration naming context container. You can check this using the AdsiEdit or the LDP tools. This is illustrated in Figure14.28 using AdsiEDit for the cross-certificate of a CA called HP Root.
Figure 14.28: crossCertificatePair attribute for an AD CA object (viewed using AdsiEdit).
14.6.3 Defining trust constraints
The different PKI trust constraints available in Windows Server 2003 PKI together with their functionality were discussed extensively in Section14.4.5. In this section we will look at how you can set them up. There are three tools we can use to define PKI trust constraints:
-
The CAPolicy.inf configuration file. This file is used to set the PKI trust constraints of a CA certificate together with other CA configuration settings (like CRL Distribution Points, AIAs, and so forth). The content of the file is evaluated at CA installation time and every time the CA certificate is renewed. It must be stored in the %SystemRoot% folder of the machine where the CA is installed. Its name cannot be changed.
-
The Policy.inf configuration file. This file defines the PKI trust constraints that are embedded in a certificate request file. It is used as a parameter to the certreq.exe executable. Its name can be changed. This is definitely the most complete configuration tool: It can be used to configure all the different categories of PKI trust constraints (see also Table 14.2).
-
The properties of version 2 certificate templates. Certificate templates define the properties (including the PKI trust constraints) of certificates issued by Windows CAs. New to the version 2 certificate templates introduced in Windows Server 2003 PKI is that their content can be modified. V2 templates, however, cannot offer the same level of granularity for PKI trust constraint definition as the policy.inf and capolicy.inf configuration files.
Later in this chapter you can find more information on the syntax of the policy.inf and capolicy.inf configuration files. The chapter also contains a sample of each of the files.
Defining trust constraints using version 2 certificate templates
PKI trust constraints can be defined in the Extensions tab of a version 2 certificate template (as illustrated in Figure 14.29). Certificate templates can be administered from the Certificate Templates MMC snap-in. When setting PKI trust constraints this way, keep the following in mind:
-
The extensions you set will be applied to all certificates that are issued using that template. The capolicy.inf and policy.inf configurations are applied to individual certificates.
Figure 14.29 crossCertificatePair attribute for an AD CA object (viewed using AdsiEdit). -
Not all PKI trust constraints discussed in this chapter can be set using V2 certificate templates. You cannot use them to set name constraints, issuance policy mappings, issuance policy constraints, application policy mappings, application policy constraints, and the basic constraint path length. Table 14.7 gives an overview of the PKI trust constraints that can be configured using V2 certificate templates.
Table 14.7: Overview of the PKI Trust Constraints That Can Be Configured Using the Properties of a Version 2 Certificate Template PKI Trust Constraint
Parameter
Issuance Policies
Criticality
Issuance Policy Name
Issuance Policy OID
Issuance Policy CPS location
Application Policies
Criticality
Application Policy Name
Application Policy OID
Basic Constraints
Criticality
CA certificate or End-entity Certificate
Defining trust constraints using the CAPolicy.inf configuration file
In this section we give an example of how to set up a constrained PKI trust relationship in both a hierarchical and a networked trust model.
Figure 14.30: Setting application policies on a version 2 certificate template.
Figure 14.30 illustrates the constrained PKI trust relationship we want to set up between a root and a subordinate CA in a hierarchical trust model. This scenario shows a typical Windows Server 2003 forest environment consisting of a parent domain called hp.net and a child domain emea.hp.net. A root CA has been defined in the hp.net domain, and a sub- ordinate CA will be defined in the emea.hp.net domain. When the CA administrator of the hp.net root CA issues the subordinate CA certificate for the CA in emea.hp.net, he or she wants to apply the following PKI trust constraint to it: It should only be capable of issuing certificates to users that have a emea.hp.net UPN extension; it should never be capable of issuing certificates to users that have an americas.hp.net UPN extension (this would be the responsibility of another CA—located in the americas child domain—which is not shown in the figure). In order to enforce this we will apply a name constraint to the subordinate CA certificate that the root CA issues to the emea.hp.net subordinate CA.
The following is a summary of the major steps you need to follow to set this up:
-
During the installation of the subordinate CA for emea.hp.net, choose to save the certificate request to a file.
-
Copy the request file to a folder on the hp.net root CA and create a policy.inf as illustrated in Figure 14.30. Note that when using name constraints, all name types (UPN, DNS, and so forth) must be included or excluded (also the ones for which you do not want to define an explicit constraint) in the policy.inf file; otherwise, all namespaces for the missing name types will by default be all included or excluded (all name types were not added in Figures 14.30 and14.31 because of space constraints). See Section 6.3.6 for a complete policy.inf example.
Figure 14.31: Setting application policies on a version 2 certificate template. -
Run the following command line from the directory where both the request file and policy.inf file are located:
Certreq –policy
This command will first prompt you for the request file and the policy.inf file. Then it will ask you for a Qualified Subordination Signing certificate (for more information on how to create such a certificate see Section 14.6.2 on how to set up cross-certification), and finally it will ask you for a name and location to save the new request file (containing the policy constraints).
-
In the next step, we will provide this new request file to the root CA for certification. To do so, simply open the Certification Authority MMC snap-in, right-click the CA object, and select All Tasks\Submit new request. After you have selected the request file, the CA will generate the certificate and ask you for a name and location to save it.
-
Finally, copy the newly created certificate to the machine where the subordinate CA is installed and link it to the subordinate CA—when trying to start the CA service, a wizard will guide you through the CA certificate installation process.
A similar procedure can be used to set up a constrained PKI trust relationship between two CAs that are part of different organizations. This is a scenario where you would typically use a networked trust model made up of one or more cross-certified trust relationships. It is illustrated in Figure14.31 for the organizations CPQ (Compaq) and HP (Hewlett-Packard). Both organizations have their proper AD forest (hp.net and cpq.net) and Certification Authority (CA HP and CA CPQ). If both organizations want a bidirectional cross-certification, you will have to run the above procedure twice: once on the HP CA for the CPQ CA and once on the CPQ CA for the HP CA.
Defining trust constraints using the Policy.inf configuration file
This section contains an example of how to use the CAPolicy.inf configuration file to define PKI trust constraints for a stand-alone root CA. Remember that the CAPolicy.inf file can only be used to define basic and issuance policy constraints.
Using a CAPolicy.inf to define PKI trust constraints is relatively easy. Just make sure the file contains the correct statements (the CAPolicy.inf syntax is covered in the next section) and that it is saved to the %system- root% directory of the system where you want to install the CA. A sample is given in Figure 14.32. It contains a basic path length constraint of 1 and refers to an issuance policy called LegalPolicy.
Figure 14.32: Setting application policies on a version 2 certificate template.
CAPolicy.inf and Policy.inf syntax
Table 14.8 shows the syntax of the entries that are needed to define PKI trust constraints using the capolicy.inf and policy.inf configuration files.
| PKI Trust Constraint | Corresponding Section Header and Tag Syntax | |
|---|---|---|
| Name Constraints (Policy.inf only) | (NameConstraintsExtension) | |
| Critical | Criticality of certificate extension (True or Yes = Critical) | |
| Include | Tag for included namespace section | |
| Exclude | Tag for excluded namespace section | |
| DNS | DNS namespace; e.g., mydomain.com or server@domain.net | |
| | Email namespace; e.g., user@domain.net | |
| UPN | UPN namespace; always requires two entries: one with a . and one with an @. e.g., @domain.net and .domain.net | |
| IPAddress | IP address namespace; e.g., 10.34.56.0,255.255.255.0 or 10.34.56.3 | |
| URL | URL namespace; e.g., http://myserver/test.htm or file://\\myserver\tes.htm | |
| DirectoryName | Directory namespace; e.g., cn=company,ou=ou,s=state,c=country | |
| Issuance Policies (Both Policy.inf and CAPolicy.inf ) | (PolicyStatementExtension) | |
| Policies | Tags for Issuance Policy sections | |
| Critical | Criticality of certificate extension (True or Yes = Critical) | |
| OID | Object Identifier of the Issuance Policy | |
| Notice | Notice text associated to Issuance Policy | |
| URL | URL linked to Issuance Policy (can be HTTP, FTP, or LDAP URL) | |
| Issuance Policy Mappings (Policy.inf only) | (PolicyMappingsExtension) | |
| Critical | Criticality of certificate extension (True or Yes = Critical) | |
| <IssuancePolicy1_OID> = <IssuancePolicy2_OID> | Issuance Policy Mapping | |
| Issuance Policy Constraints (Policy.inf only) | (PolicyConstraintsExtension) | |
| RequireExplicitPolicy | Require Explicit Policy constraint, contains a numeric value | |
| InhibitPolicyMapping | Inhibit policy mapping constraint, contains a numeric value | |
| Application Policies | (ApplicationPolicyStatementExtension) | |
| Policies | Tags for Application Policy sections | |
| Critical | Criticality of certificate extension (True or Yes = Critical) | |
| OID | Object Identifier of the Application Policy | |
| Notice | Notice text associated to Application Policy | |
| URL | URL linked to Application Policy (can be HTTP, FTP, or LDAP URL) | |
| Application Policy Mappings (Policy.inf only) | (ApplicationPolicyMappingsExtension) | |
| Critical | Criticality of certificate extension (True or Yes = Critical) | |
| <ApplicationPolicy1_OID> = <ApplicationPolicy2_OID> | Application Policy Mapping | |
| Application Policy Constraints (Policy.inf only) | (ApplicationPolicyConstraintsExtension) | |
| RequireExplicitPolicy | Require Explicit Policy constraint , contains a numeric value | |
| InhibitPolicyMapping | Inhibit policy mapping constraint, contains a numeric value | |
| Basic Constraints (Both Policy.inf and CAPolicy.inf ) | (BasicConstraintExtension) | |
| Critical | Criticality of certificate extension (True or Yes = Critical) | |
| PathLength | Path Length constraint, contains a numeric value | |
Sample CAPolicy.inf configuration file
The following is a sample CAPolicy.inf file. The trust constraint-related information is marked in bold.[2]
[Version] Signature= "$Windows NT$" [PolicyStatementExtension] Policies = LegalPolicy, LimitedUsePolicy, OIDPolicy Critical = 0 [LegalPolicy] OID = 1.3.6.1.4.1.311.21.43 Notice = "Legal policy statement text." [LimitedUsePolicy] OID = 1.3.6.1.4.1.311.21.47 URL = http://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 gain/default.asp" [oidpolicy] OID = 1.3.6.1.4.1.311.21.55 [AuthorityInformationAccess] URL = http://%1/Public/My CA.crt URL = ftp://foo.com/Public/MyCA.crt URL = file://\\%1\Public\My CA.crt CriticAL = false [CRLDistributionPoint] URL = http://%1/Public/My CA.crl URL = ftp://%1/Public/MyCA.crl URL = file://\\%1\Public\My CA.crl CriticAL = true [CrossCertificateDistributionPointsExtension] SyncDeltaTime = 600 ; in seconds URL = http://%1/Public/My CCDP.crl URL = ftp://%1/Public/MyCCDP.crl URL = file://\\%1\Public\My CCDP.crl CriticAL = yeS [EnhancedKeyUsageExtension] OID = 1.3.6.1.4.1.311.21.6 ; szOID_KP_KEY_RECOVERY_AGENTOID = 1.3.6.1.4.1.311.10.3.9 ; szOID_ROOT_LIST_SIGNER OID = 1.3.6.1.4.1.311.10.3.1 ; szOID_KP_CTL_USAGE_SIGNING CriticAL = true [BasicConstraintsExtension] pathlength = 13 criticaL=false [certsrv_server] renewalkeylength=2048 RenewalValidityPeriodUnits=0x18 RenewalValidityPeriod=years CRLPeriod = days CRLPeriodUnits = 2 CRLDeltaPeriod = hours CRLDeltaPeriodUnits = 4
Sample Policy.inf configuration file
The following is a sample Policy.inf file. The trust constraint-related information is marked in bold.
[Version] Signature= "$Windows NT$" ; =========================================== ; Request Attributes ; =========================================== [RequestAttributes] CertificateTemplate = CrossCA ; ======================================== ; NameConstraintsExcluded Name Constraints Extension ; ======================================== [NameConstraintsExtension] Include = NameConstraintsPermitted Exclude = NameConstraintsExcluded Critical = TrUe [NameConstraintsPermitted] DNS = foo@domain.com DNS = domain1.domain.com email=me@you.com UPN=user.domain.com UPN=user@domain.com ; the first is an IP address, the second is an IP address mask ipaddress =255.255.18.172,255.255.255.0 url=http://localhost/certsrv/default.html url=file://\\localhost\certsrv\default.html DIRECTORYNAME = "cn=mycn,ou=myou,s=mystate,c=us" [NameConstraintsExcluded]; list of user defined excluded DNS names DNS = baddomain.com email = @baddomain.com UPN = . baddomain.com UPN = @baddomain.com ; the first is an IP address, the second is an IP address mask ipaddress =255.255.19.172,255.255.255.0 url=http://hrsrv1/public/default.html url=file://\\hrsrv1\public\default.html DIRECTORYNAME = "DC=baddomain,DC=com" ; ======================================== ; Policy (CPS) Extension ========================================= [PolicyStatementExtension] ; list of user defined policies Policies = LegalPolicy, LimitedUsePolicy, OIDPolicy CRITICAL = FALSE [LegalPolicy] ; each policy has OID, and zero or more Notice and URL keys OID = 1.3.6.1.4.1.311.21.43 Notice = "Legal policy statement text" [LimitedUsePolicy] OID = 1.3.6.1.4.1.311.21.47 URL = http://http.site.com/folder/default.asp URL = ftp://ftp.site.com/folder/default.asp Notice = "Limited use policy statement text." URL = "ldap://ldap.site.com/folder/default.asp" [oidpolicy] OID = 1.3.6.1.4.1.311.21.55 ; ======================================== ; Policy Mapping Extension ; ======================================== [PolicyMappingsExtension] ; list of user defined policy mappings ; first OID is Issuer Domain Policy OID ; second is Subject Domain Policy OID ; each entry maps one foreign policy OID to local 1.3.6.1.4.1.311.21.43 = 1.2.3.4.87 1.3.6.1.4.1.311.21.47 = 1.2.3.4.89 critical = yEs ; ======================================== ; Policy Constraints Extension ========================================= [PolicyConstraintsExtension] ; consists of two optional DWORDs RequireExplicitPolicy = 3 InhibitPolicyMapping = 5 ; ======================================== ; Application Policy (CPS) Extension ; ======================================== [ApplicationPolicyStatementExtension] ; list of user defined policies Policies = AppLegalPolicy, AppLimitedUsePolicy, AppOIDPolicy CRITICAL = FALSE [AppLegalPolicy] ; each policy has OID, and zero or more Notice and URL keys OID = 1.3.6.1.4.1.311.21.54 Notice = "Application Legal policy statement text" [AppLimitedUsePolicy] OID = 1.3.6.1.4.1.311.21.58 URL = http://http.site.com/application/default.asp URL = ftp://ftp.site.com/application/default.asp Notice = "Application Limited use policy statement text." URL = "ldap://ldap.site.com/application/default.asp" [Appoidpolicy] OID = 1.3.6.1.4.1.311.21.66 ; ======================================== ; Application Policy Mapping Extension ; ======================================== [ApplicationPolicyMappingsExtension] ; list of user defined application policy mappings ; first OID is Issuer Domain Policy OID ; second is Subject Domain Policy OID ; each entry maps one foreign policy OID to local 1.3.6.1.4.1.311.21.54 = 1.2.3.4.98 1.3.6.1.4.1.311.21.58 = 1.2.3.4.100 critical = true ; ======================================== ; Application Policy Constraints Extension ; ======================================== [ApplicationPolicyConstraintsExtension] ; consists of two optional DWORDs RequireExplicitPolicy = 6 InhibitPolicyMapping = 10 ; ======================================== ; Basic Constraints Extension ; ======================================== [BasicConstraintsExtension] ; Subject Type is not supported always set to CA ; maximum subordinate CA path length PathLength = 3 [EnhancedKeyUsageExtension] ;OID = 1.3.6.1.4.1.311.21.6 ;szOID_KP_KEY_RECOVERY_ AGENT ;OID = 1.3.6.1.4.1.311.10.3.9 ; szOID_ROOT_LIST_SIGNER ;OID = 1.3.6.1.4.1.311.10.3.1 ; szOID_KP_CTL_USAGE_ SIGNING ;Entries match the [ApplicationPolicyStatementExtension] section: OID = 1.3.6.1.4.1.311.21.54 OID = 1.3.6.1.4.1.311.21.58 OID = 1.3.6.1.4.1.311.21.66 CriticAL = true ; =========================================== ; Cross Certificate Distribution Points Extension ;=========================================== [CrossCertificateDistributionPointsExtension] SyncDeltaTime = 24 URL = http://%1/Public/My CA.crt URL = ftp://foo.com/Public/MyCA.crt URL = file://\\%1\Public\My CA.crt CriticAL = false
Trust constraint inheritance in hierarchical trust models
An interesting detail that was not covered so far in this chapter is whether trust constraints are inherited between the certificates of the different entities in a hierarchical trust model. Are trust constraints set in a parent CA certificate automatically copied in a subordinate CA’s certificate? Also, are they copied automatically to an end-entity certificate? Table 14.9 gives an overview.
| Trust Constraint Type | Set in Parent CA Certificate? | Copied to Subordinate CA Certificate? | Copied to End-Entity Certificate? |
|---|---|---|---|
| Basic Constraints | Yes | Yes | No |
| Name Constraints | Yes | No | No |
| Application Policies | Yes | Yes | No |
| Issuance Policies | Yes | No | No |
| Application Policy Mappings | Yes | No | No |
| Application Policy Constraints | Yes | No | No |
| Issuance Policy Mappings | Yes | No | No |
| Issuance Policy Constraints | Yes | No | No |
14.6.4 CA trust definition: Summary
Table 14.10 summarizes CA trust definition in Windows Server 2003 PKI: It shows when and how trust relationships are defined for the different PKI trust types. The table clearly shows that not every tool discussed previously can define all types of PKI trust constraints. Also, some of these tools cannot be used in a stand-alone CA environment and require the presence of enterprise CAs.
| PKI Trust Type | When and How Defined? | Applies to Which CAs? |
|---|---|---|
| Hierarchical Trust | During the CA installation process.
| Root and subordinate CAs in a hierarchical trust model |
| Cross-Certified Trust | Any time after the CA installation process.
| Cross-certified CAs in a networked trust model |
| Constrained Trust: Basic Constraints, Issuance Policies | During the CA installation process or at CA certificate renewal time.
During the CA installation process or at CA certificate renewal time.
Any time after the CA installation process.
| Root or subordinate CAs (that are subordinate to a stand-alone CA) in a hierarchical trust model Subordinate CAs (that are subordinate to an enterprise CA) in a hierarchical trust model Cross-certified CAs in a networked trust model |
| Constrained Trust: Application Policies | During the subordinate CA installation process or at subordinate CA certificate renewal time.
Any time after the CA installation process.
| Subordinate CAs (that are subordinate to an enterprise CA) in a hierarchical trust model Cross-certified CAs in a networked trust model |
| Constrained Trust: Name Constraints | As part of the subordinate CA installation process or at subordinate CA certificate renewal time.
Any time after the CA installation process.
| Subordinate CAs in a hierarchical trust model Cross-certified CAs in a networked trust model |
[2]The variables (%1...) that are used in the AuthorityInformationAccess, CRLDistributionPoint, and CrossCertificateDistributionPointsExtension fields are explained in Chapter 16.
EAN: 2147483647
Pages: 137