Walkthrough (Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003)

  • Article

Applies To: Windows Server 2003 with SP1

This section provides detailed implementation steps involved in defining qualified subordination between two CA hierarchies.

Creating an Offline Bridge CA

The following process can be used to deploy an offline root CA for your organization. The following is required before you establish your offline Bridge CA:

  • Configure a CAPolicy.inf file to define the following settings for the offline Bridge CA.

    • Authority Information Access locations

    • CRL Distribution Point locations

    • Certificate Practice Statement

    • All issuance policies required to cross the Bridge CA

  • Determine the CAs distinguished name.

  • Determine what Cryptographic Service Provider (CSP) will be used for certificate creation and signing.

Configuring the CAPolicy.inf File

The Offline Bridge CA must include the following sections in a CAPolicy.inf file stored in the %Systemroot% folder. This example shows an addition of three policy settings for the Offline Bridge CA. The OIDs for the three policies were obtained from the organization's Active Directory. Alternatively, the OIDs could be obtained from the IANA at https://www.iana.org/cgi-bin/enterprise.pl.

[Version]
Signature= "$Windows NT$"

 [certsrv_server]
CRLPeriod = weeks
CRLPeriodUnits = 26

[PolicyStatementExtension]
Policies = HighAssurancePolicy, MediumAssurancePolicy, LowAssurancePolicy
CRITICAL = FALSE

[HighAssurancePolicy]
OID = 1.3.6.1.4.1.311.21.8.2473717464.1095930238.502626717.506190032.1.402

[MediumAssurancePolicy]
OID = 1.3.6.1.4.1.311.21.8.2473717464.1095930238.502626717.506190032.1.401

[LowAssurancePolicy]
OID = 1.3.6.1.4.1.311.21.8.2473717464.1095930238.502626717.506190032.1.400

[PolicyConstraintsExtension]
RequireExplicitPolicy = 0
InhibitPolicyMapping = 0

[BasicConstraintsExtension]
PathLength = 0

Note

R As mentioned previously, it is not a best practice to place policy OIDs in root CA certificates. It is also not a best practice to place CDP or AIA extensions in the root CA certificate as most applications do not check for root CA revocation.

Installing Certificate Services

The actual installation process of a root CA is performed using the following steps:

  1. Ensure that the updated CAPolicy.inf file is saved to the %systemroot% folder.

    Note

    Appendix B contains an example of a CAPolicy.inf file.

  2. On the Start menu, click Settings, and then click Control Panel.

  3. On the Control Panel, double-click Add or Remove Programs.

  4. In the Add or Remove Programs window, click Add/Remove Windows Components.

  5. In the Windows Components Wizard, on the Windows Components page, select the Certificate Services check box.

  6. In the Microsoft Certificate Services dialog box, click Yes to accept that you cannot rename the computer or change its domain membership.

  7. On the Windows Components page, click Next.

  8. In the CA Type page (Figure 17), click Stand-alone root CA, select the Use custom settings to generate the key pair and CA certificate check box, and then click Next.

    6d8893aa-c1d0-402d-bd38-cfb4d5b46e96Figure 17: Defining the CA Type Configuration

  9. On the Public and Private Key Pair page (Figure 18), select the CSP and the Key length (for the private and public key pair), and then click Next.

    257da79a-90a5-4891-a86d-24212e559acfFigure 18: Defining the Public and Private Key Pair Properties

  10. On the CA Identifying Information page (Figure 19), enter the Common name and Validity period (for the Root CA certificate), and then click Next.

    dc2559d6-b77d-49f5-8904-70de774e92bdFigure 19: Defining the Common Name of the CA and Setting the Validity Period

    Note

    The Cryptographic Key is now generated based on the provided information in the preceding dialog boxes. Depending on the length of key defined on the Public and Private Key Pair page, this may take some time.

  11. On the Certificate Database Settings page (Figure 20), accept the default locations, and then click Next.

    fb4f9c68-acf8-4370-b4b7-b39e1474576cFigure 20: Defining the Database and Log Storage Locations

  12. In the Microsoft Certificate Services dialog box, click Yes to stop the Internet Information Services.

    The Configuring Components dialog box appears as the installation proceeds.

  13. If the Files Needed dialog box appears (Figure 21), in the Copy files from box, enter the CD-ROM drive path or the network share path where the distribution files are located, and then click OK.

    67259725-95c2-448d-9a5e-5de588c3ac63Figure 21: Providing the Location of the Installation Files

  14. In the Windows Components Wizard, click Finish.

  15. In the Add or Remove Programs dialog box, click Close.

  16. Close the Control Panel.

Disabling Delta CRLs at the Root CA

Typically, the root CA for a CA hierarchy is removed from the network for security purposes. Periodically, the CA must be accessed for the publication of updated CRLs. The goal of delta CRLs is to publish the newly revoked certificates at a more frequent interval than the publication period for the base CRL. By disabling delta CRLs, you reduce the number of times that the offline root CA must be accessed for CRL publication. It is typically not an issue that the delta CRLs are not published, as the number of certificates issued by the root CA is minimal.

Important

If cross-certification is performed between root CAs, it is possible that there may be a delay between the revocation of a former partner's cross-certification certificate and the recognition of the revocation by the clients accessing the base CRL.

  1. On the Start menu, point to Programs, point to Administrative Tools, and then click Certification Authority.

  2. In the Certification Authority console, in the console tree, expand CAName (where CAName is the name of your offline Bridge CA).

  3. In the console tree, right-click Revoked Certificates, and then click Properties.

  4. In the Revoked Certificates Properties dialog box, click to clear the Publish Delta CRLs check box, and then click OK.

  5. In the console tree, right-click Revoked Certificates, click All Tasks, and then click Publish to publish a new base CRL that does not reference a Delta CRL.

  6. In the Publish CRL dialog box, click OK.

Removing the Non-Required AIA and CDP Extensions

Once the offline Bridge CA is installed, the CDP and AIA locations for issued certificates must be modified to ensure that the certificate chaining engine can find the CRL and certificate for the offline Bridge CA. Because the CA is removed from the network, these default AIA and CDP extensions do not reference valid locations for the publication points. By removing the offline root CA from the network, you effectively remove the default publication points.

To remove non-required CDP and AIA extensions

  1. In the Certification Authority console tree, right-click CAName, and then click Properties.

  2. In the CAName Properties dialog box, click the Extensions tab.

  3. In the Select extension box, ensure that the box contains CRL Distribution Point (CDP).

  4. In the list of CDP locations, select the CDP location beginning with ldap:///, and then click Remove.

  5. In the Confirm removal dialog box, click Yes to verify the removal.

  6. In the list of CDP locations, select the CDP location beginning with https://, and then click Remove.

  7. In the Confirm removal dialog box, click Yes to verify the removal.

  8. In the list of CDP locations, select the CDP location beginning with file://\\, and then click Remove.

  9. In the Confirm removal dialog box, click Yes to verify the removal.

    Important

    Do not delete the CDP location referencing c:\windows\System32. This location is required by the CA to locally publish update Certificate Revocation lists.

  10. On the Extensions tab, select Authority Information Access in the Select extension box.

  11. In the list of AIA locations, select the AIA location beginning with ldap:///, and then click Remove.

  12. In the Confirm removal dialog box, click Yes to verify the removal.

  13. In the list of AIA locations, select the AIA location beginning with https://, and then click Remove.

  14. In the Confirm removal dialog box, click Yes to verify the removal.

  15. In the list of AIA locations, select the AIA location beginning with file://\\, and then click Remove.

  16. In the Confirm removal dialog box, click Yes to verify the removal.

    Important

    Do not delete the AIA location referencing c:\windows\System32. This location is required by the CA to locally publish renewed Certificates.

  17. Click OK.

  18. In the Certification Authority dialog box, click Yes to restart Certificate Services.

Adding Required AIA and CDP Extensions

The offline Bridge CA must add required CDP and AIA extensions to allow Active Directory clients and other clients to find the CAs certificate and CRL. You must modify the extensions to include paths that are available when the offline Bridge CA is removed from the network.

The examples provided in this white paper are not mandatory, but should be considered when defining the AIA and CDP extensions for the offline root CA.

Note

The AIA and CDP extensions are required by the certificate chaining engine to build certificate chains for validation. For more information about the certificate validation process, see Certificate Revocation and Status Checking (https://go.microsoft.com/fwlink/?LinkID=27081).

Adding the LDAP CDP Extension

The first CDP extension that needs to be added is the LDAP:// CDP extension. This CDP extension allows Active Directory and other LDAP clients to acquire the CRL from an LDAP service available to the Internet.

Note

In some Windows 2000 and Windows Server 2003 deployments, a separate Active Directory forest is deployed in the extranet to prevent external access to the corporate Active Directory. If a separate LDAP service is used in the extranet, the LDAP URL must reference this Active Directory service. Otherwise, the LDAP URL must reference a link that is accessible by all clients that require access to the CRL.

To add the CRL to Active Directory, you will need the following information from the forest root domain of Active Directory that will maintain a copy of the offline Root CAs CRL:

ForestRootDomain   The LDAP representation of the forest root domain. For example
security.nwtraders com would be represented as DC=security,DC=Nwtraders,DC=com.

You will also require some information from the offline Bridge CA. Specifically, you require the following:

CAName:    The name assigned to the CA during installation of the CA. 
CAMachineName:    The NetBIOS name of the computer hosting the CA.

You will need to add the two following LDAP paths to the CDP extensions list:

ldap:///CN=CAName,CN=CAMachineName,CN=CDP,CN=Public Key Services,
CN=Services,CN=Configuration,CAForestName?certificateRevocationList
?base?objectClass=cRLDistributionPoint

and

ldap://ldap.company.com/CN=CAName,CN=CAMachineName,CN=CDP,CN=Public Key Services,
CN=Services,CN=Configuration,CAForestName

where ldap.company.com is an URL that refers queries to TCP port 389 to the
server hosting the LDAP service, typically a Windows 2000 domain controller.

For example, for the following information:

  • CAName: BridgeCA

  • CAMachineName: BridgeComp

  • ForestRootDomain: extranet.nwtraders.com

The following are the LDAP paths you must add to the list of CDP extensions:

ldap:///CN=BridgeCA,CN=BridgeComp,CN=CDP,CN=Public Key Services,
CN=Services,CN=Configuration,DC=extranet,DC=nwtraders,DC=com?certificateRevocati
onList?base?objectClass=cRLDistributionPoint

and

ldap://ldap.extranet.nwtraders.com/CN=BridgeCA,CN=BridgeComp,CN=CDP,CN=Public
Key Services,CN=Services,CN=Configuration,DC=extranet,DC=nwtraders,DC=com

Note

The LDAP:/// URL is a local LDAP path that binds to the current domain controller used by the client computer. This LDAP URL will not work with external clients, therefore, the second LDAP URL is added to provide the URL to the LDAP server for external clients.

  1. In the Certification Authority console tree, right-click CAName, and then click Properties.

  2. In the CAName Properties dialog box, click the Extensions tab.

  3. Ensure that the Select Extensions list contains CRL Distribution Points (CDP), and then click Add.

  4. In the Add Location dialog box (Figure 22), in the Location box, type the LDAP path as described previously, and then click OK.

    535585f5-6307-481e-91d5-07c89e5b6ad0Figure 22: Adding an LDAP CDP Extension

    Note

    Consider creating the path in a text file beforehand and then copying and pasting the complete LDAP URL into the Location box. There is no control to allow editing of the LDAP path if it is incorrectly typed in the console.

  5. On the Extensions tab, select the LDAP CDP extension. Select the Include in all CRLS. Specifics where to publish in the Active Directory when publishing manually and Include in the CDP extension of issued certificates check boxes as shown in Figure 23. The first option is recommended when publishing offline CA CRLs to Active Directory. The second option ensures that all issued certificates include the updated paths to the CRL.

    559e6ffc-6942-4ab4-bc22-16eb2b21be15Figure 23: Configuring the Properties of the LDAP Extension

    Repeat the process using the LDAP URL
ldap://ldap.company.com/CN=CAName,CN=CAMachineName,CN=CDP,CN=Public Key Services,
CN=Services,CN=Configuration,CAForestName

  6. Leave the dialog box open to allow the addition of an HTTP CDP extension.

Note

It is recommended to include an HTTP CDP extension to ensure that non-LDAP clients can access the offline CA's CRL. It also is easier to deploy the CRL to external clients using the HTTP protocol than the LDAP protocol.

Adding the HTTP CDP Extension

Additionally, at least one CDP extension should be added for the HTTP protocol that references an available Web server hosting the CRL file for the offline CA. You should provide more than one HTTP location to provide fault tolerance in the event that the Web server referenced in the CDP extension is unavailable. The URL must reference a valid HTTP location to work correctly.

To add an HTTP CDP extension

  1. In the CAName Properties dialog box, click the Extensions tab.

  2. Ensure that the Select Extensions list contains CRL Distribution Points (CDP), and then click Add.

  3. In the Add Location dialog box (Figure 24), in the Location box, type the HTTP path as described previously, and then click OK.

    c1570723-c4bb-4fab-ab0a-9619bafa85f2Figure 24: Adding an HTTP CDP Extension

    Note

    Consider creating the path in a text file beforehand and then copying and pasting the complete HTTP URL into the Location box. There is no control to allow editing of the HTTP path if it is incorrectly typed in the console.

  4. On the Extensions tab, select the HTTP CDP extension, and then select the Include in the CDP extension of issued certificates check box as shown in Figure 25.

    b5abc35e-5ff3-4b61-ae96-2eed92c46b86Figure 25: Configuring the Properties of the HTTP Extension

  5. In the CAName Properties dialog box, click OK.

  6. In the Certification Authority dialog box, click Yes to restart Certificate Services.

Adding an HTTP AIA Extension

In addition to CDP extensions, an AIA extension should be added to allow Web clients to access the offline Bridge CAs certificate from a Web server.

To add an updated HTTP AIA extension

  1. In the Certification Authority console tree, right-click CAName, and then click Properties.

  2. In the CAName Properties dialog box, click the Extensions tab.

  3. Ensure that the Select Extensions list contains Authority Information Access (AIA), and then click Add.

  4. In the Add Location dialog box (Figure 26), in the Location box, type the HTTP path to the Root CA certificate, and then click OK.

    5f09ada8-aa9f-420e-9ae3-d518662f1459Figure 26: Adding an HTTP AIA Extension

    Note

    Consider creating the path in a text file beforehand and then copying and pasting the complete HTTP URL into the Location box. There is no control to allow editing of the HTTP path if it is incorrectly typed in the console.

  5. On the Extensions tab, select the HTTP AIA extension, and then select the Include in the AIA extension of issued certificates check boxes as shown in Figure 27.

    52453c5e-343e-4ff3-b703-f7be0217c744Figure 27: Configuring the Properties of the LDAP Extension

  6. In the CAName Properties dialog box, click OK.

  7. In the Certification Authority dialog box, click Yes to restart Certificate Services.

Publishing CRLs and Certificates

Once the CDP and AIA extensions are modified, you must publish the updated CRL referencing the new CDP locations. The previous version of the CRL still contains the default locations for the CDP and AIA extensions.

To publish the new base CRL

  1. In the console tree, right-click Revoked Certificates, click All Tasks, and then click Publish to publish a new base CRL.

  2. In the Publish CRL dialog box, click OK.

Once the CRL is updated, the new version must be published to the locations referenced in the CDP and AIA extensions. This requires manually copying the CRL and Certificate to the Web servers and injecting the CRL and certificate into Active Directory.

Publishing the CRL and CA Certificate to a Web Server

The CRL and CA Certificate can be retrieved from the \\CAMachineName\CertEnroll share and copied to a disk or to a network location. The CRL and certificate must be published to the location referenced in the CDP and AIA extensions of the CA.

For example, if the CDP extension references https://www.microsoft.com/public/rootca.crl, the CRL must be copied to this location so that a Web client can retrieve the latest version of the CRL.

Likewise, if the AIA extension references https://www.microsoft.com/public/rootca.crt, the CAs certificate file must be copied to this location so that a Web client can retrieve the CAs certificate.

By default, the IIS default Web site is stored in \inetpub\wwwroot in the same drive where the Windows Server 2003 operating system is installed. To create the paths referenced above, you can create a Public subfolder and copy the two files into the Public folder (\inetpub\wwwroot\public).

Alternatively, you can create a virtual folder and have /Public reference any folder on the Web servers disk.

Once the CRL and certificate are published, you should validate that the paths are correct in the issued certificates by connecting to the CRL and certificate using the CDP and AIA URLs.

Publishing the CRL and CA Certificate into Active Directory

The Certutil.exe utility is used to publish the CAs certificate and CRL into the Configuration naming context of Active Directory. The CA's certificate is published to two locations:

  • CN=CAName,CN=Certification Authorities,CN=Public Key Services,CN=Services,

    CN=Configuration,DC=ForestRootDomainDN

  • CN=CAName,CN=AIA,CN=Public Key Services,CN=Services,

    CN=Configuration, DC=ForestRootDomainDN

The CA's CRL is published to the following location in the Configuration naming context:

  • CN=CAName,CN=CAComputerName,CN=CDP,CN=Public Key Services,CN=Services CN=Configuration,DC=ForestRootDomainDN

The Certutil.exe utility is only installed at a CA by default, but can be installed at any Windows XP client by installing the Windows Server 2003 Administration Pack (adminpak.msi).

Assuming that the CAs certificate is named RootCA.crt and that the CAs CRL is named RootCA.crl, and that the files are stored in the current directory, the following commands can be run to inject the CAs certificate and the CAs CRL into Active Directory.

To install the CAs CRL into Active Directory, use the following command:

certutil.exe -dspublish -f RootCA.crl

If the command is successful, you should see the following output in response to the command:

ldap:///CN=RootCA,CN=RackCluster3,CN=CDP,CN=Public Key Services,CN=Services
,CN=Configuration,DC=bkforest2,DC=nttest,DC=microsoft,DC=com?certificateRevocati
onList?base?objectClass=cRLDistributionPoint?certificateRevocationList

Base CRL added to DS store.

CertUtil: -dsPublish command completed successfully.

To install the CAs certificate into Active Directory, a variation of the Certutil –dspublish command is used:

Certutil –dspublish –f RootCA.crt RootCA

If successful, the command should produce the following output:

ldap:///CN=RootCA,CN=Certification Authorities,CN=Public Key Services,CN=Se
rvices,CN=Configuration,DC=bkforest2,DC=nttest,DC=microsoft,DC=com?cACertificate

Certificate added to DS store.

ldap:///CN=RootCA,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuratio
n,DC=bkforest2,DC=nttest,DC=microsoft,DC=com?cACertificate

Certificate added to DS store.

CertUtil: -dsPublish command completed successfully.

Note

The certificate is published to both the Certification Authorities and AIA locations under Public Key Services.

Installing the Enterprise Subordinate CAs

The enterprise subordinate CAs must be installed with the issuance policies defined for the CA certificate. The following processes describe the installation of the Enterprise Subordinate CA.

Configuring the CAPolicy.inf File

The Enterprise Subordinate CA requires that a CAPolicy.inf file be created and installed in the %systemroot% folder to apply the correct policies. If the Enterprise CA already exists, you can still use CAPolicy.inf and renew the CAs certificate to apply the modified settings. The CAPolicy.inf file must contain the following sections:

[RequestAttributes]
CertificateTemplate = SubCA

[PolicyStatementExtension]
Policies = HighAssurancePolicy, MediumAssurancePolicy, LowAssurancePolicy
CRITICAL = FALSE

[HighAssurancePolicy]
OID = 1.3.6.1.4.1.311.21.8.2473717464.1095930238.502626717.506190032.1.402

[MediumAssurancePolicy]
OID = 1.3.6.1.4.1.311.21.8.2473717464.1095930238.502626717.506190032.1.401

[LowAssurancePolicy]
OID = 1.3.6.1.4.1.311.21.8.2473717464.1095930238.502626717.506190032.1.400

Note

The OIDS for the assurance policies must be modified to match the OIDS for the forest where the Enterprise Subordinate CAs exist. Each forest will generate a unique OID that is used for the high, medium, and low assurance issuance policies. In this example, the unique component of each OID is 1.3.6.1.4.1.311.21.8.2473717464.1095930238.502626717.506190032.1, You must change the OIDs shown in this example to match the unique OID representing your forest.

To modify the CAPolicy.inf file

  1. Copy the modified CaPolicy.inf file to the %systemroot% folder.

  2. Open the CaPolicy.inf file using Notepad.

  3. Click Start, and then click Run. In the Open box, type certtmpl.msc.

  4. In the console tree, right-click Certificate Templates, and then click View Object Identifiers.

  5. In the View Object Identifiers dialog box, select High Assurance, and then click Copy Object Identifier.

  6. Paste the updated object identifier for High Assurance into the CaPolicy.inf file.

  7. In the View Object Identifiers dialog box, select Medium Assurance, and then click Copy Object Identifier.

  8. Paste the updated object identifier for Medium Assurance into the CaPolicy.inf file.

  9. In the View Object Identifiers dialog box, select Low Assurance, and then click Copy Object Identifier.

  10. Paste the updated object identifier for Low Assurance into the CaPolicy.inf file.

  11. In the View Object Identifiers, click Close.

  12. Close the Certificate Templates console.

Installing Certificate Services

Once the CAPolicy.inf file is configured, the installation of the Enterprise CA can begin. The process is made up of three steps: the initial installation of the enterprise subordinate CA, the offline certificate request process, and the installation of the SubCA certificate.

Installing the Enterprise Subordinate CA

To perform the initial installation of certificate services on the enterprise subordinate CA

  1. On the Start menu, click Settings, and then click Control Panel.

  2. In the Control Panel, double-click Add or Remove Programs.

  3. In the Add or Remove Programs window, click Add/Remove Windows Components.

  4. In the Windows Components Wizard, on the Windows Components page, select the Certificate Services check box.

  5. In the Microsoft Certificate Services dialog box, click Yes to accept that you cannot rename the computer or change its domain membership.

  6. In the Windows Components page, click Next.

  7. In the CA Type page, click Enterprise Subordinate CA, select the Use custom settings to generate the key pair and CA certificate check box, and then click Next.

  8. On the Public and Private Key Pair page, define the CSP, Hash algorithm, and Key length the CA will use for the private and public key pair (Figure 28), and then click Next.

    bd9e07f4-4822-4405-93fb-4f55aecb19c4Figure 28: Defining the Public and Private Key Settings

  9. On the CA Identifying Information page (Figure 29), enter the Common name for this CA, and then click Next.

    8011cc44-f4ef-4206-ab65-2a61eca19d66Figure 29: Defining the CA Name

  10. On the Certificate Database Settings page (Figure 30), accept the default settings, and then click Next.

    63e9ceac-0a9c-4502-813a-3e9cd25e7656Figure 30: Defining the Certificate Database and Log Locations

  11. On the CA Certificate Request page (Figure 31), select the Save the request to a file option button, accept the default Request file name, and then click Next.

    32e7d6a2-c3af-48c9-b931-fb1f1d64966fFigure 31: Configuring an Offline Certificate Request

    Note

    This assumes that the root CA or parent CA is offline and unable to receive online requests.

  12. In the Microsoft Certificate Services dialog box, click Yes.

  13. If the Files Needed dialog box appears, enter the path to the installation files, and then click OK.

    Note

    A dialog box appears indicating that the installation is incomplete and that the request file must be submitted to the parent CA.

  14. In the Microsoft Certificate Services dialog box, click OK.

  15. In the Windows Components Wizard, click Finish.

Signing the Offline Certificate Request

To sign the offline certificate request (These steps are performed at the offline Root CA or the offline parent CA.)

  1. Copy the request file to a disk.

  2. Take the disk to the offline root CA.

  3. Open the request file using Notepad. You should see content similar to the following example:

     -----BEGIN NEW CERTIFICATE REQUEST-----
MIICJTCCAY4CAQAwPjETMBEGCgmSJomT8ixkARkWA2NvbTETMBEGCgmSJomT8ixk
ARkWA2FiYzESMBAGA1UEAxMJSXNzdWluZ0NBMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDD7j/MtDoqG0ZWdGSkF7h+taDOD5fB8JhTqIgx31maN+YQE288n7Vm
xtHH7a6Mo+hTRyNBr9gut3ZD4+CNETE+ek3SAsqu/7yXKPzlURlrniKWSAQ9kseO
9llLNFVAWwE8dwxR/taqMAKW1hxflub7p7qnL95eqLzzLfzPfqHwoQIDAQABoIGm
MCkGCisGAQQBgjcNAgMxGxYZNS4xLjM1OTAuMi5TZXJ2aWNlIFBhY2sgMTB5Bgkq
hkiG9w0BCQ4xbDBqMBAGCSsGAQQBgjcVAQQDAgEAMB0GA1UdDgQWBBS64o3oWvft
Zy8bMazXc1SZsyCx2jAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8E
BAMCAYYwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQAl15B50lwN
AfsSgFKTuPELSalkjWmnn11ZPAmGCLHnhZ6yhQwonWntN3nRaU7F1+KfEnvoibb2
DM1x7SLoMEzQrWQ8sWneoBSCtD0Sdg24dIpWwxlnKgsImRlfGnlEQEd/VHTgyxSh
hrS1gQXYQYH0CT8giCZ8PwGsg1qr/8dMIg==
-----END NEW CERTIFICATE REQUEST-----

  4. Copy the entire contents of the request file to the Windows Clipboard.

  5. Start Internet Explorer.

  6. Open the https://localhost/certsrv URL.

  7. On the Welcome page, click the Request a certificate link.

  8. On the Request a Certificate page, click advanced certificate request.

  9. In the Advanced Certificate Request page, click Submit a certificate request by using a base-64-encoded CMC or PKCS#10 file, or submit a renewal request by using a base-64-encoded PKCS#7 file.

  10. In the Submit a Certificate Request or Renewal Request page, paste the contents of the request file in the Saved Request box, and then click Submit.

  11. The Certificate Pending page appears informing you that an administrator must issue the certificate. You should note the request ID for future reference.

  12. Close Internet Explorer.

To issue the certificate, you must use the Certification Authority Console.

  1. On the Start menu, point to Programs, point to Administrative Tools, and then click Certification Authority.

  2. In the console tree, expand CAName (where CAName is the name of your Certification Authority), and then click the Pending Requests container.

  3. In the details pane, right-click the pending request, identified by its request ID, for the previously submitted request, click All Tasks, and then click Issue.

  4. Close the Certification Authority console.

To retrieve the issued certificate (These steps are performed at the offline root CA or offline parent CA.)

  1. Start Internet Explorer.

  2. Open the https://localhost/certsrv URL.

  3. On the Welcome page, click the View the status of a pending certificate request link.

  4. On the View the Status of a Pending Certificate Request page, click the Saved-Request Certificate (Date and Time) link.

  5. On the Certificate Issued page, click the Download certificate chain link.

  6. In the File Download dialog box, click Save.

  7. In the Save As dialog box, in the file name box, type a:\certnew.p7b, and then click Save to save the PKCS#7 file to the disk.

  8. If the Download complete dialog box appears, click Close.

  9. Close Internet Explorer.

Installing the Certificate at the Enterprise Subordinate CA

The PKCS#7 file must now be installed at the enterprise subordinate CA using the following steps:

  1. Insert the disk containing the PKCS#7 file in the disk drive.

  2. On the Start menu, point to Programs, point to Administrative Tools, and then click Certification Authority.

  3. In the console tree, right-click CAName (where CAName is the name of your enterprise subordinate CA), point to All Tasks, and then click Install CA Certificate.

  4. In the Select file to complete CA Installation dialog box, in the File name box, type a:\certnew.p7b, and then click Open.

  5. In the console tree, right-click CAName, point to All Tasks, and then click Start Service.

Note

It may be required to also install the offline root CA's CRL manually if the CRL cannot be accessed directly from the network. You can load the CRL file using the certutil.exe –addstore <CRL file> command.

Renewing an Existing Enterprise Subordinate CA

  1. Ensure that the modified CAPolicy.inf file is in the %SystemRoot% folder.

    This ensures that either the newly defined constraints are applied or that the existing policy constraints are retained.

  2. On the Start menu, point to Programs, point to Administrative Tools, and then click Certification Authority.

  3. In the console tree, right-click CAName, and then click Renew CA Certificate.

  4. In the Install CA Certificate dialog box, click Yes to stop Certificate Services.

    Note

    In addition to defining constraints, the key size, key lifetime, CDP locations, AIA locations, and other settings defined in the CAPolicy.inf file can be redefined at certificate renewal.

  5. In the Renew CA Certificate dialog box (Figure 32), click No so that the same public and private key pair is used, and then click OK.

    0d5a9c50-c144-4b11-9275-d331f2d0056dFigure 32: Selecting Whether to Generate a New Public and Private Key Pair

  6. In the CA Certificate Request dialog box (Figure 33), enter the Computer Name and Parent CA name for the issuing CA, and then click Cancel. This will place a CAMachineName_CAName.req file in the root folder of the volume where Windows Server 2003 is installed.

    4d5b9c57-764e-44d1-9fb7-4fb457dbaf01Figure 33: Selecting the CA to Which the CA Will Be a Subordinate CA

    Note

    If the CA that issued the SubCAs certificate is online, you can click OK to attempt the certificate request online.

  7. Copy the CAMachineName_CAName.req file to a disk, and then follow the procedures for performing the offline request and certificate installation used for installing a new subordinate CA certificate.

Verifying the Inclusion of All Issuance Policies

Once the CA certificate is installed, the Enterprise CAs certificate should be inspected to ensure that the Issuance policies are included in the certificate.

  1. On the Start menu, point to Programs, point to Administrative Tools, and then click Certification Authority.

  2. In the console tree, right-click CAName (where CAName is the name of your CA), and then click Properties.

  3. In the CAName Properties dialog box, on the General tab, click View Certificate.

  4. On the General tab, ensure that the intended purposes list includes:

    • High Assurance

    • Medium Assurance

    • Low Assurance

  5. If any are missing, or appear as OIDs rather than text, review the %systemroot%\CAPolicy.inf file and ensure that the correct OIDs for the domain are included in the file. An incorrect OID will result in the OID being listed here, rather than being translated to the display names.

  6. In the Certificate dialog box, click OK.

  7. In the CAName Properties dialog box, click OK.

  8. Close the Certification Authority console.

Creating a Qualified Subordination Signing Certificate at a Stand-alone CA

A stand-alone CA does not use certificate templates. Because certificate templates are not supported by stand-alone CAs, the certificate request must inject the OID for qualified subordination during certificate enrollment. The following steps allow a qualified subordination certificate to be obtained at a stand-alone CA.

Performing the Initial Certificate Request

To perform the initial request for a qualified subordination signing certificate

  1. At the stand-alone CA, ensure that you are logged on as the Administrator of the CA computer.

  2. Start Internet Explorer.

  3. Open the https://localhost/certsrv URL.

  4. On the Welcome page, click Request a certificate.

  5. On the Request a Certificate page, click advanced certificate request.

  6. On the Advanced Certificate Request page, click Create and submit a request to this CA.

  7. On the Advanced Certificate Request page, enter the following information in Identifying Information:

    • Name: Administrator (or the name of the user account currently in use)

    • E-mail: Leave blank

    • Company: YourOrganization (where YourOrganization is the name of your organization)

    • Department: YourDepartment (where YourDepartment is the name of your department)

    • City: CityName (where CityName is the name of your city)

    • State: StateName (where StateName is the name of your state or province)

    • Country/Region: CountryName (where CountryName is the name of your country or region)

  8. In Type of Certificate Needed, select Other from the list.

  9. In the OID box, type 1.3.6.1.4.1.311.10.3.10.

  10. In Key Options, set the following options:

    • Create a new key set

    • CSP: Microsoft Enhanced Cryptographic Provider v1.0 (or a different CSP if you are using a hardware CSP).

    • Key Usage: Signature

    • Automatic Key container name

    • Mark keys as exportable: unchecked

    • Enable strong private key protection: unchecked

    • Use local machine store: unchecked

  11. In Additional Options, set the following options:

    • Request format: CMC

    • Hash Algorithm: SHA-1

    • Save request to a file: unchecked

    • Attributes: empty

    • Friendly name: Qualified Subordination Signing

  12. Review the entries, and then click Submit.

    The Certificate Pending page appears.

Issuing the Pending Certificate Request

The certificate request is set to a pending status by default on a stand-alone CA. To issue the certificate, a CA administrator must use the Certification Authority console.

  1. On the Start menu, point to Programs, point to Administrative Tools, and then click Certification Authority.

  2. In the console tree, click the Pending Requests container.

  3. In the details pane, right-click the certificate request, point to All Tasks, and then click Issue.

  4. Close the Certification Authority console.

Installing the Qualified Subordination Signing Certificate

The final step is to install the issued certificate.

  1. In Internet Explorer, open the https://localhost/certsrv/ URL.

  2. On the Welcome page, click View the status of a pending certificate request.

  3. On the View the status of a pending certificate request page, click the User-EKU (1.3.6.4.1.311.10.3.10) Certificate (Date and Time) link.

  4. On the Certificate Issued page, click Install this certificate.

    The Certificate Installed page should appear.

  5. Close Internet Explorer.

Verifying the Qualified Subordination Signing Certificate

Once you have installed the qualified subordination certificate, you should view the certificate to ensure that it is correctly configured.

  1. Open an empty MMC console.

  2. On the File menu, click Add/Remove Snap-in.

  3. In the Add/Remove Snap-in dialog box, click Add.

  4. In the Add Standalone Snap-in dialog box, select Certificates, and then click Add.

  5. In the Certificates snap-in dialog box, click My user account, and then click Finish.

  6. In the Add Standalone Snap-in dialog box, click Close.

  7. In the Add/Remove Snap-in dialog box, click OK.

  8. In the console tree, expand Certificates – Current User, expand Personal, and then click Certificates.

  9. In the details panel, double-click the certificate with the Template Friendly Name of Qualified Subordination Signing.

  10. In the Certificate dialog box, on the General tab, ensure that the intended purposes only list Qualified Subordination.

  11. In the Certificate dialog box, on the Details tab, ensure that the Key Usage indicates Digital Signature, Non-Repudiation (c0).

  12. Click OK.

  13. Close the console without saving changes.

Creating a Qualified Subordination Signing Certificate at an Enterprise CA

An Enterprise CA running on Windows Server 2003 Enterprise Edition can issue version 2.0 certificate templates. For qualified subordination, a version 2.0 template can be created to allow qualified subordination signing. If you are going to issue the Qualified Subordination Signing certificate from an Enterprise CA, the following steps will allow the creation and retrieval of a qualified subordination signing certificate at an enterprise CA.

Note

While the goal is the same as the previous section on creating a qualified subordination signing certificate, the method is different when issuing the certificate from an Enterprise CA. The decision on which CA type to use should be based on what CAs are available in the infrastructure.

Creating a Qualified Subordination version 2 Certificate Template

To create a version 2 certificate template for Qualified Subordination Signing

  1. Open an empty MMC console.

  2. On the File menu, click Add/Remove Snap-in.

  3. In the Add/Remove Snap-in dialog box, click Add.

  4. In the Add Standalone Snap-in dialog box, select Certificate Templates, and then click Add.

  5. In the Add Standalone Snap-in dialog box, click Close.

  6. In the Add/Remove Snap-in dialog box, click OK.

  7. In the console tree, select Certificate Templates.

  8. In the details pane, right-click Enrollment Agent, and then click Duplicate Template.

  9. In the Properties of New Template dialog box, on the General tab, in the Template display name box, type Qualified Subordination Signing.

  10. On the Request Handling tab (Figure 34), make the following property changes:

    3ab288c7-a8f5-4889-99b5-4092011649d2Figure 34: Setting Request Handling Attributes

    • Purpose: Signature

    • CSPs: Clear the check boxes for Microsoft Base Cryptographic Provider 1.0 and Microsoft Base DSS Cryptographic Provider and ensure that Microsoft Enhanced Cryptographic Provider 1.0 is checked.

  11. On the Subject Name tab, ensure that the Subject name format is set to Fully distinguished name and that only the User principal name (UPN) check box is selected.

  12. On the Issuance Requirements tab (Figure 35), ensure that the CA certificate manager approval check box is selected. For Require the following for reenrollment, ensure that the Valid existing certificate option is set.

    c2ba59ce-b12a-4c52-bd5e-e9992a69bd55Figure 35: Configuring Issuance Requirement Settings

    Note

    Depending on the security policy of your organization, you may choose to use different issuance settings. For example, you may choose to require one or more authorized signatures for certificate issuance, or that the same approval process be used for certificate reenrollment.

  13. On the Extensions tab, in the Extensions included in this template box, select Application policies, and then click Edit.

  14. In the Edit Application Policies Extension dialog box, in the Application policies box, select Certificate Request Agent, and then click Remove.

  15. In the Edit Application Policies Extension dialog box, click Add.

  16. In the Add Application Policy dialog box, in the Application Policies box, select Qualified Subordination, and then click OK.

    Note

    Alternatively, you could create a custom application policy with its own assigned OID. This will require a modification later in the process where you will configure the XXXX Certificate template to require your custom application policy for a signature.

  17. In the Edit Application Policies Extension dialog box, ensure that Qualified Subordination is the only policy that appears in the Application policies dialog box, and then click OK.

  18. On the Security tab, ensure that only Domain Admins and Enterprise Admins have the Enroll permission for the certificate template. Alternatively, you can create a custom security group and only assign that security group the Enroll permission.

  19. Click OK to apply all configuration changes to the certificate template.

Modifying the Cross-Certification Authority version 2 Certificate Template

Once the qualified subordination signing template is created, the cross-certification authority certificate template must be modified.

  1. In the Certificate Templates console, in the details pane, double-click the Cross Certification Authority certificate template.

  2. In the Cross-Certification Authority Properties dialog box, on the Issuance Requirements tab (Figure 36), make the following changes:

    867b3882-0805-42bd-9999-895e18ffe611Figure 36: Modifying the Issuance Requirements for the Cross CA Certificate

    • This number of authorized signatures A request can be configured to require more than one signature for issuance. You should require at least one signature.

    • Application Policy If a custom application policy was created, change the default application policy from Qualified Subordination to the logical name you created for your custom application policy.

  3. Click OK.

  4. Close the Certificate Templates console

Important

By default, the CrossCA template is defined to publish to Active Directory when issued. Ensure that the certificate is formatted and configured properly before issuing. Invalid or unintended constraints may cause unwanted behavior in the environment and pose security risks, if not properly prepared.

Configuring Windows Server 2003 Enterprise Edition to Issue the Certificate Templates

Since only Windows Server 2003 Enterprise Edition supports version 2 certificate templates, it is required for the certificate deployment. The Windows Server 2003 Enterprise Edition must be configured to issue both the Qualified Subordination Signing and cross-certification authority certificate templates.

  1. Log on as a CA Administrator at Windows Server 2003 Enterprise Edition running Certificate Services configured as an Enterprise CA.

  2. On the Start menu, point to Programs, point to Administrative Tools, and then click Certification Authority.

  3. In the console tree, expand CAName (where CAName is the logical name assigned to your CA).

  4. In the console tree, right-click Certificate Templates, point to New, and then click Certificate Template to Issue.

  5. In the Enable Certificate Templates dialog box (Figure 37), in the list of available templates, click Cross-Certification Authority, control-click Qualified Subordination Signing, and then click OK.

    b2c1aa45-2f55-4800-a1cc-04f53f6629faFigure 37: Loading the Cross-Certification Authority and Qualified Subordination Signing Certificates

  6. In the details pane, ensure that the Cross-Certification Authority and Qualified Subordination Signing certificate appear.

  7. Close the Certification Authority console.

Acquiring the Qualified Subordination Signing Certificate

Although you typically request certificates from an Enterprise CA using the Certificates MMC console, the requirement for CA Certificate manager approval in the Qualified Subordination Signing certificate template makes the use of the Certificate Services Web enrollment pages the better method to acquire the Qualified Subordination Signing certificate.

Performing the Initial Certificate Request

To perform the initial request for a qualified subordination signing certificate

  1. Ensure that you are logged on as a user with the Enroll permissions for the Qualified Subordination Signing Certificate template.

  2. Start Internet Explorer.

  3. Open the https://CAMachineName/certsrv URL (where CAMachineName is the name of the Windows Server 2003 Enterprise Edition configured to issue the Qualified Subordination Signing Certificates).

  4. On the Welcome page, click Request a certificate.

  5. On the Request a Certificate page, click advanced certificate request.

  6. On the Advanced Certificate Request page, click Create and submit a request to this CA.

  7. On the Advanced Certificate Request page, in the Certificate Template section, select Qualified Subordination Signing from the list.

  8. In the Key Options section, set the following options:

    • Create a new key set

    • CSP: Microsoft Enhanced Cryptographic Provider v1.0 (or a different CSP if you are using a hardware CSP).

    • Key Usage: Signature

    • Automatic Key container name

    • Mark keys as exportable: unchecked

    • Enable strong private key protection: unchecked

    • Use local machine store: unchecked

  9. In the Additional Options section, set the following options:

    • Request format: CMC

    • Hash Algorithm: SHA-1

    • Save request to a file: unchecked

    • Attributes: empty

    • Friendly name: Qualified Subordination Signing

  10. Review the entries, and then click Submit.

    The Certificate Pending page appears.

Issuing the Pending Certificate Request

The certificate request is set to a pending status by default on a stand-alone CA. To issue the certificate, a CA administrator must use the Certification Authority console.

  1. Ensure that you are logged on to the Windows Server 2003 Enterprise Edition as a CA Certificate Manager.

  2. On the Start menu, point to Programs, point to Administrative Tools, and then click Certification Authority.

  3. In the console tree, click the Pending Requests container.

  4. In the details pane, right-click the certificate request for a Qualified Subordination Signing certificate, point to All Tasks, and then click Issue.

  5. Close the Certification Authority console.

Installing the Qualified Subordination Signing Certificate

The final step is to install the issued certificate.

  1. At the computer where the original certificate request was performed, log on as the user who made the Qualified Subordination Signing certificate request.

  2. In Internet Explorer, open the https://CAMachineName/certsrv/ URL (where CAMachineName is the name of the Windows Server 2003 Enterprise Edition configured to issue the Qualified Subordination Signing Certificates).

  3. On the Welcome page, click View the status of a pending certificate request.

  4. On the View the status of a pending certificate request page, click the QualifiedSubordinationSigning Certificate (Date and Time) link.

  5. On the Certificate Issued page, click Install this certificate.

    The Certificate Installed page should appear.

  6. Close Internet Explorer.

Verifying the Qualified Subordination Signing Certificate

Once you have installed the qualified subordination certificate, you should view the certificate to ensure that it is correctly configured.

  1. Open an empty MMC console.

  2. On the File menu, click Add/Remove Snap-in.

  3. In the Add/Remove Snap-in dialog box, click Add.

  4. In the Add Standalone Snap-in dialog box, select Certificates, and then click Add.

  5. In the Certificates snap-in dialog box, click My user account, and then click Finish.

  6. In the Add Standalone Snap-in dialog box, click Close.

  7. In the Add/Remove Snap-in dialog box, click OK.

  8. In the console tree, expand Certificates – Current User, expand Personal, and then click Certificates.

  9. In the details panel, double-click the certificate with the template Friendly Name of Qualified Subordination Signing.

  10. In the Certificate dialog box, on the General tab, ensure that the intended purposes only list Qualified Subordination.

    Note

    If you used a custom application policy, then the name of this application policy and its OID will appear instead of Qualified Subordination.

  11. In the Certificate dialog box, on the Details tab, ensure that the Key Usage indicates Digital Signature (80).

  12. Click OK.

  13. Close the console without saving the changes.

Performing Cross-Certification

Once the qualified subordination signing certificate is successfully installed, you can now request the Cross-Certification Authority certificate from the other CA. In this example, the following CAs shown in Figure 38 will be used.

faf84134-bfa9-4bdd-ba71-a7afb98aa318

Figure 38: Performing the Cross-Certification

Gathering the Necessary Files

The first cross-certification request is to be run from the F1CA certification authority. To perform the qualified subordination, the following is required at the F1CA before starting the process:

  • The CA certificate from F2Root.

  • The Policy.inf file configured at the F1CA defining the naming constraints, policy constraints, and application constraints defined for the qualified subordination.

  • The user performing the qualified subordination must have a qualified subordination signing certificate issued by F1CA.

Generating the Cross-Certification Authority Certificate Request

Once these items are obtained, the following procedure is used to obtain a Cross-Certification Authority certificate for F2Root from F1CA. The request is performed using Certreq.exe, a command-line tool used from the Windows Server 2003 administrative tools pack that requests certificates from the command line.

Important

The constraints defined in Policy.inf are enforced at the signing CA where you generate the request, not at the CA whose CA certificate you use during the request. It is also important to generate the cross-certificate request in the domain in which the cross-cert will be issued.

  1. Copy the F2Root certificate and the Policy.inf file into a folder on the F1CA computer.

  2. Open a command prompt window.

  3. Make the folder containing the F2Root certificate and the Policy.inf file the current directory.

  4. Run certreq.exe –policy. This command constructs a cross-certification or qualified subordination request from an existing CA certificate or from an existing request.

    Note

    If creating a cross-certificate request from a stand-alone CA to an Enterprise CA, the following command must be specified to include the proper CrossCA template name in the template. Example:

    certreq –policy –attrib CertificateTemplate:CrossCA  <CatoXcertify> <inf
file> <CMCoutFile>

  5. In the Open Request File dialog box (Figure 39), in the Files of Type box, select Certificate Files (*.cer, *.crt, *.der), select the requesting CAs certificate (RackCluster3_F2Root in this example), and then click Open.

    5f5d95cb-b270-4888-b549-6031a9da0c56Figure 39: Selecting the Target CAs Certificate

  6. In the Open Inf File dialog box (Figure 40), select the configured Policy.inf file, and then click Open.

    c03095db-3857-489a-b4ce-0bb25866bb8aFigure 40: Selecting the Policy.inf File

    Note

    You do not have to name the file Policy.inf. In this example, the file was named xrossForest2.inf to aid in determining which Policy.inf file was required.

  7. In the Certificate List dialog box (Figure 41), select the Qualified Subordination certificate that you requested earlier, and then click OK.

    8143be9c-dcaf-408f-895f-ecb05b22f498Figure 41: Selecting the Qualified Subordination Signing Certificate

  8. In the Save Request dialog box (Figure 42), in the File name box, type a name describing the Cross-Certification Authority certificate request, and then click Save.

    bde99310-144b-415a-af2b-e7c8eda48fd6Figure 42: Saving the Request File

Processing the Cross-Certification Authority Certificate Request

At the F1CA, the final step is to process the Cross-Certification Authority certificate request file.

  1. In Administrative Tools, open Certification Authority.

  2. In the console tree, right-click CAName (where CAName is the name of your CA), point to All Tasks, and then click Submit New Request.

  3. In the Open Request File dialog box (Figure 43), select the request file that you created in the previous process, and then click Save.

    8071b44f-3a3a-4dcd-81a8-21c8854d79e8Figure 43: Choosing the Request File

  4. In the Save Certificate dialog box, indicate the name of the Certificate File, and then click Save.

    The certificate file is automatically published into Active Directory, so that the clients in Forest1 can validate certificates issued by the CAs in Forest2.

Verifying the Existence of the Cross Certificate

The final step is verifying that the certificate has been successfully published into Active Directory. This process uses Certutil.exe to verify the existence of the cross certificate. The following walkthrough validates the certificate with subject name ASIA SA Root CA that was issued by the Microsoft Intranet CA.

  1. Open a command prompt window.

  2. Type certutil -viewstore "CN=<CAName>,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=<ForestRootDN>?crossCertificatePair

    Where:

    • <CAName> The name of the CA that is issued the cross-certification authority certification. This is the subject of the cross-certification authority certificate.

    • <ForestRootDN> The name of the forest root LDAP distinguished name. This is the forest in which the cross-certification authority certificate exists.

    In this example, the following command was used:

    certutil -viewstore "CN=ASIA SA Root CA,CN=AIA,CN=Public Key
Services,CN=Services,CN=Configuration,DC=corp,DC=microsoft,DC=com?crossCertificatePair

    Note

    If the subject name of the CA being cross-certified does not have CN= in the subject name, the Windows Server 2003 CA will generate a hash of the binary name of the CA and publish the cross certificate to that name. For example, to perform the command in the previous step in this case, the syntax would be similar to the following where the common name is the hash of the CA name:

    certutil -viewstore
CN=12d2cb85c5e62f9aa7591e2ddaa44c987de5abbc,CN=AIA,CN=Public Key
Services,CN=Services,CN=Configuration,DC=ntdev,DC=corp,DC=microsoft,DC=com

  3. In the View Certificate Store window (Figure 44), all cross-certification authority certificates with the <CAName> in the subject name are listed.

    b872d22c-3e0e-4366-8627-130dc6fb8c8bFigure 44: The Cross-Certification Authority Certificates List

    Note

    Multiple cross-certification authority certificates can exist when the cross-certification authority certificate is renewed when the previous certificate expires.

  4. In the View Certificate Store dialog box, select the cross-certification authority certificate that you wish to view, and then click View Certificate.

  5. In the Certificate dialog box, click the Certification Path tab.

  6. On the Certification Path tab (Figure 45), ensure that the certification path is the correct path. In this example, the chain is correct, as it shows the ASIA SA Root CA chaining to the Microsoft Corporate Root Authority.

    a6cca3d0-2f9b-47ff-9615-3fe2f23a58d8Figure 45: Validating the Certification Path of the Cross-Certification Authority Certificate

  7. In the Certificate dialog box, click OK.

  8. In the View Certificate Store dialog box, click OK.

  9. Close the command prompt window.

When cross-certifying with some third-party certification authorities, you may have to specify where to retrieve additional cross certificates associated with the issuer of a presented certificate. Typically, a certificate will have a cross-certificate URL encoded in the certificate, but in some cases, you may need to specify additional URLs.

To add the additional URLs

  1. Open a blank MMC console.

  2. On the File menu, click the Add/Remove snap-in.

  3. In the Add/Remove snap-in dialog box, click Add.

  4. In the Add Standalone Snap-in dialog box, select Certificates, and then click Add.

  5. In the Certificates snap-in dialog box, select either My user account, Service account, or computer account, based on whether the certificate that must chain using a cross certificate is issued to the computer, a service, or to your user account, and then click Finish.

    Note

    If you are not an Administrator of the local computer, you will automatically load the Certificates console focused on My user account.

  6. In the console tree, expand Certificates – Current User, expand Personal, and then click Certificates.

  7. In the details pane, right-click the certificate that must be cross-certified, and then click Properties.

  8. In the Certificate Properties dialog box, click the Cross-Certificates tab.

  9. In the Cross-Certificates tab (Figure 46), select the Specify additional Cross-Certificate download locations check box. In addition, you can now do the following:

    d87495ea-4856-47ce-ac19-7c1bd0bd6b11Figure 46: Defining Manual Cross-Certificate Download Locations

    • Define the Cross-Certificate download interval. The default is every eight hours.

    • Add URLs for Cross-Certificate download locations. The URL can be an LDAP, HTTP, FTP, or FILE location.

Completing Cross-Certification

The cross-certification must be performed in the opposite direction to ensure that all certificates issued in both organizations are trusted. This requires that the same process be performed at F2CA using the F1Root certificate.

Completing the Cross-Certification When a Bridge CA Is Implemented

An additional process must be performed when a Bridge CA is used. The certificates that are issued by the BridgeCA must be published in all forests that are connected to the BridgeCA to allow all certificates to be recognized by the organizations using the bridge.

  1. From the BridgeCA, copy all issued CrossCA certificates to a common share point.

  2. At the first forest connected to the bridge, run Certutil –dspublish –f cert1.crt CrossCA (where cert1.crt is the first crossCA cert).

  3. Repeat the process for all certificates issued by the Cross CA, at all forests connected to the Bridge CA.