Swedish Windows Security User Group

Jonathan Stephens posted an excellent Blog about this topic; however, it didn’t include the steps. As a result, I decided to type this Blog detailing the steps required. The following assumptions have to be met before proceeding with these steps:

1- There is a new valid Certification Authority configured

2- There is a new distribution point configured for AIA and CDP locations named http://crl.contoso.com/CertData

Steps:

1- Logon to the old Enterprise Certification Authority as an Enterprise Administrator.

2- Identify the AIA and CDP distribution points

1. a. Open the Certification Authority Console
2. b. Right click the Certification Authority name and click Properties
3. c. Click the “Extensions” tab
4. d. Document the distribution points configured for CRL Distribution Point (CDP) – as an example http://<serverDNSnname>/CertEnroll/<CANAME>CRLNameSuffix><DeltaCRLAllowed>.crl which refers to local IIS installed on the server, or http://pki.contoso.com/Certenroll/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl

Note: Ignore the LDAP and C:\%windir% locations

1. e. In the “Extensions” tab, select Authority Information Access (AIA) from the drop down menu
2. f.  Document the distribution points configured for the AIA extensions – as an example http://<ServerDNSName>/Certenroll/<ServerDNSName>_<CAName><CertificateName>.crt  which refers to the local IIS installed on the server or http://pki.contoso.com/Certenroll/<ServerDNSName>_<CAName><CertificateName>.crt

Note: Ignore the LDAP and C:\%windir% locations

3- Disable Delta CRL and Issue a long Certificate Revocation List (CRL)

1. a. Open the Certification Authority Console
2. b. Right click “Revoked Certificates”, and then click “Properties”
3. c. Uncheck “Publish Delta CRL”
4. d. Change the “CRL publication Interval” to 99 years and then click OK
5. e. Open the command line with elevated privileges
6. f.  Run Certutil –crl  to issue a new Certificate Revocation List (CRL)

4- Copy the old Certification Authority’s certificate (CRT) and certificate revocation list (CRL) files to the server hosting website http://crl.contoso.com/CertData 

1. a. On the old Certification Authority, navigate to %windir%\System32\CertSrv\CertEnroll
2. b. Copy the Certification Authority’s certificate (CRT) and certificate revocation list (CRL) to the directory hosting http://crl.contoso.com/CertData

5- Redirect the Authority Information Access (AIA) and Certificate Revocation List (CRL) distribution points  of the old Certification Authority to http://crl.contoso.com/certdata

1. a. This can be done using an IIS redirect, or a DNS CNAME redirect to redirect Authority information Access (AIA) and Certificate Revocation List (CRL) of the old Certification Authority documented in steps 2.d and 2.f to the new web server http://crl.contoso.com/certdata

6- Document and remove all  certificate templates available on the old Certification Authority to prevent it from issuing new certificates

1. a. Open the command line with elevated privileges
2. b. Run Certutil –catemplates > c:\catemplates.txt  to document all available certificate templates at the old Certification Authority
3. c. Launch the Certification Authority console
4. d. Navigate to “Certificate Templates”
5. e. Highlight all templates in the right pane, right click and then click “Delete”

At this point, the old Certification Authority can’t issue any certificates, and has all of its Authority Information Access (AIA) and Certificate Revocation List (CRL) redirected to a new web site http://crl.contoso.com/CertData The next steps will detail how to document the certificates issued by templates from the old Certification Authority and how to make them available at the new Certification Authority.

7- Identify and document the certificates issued based on certificate templates by sorting the Certification Authority database

1. a. Highlight “Issued Certificates”
2. b. Navigate to the right, and sort by “Certificate Templates”
3. c. Identify the certificates issued by default certificate template types
4. d. Identify the certificates issued by custom certificate templates – any template other than the default certificate templates mentioned earlier

8- Dump the certificates based on the default certificate template types:

1. a. Open the command line with elevated privileges
2. b. Run Certutil -view -restrict “Certificate Template=Template” -out “SerialNumber,NotAfter,DistinguishedName,CommonName” > c:\TemplateType.txt
3. c. Examine the output of c:\TemplateType.txt and document all the certificates needing immediate action – i.e. requiring issuance from the new CA infrastructure if needed such as Web SSL.
4. d. Consult with the application administrator using the certificates to determine the best approach to replace the certificates if needed

Note: Replace Template with the correct template name.

9- Dump the certificates based on the custom certificate template types:

1. a. Open the Certification Authority Console
2. b. Right click “Certificate Templates” and click “Manage”
3. c. Double click the certificate template and click on “Extensions” tab
4. d. Click on “Certificate Template Information”
5. e. Copy the Object Identifier (OID) number – the number will look similar to 1.3.6.1.4.1.311.21.8.12531710.13924440.6111642.16676639.10714343.69.16212521.10022553
6. f. Open the command line with elevated privileges
7. g. Run Certutil -view -restrict “Certificate Template=OIDNumber” -out “SerialNumber,NotAfter,DistinguishedName,CommonName” > c:\CustomTemplateType.txt

Note: Replace OIDNumber with the number identified in step 9.e

1. h. Examine the output of c:\CustomTemplateType.txt and document all the certificates needing immediate action – i.e. requiring issuance from the new CA infrastructure if needed such as custom SSL certificates.
2. i. Consult with the application administrator using the certificates to determine the best approach to replace the certificates if needed

Note: You don’t need to take any action if the certificate was auto-enrolled because the certificate holder will renew the certificate when it expires from the new CA infrastructure.

10- Enable the Certificate Templates needed based on the results of steps 7-9 on the new Certification Authority

1. a. Logon to the new Certification Authority as an Enterprise Administrator
2. b. Right Click “Certificate Templates”, click “New” and then click “Certificate Template to Issue”
3. c. Choose all the certificate templates needed in the “Enable Certificate Templates” window and click “OK”

11- <Optional> At this point you can uninstall the Certification Authority Role on the old Certification Authority

1. a. Backup the old Certification Authority using the steps outlined in Disaster Recovery Procedures for Active Directory Certificate Services (ADCS)
2. b. Uninstall Certificate Services from the old Certification Authority
3. c. Decommission the server unless it is running other applications

12- Once all certificates are issued by the new infrastructure, you can safely remove all the Authority Information Access (AIA) and Certificate Revocation List (CRL) files from you infrastructure by following the steps in How to Decommission a Windows Enterprise Certification Authority and How to Remove All Related Objects and from the web server hosting http://crl.contoso.com

 

Amer F. Kamal

Senior Premier Field Engineer

Jonathan Stephens posted an excellent Blog about this topic; however, it didn’t include the steps. As a result, I decided to type this Blog detailing the steps required. The following assumptions have to be met before proceeding with these steps:

1- There is a new valid Certification Authority configured

2- There is a new distribution point configured for AIA and CDP locations named http://crl.contoso.com/CertData

Steps:

1- Logon to the old Enterprise Certification Authority as an Enterprise Administrator.

2- Identify the AIA and CDP distribution points

1. a. Open the Certification Authority Console
2. b. Right click the Certification Authority name and click Properties
3. c. Click the “Extensions” tab
4. d. Document the distribution points configured for CRL Distribution Point (CDP) – as an example http://<serverDNSnname>/CertEnroll/<CANAME>CRLNameSuffix><DeltaCRLAllowed>.crl which refers to local IIS installed on the server, or http://pki.contoso.com/Certenroll/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl

Note: Ignore the LDAP and C:\%windir% locations

1. e. In the “Extensions” tab, select Authority Information Access (AIA) from the drop down menu
2. f.  Document the distribution points configured for the AIA extensions – as an example http://<ServerDNSName>/Certenroll/<ServerDNSName>_<CAName><CertificateName>.crt  which refers to the local IIS installed on the server or http://pki.contoso.com/Certenroll/<ServerDNSName>_<CAName><CertificateName>.crt

Note: Ignore the LDAP and C:\%windir% locations

3- Disable Delta CRL and Issue a long Certificate Revocation List (CRL)

1. a. Open the Certification Authority Console
2. b. Right click “Revoked Certificates”, and then click “Properties”
3. c. Uncheck “Publish Delta CRL”
4. d. Change the “CRL publication Interval” to 99 years and then click OK
5. e. Open the command line with elevated privileges
6. f.  Run Certutil –crl  to issue a new Certificate Revocation List (CRL)

4- Copy the old Certification Authority’s certificate (CRT) and certificate revocation list (CRL) files to the server hosting website http://crl.contoso.com/CertData 

1. a. On the old Certification Authority, navigate to %windir%\System32\CertSrv\CertEnroll
2. b. Copy the Certification Authority’s certificate (CRT) and certificate revocation list (CRL) to the directory hosting http://crl.contoso.com/CertData

5- Redirect the Authority Information Access (AIA) and Certificate Revocation List (CRL) distribution points  of the old Certification Authority to http://crl.contoso.com/certdata

1. a. This can be done using an IIS redirect, or a DNS CNAME redirect to redirect Authority information Access (AIA) and Certificate Revocation List (CRL) of the old Certification Authority documented in steps 2.d and 2.f to the new web server http://crl.contoso.com/certdata

6- Document and remove all  certificate templates available on the old Certification Authority to prevent it from issuing new certificates

1. a. Open the command line with elevated privileges
2. b. Run Certutil –catemplates > c:\catemplates.txt  to document all available certificate templates at the old Certification Authority
3. c. Launch the Certification Authority console
4. d. Navigate to “Certificate Templates”
5. e. Highlight all templates in the right pane, right click and then click “Delete”

At this point, the old Certification Authority can’t issue any certificates, and has all of its Authority Information Access (AIA) and Certificate Revocation List (CRL) redirected to a new web site http://crl.contoso.com/CertData The next steps will detail how to document the certificates issued by templates from the old Certification Authority and how to make them available at the new Certification Authority.

7- Identify and document the certificates issued based on certificate templates by sorting the Certification Authority database

1. a. Highlight “Issued Certificates”
2. b. Navigate to the right, and sort by “Certificate Templates”
3. c. Identify the certificates issued by default certificate template types
4. d. Identify the certificates issued by custom certificate templates – any template other than the default certificate templates mentioned earlier

8- Dump the certificates based on the default certificate template types:

1. a. Open the command line with elevated privileges
2. b. Run Certutil -view -restrict “Certificate Template=Template” -out “SerialNumber,NotAfter,DistinguishedName,CommonName” > c:\TemplateType.txt
3. c. Examine the output of c:\TemplateType.txt and document all the certificates needing immediate action – i.e. requiring issuance from the new CA infrastructure if needed such as Web SSL.
4. d. Consult with the application administrator using the certificates to determine the best approach to replace the certificates if needed

Note: Replace Template with the correct template name.

9- Dump the certificates based on the custom certificate template types:

1. a. Open the Certification Authority Console
2. b. Right click “Certificate Templates” and click “Manage”
3. c. Double click the certificate template and click on “Extensions” tab
4. d. Click on “Certificate Template Information”
5. e. Copy the Object Identifier (OID) number – the number will look similar to 1.3.6.1.4.1.311.21.8.12531710.13924440.6111642.16676639.10714343.69.16212521.10022553
6. f. Open the command line with elevated privileges
7. g. Run Certutil -view -restrict “Certificate Template=OIDNumber” -out “SerialNumber,NotAfter,DistinguishedName,CommonName” > c:\CustomTemplateType.txt

Note: Replace OIDNumber with the number identified in step 9.e

1. h. Examine the output of c:\CustomTemplateType.txt and document all the certificates needing immediate action – i.e. requiring issuance from the new CA infrastructure if needed such as custom SSL certificates.
2. i. Consult with the application administrator using the certificates to determine the best approach to replace the certificates if needed

Note: You don’t need to take any action if the certificate was auto-enrolled because the certificate holder will renew the certificate when it expires from the new CA infrastructure.

10- Enable the Certificate Templates needed based on the results of steps 7-9 on the new Certification Authority

1. a. Logon to the new Certification Authority as an Enterprise Administrator
2. b. Right Click “Certificate Templates”, click “New” and then click “Certificate Template to Issue”
3. c. Choose all the certificate templates needed in the “Enable Certificate Templates” window and click “OK”

11- <Optional> At this point you can uninstall the Certification Authority Role on the old Certification Authority

1. a. Backup the old Certification Authority using the steps outlined in Disaster Recovery Procedures for Active Directory Certificate Services (ADCS)
2. b. Uninstall Certificate Services from the old Certification Authority
3. c. Decommission the server unless it is running other applications

12- Once all certificates are issued by the new infrastructure, you can safely remove all the Authority Information Access (AIA) and Certificate Revocation List (CRL) files from you infrastructure by following the steps in How to Decommission a Windows Enterprise Certification Authority and How to Remove All Related Objects and from the web server hosting http://crl.contoso.com

 

Amer F. Kamal

Senior Premier Field Engineer

Background

On December 1, 2010 the Federal PKI Management Authority (FPKIMA), in compliance with NIST guidance, created a new SHA-256 Federal Common Policy root certification authority. Windows Update will include the new Federal Common Policy Root CA (FCPCA) certificate as part of the Microsoft Root Certificate Program on March 22, 2011. The FPKIMA will not be publishing the FCPCA certificate to subordinate certificates’ Authority Information Access locations (http://http.fpki.gov/fcpca/caCertsIssuedTofcpca.p7c). Therefore it is critical that the FCPCA certificate is deployed to systems Trusted Root Certification Authorities store to enable U.S. Federal PKI applications. The goal of this blog entry is to explain the new Federal Common Policy CA architecture, the Windows Update Root Certificate deployment process, and methods used to deploy the new Federal Common Policy CA certificate within your enterprise environments.

Federal PKI Architecture

Click the picture to maximize it to its original size.

Federal Common Policy CA Certificate

AIA:

• http://http.fpki.gov/fcpca/caCertsIssuedTofcpca.p7c
• ldap://ldap.fpki.gov/cn=Federal%20Common%20Policy%20CA,ou=FPKI,o=U.S. %20Government,c=US

CRL:

• http://http.fpki.gov/fcpca/fcpca.crl
• ldap://ldap.fpki.gov/cn=Federal%20Common%20Policy%20CA,ou=FPKI,o=U.S. %20Government,c=US

Make sure your firewalls are configured to allow the downloading of these certificates and CRLs.

Legacy SHA1 Support

The FPKIMA has also stood up a new SHA-1 certification authority (SHA-1 FRCA), subordinate to the old Common Policy, to support legacy SHA-1 certificates (e.g. HSPD-12 SHA-1 smart cards). Existing subordinate CAs to the Common Policy whose users still require a pure SHA-1 certificate path have since been issued cross certificates signed by the SHA1-FRCA. The certificates issued to these CAs from the old Common Policy CA will be revoked and published to the final Common Policy certificate revocation list (CRL). The final Common Policy CRL will not have a Next Update field and will be removed when all SHA-1 authority to operate extensions have expired. The new Federal Common Policy CA has signed a cross certificate to the SHA-1 FRCA as well.

The SHA-1 FRCA certificate will not be distributed by the Windows Update program and the certificate should be placed in a computer requiring pure SHA-1 chaining Trusted Root Certification Authorities store.

Chaining to old Common Policy

The old Common Policy CA has issued a cross certificate to the new Federal Common Policy CA to allow for the chaining to a root trust point prior to the deployment of the new Federal Common Policy CA certificate.

Enhanced Key Usage

The Enhanced Key Usage field defines one or more purposes for which the public key may be used. RFC 5280 states “in general, [sic] the EKU extension will appear only in end entity certificates.” Certification authorities’ certificates may contain EKU entries. To allow smart card logon within an Active Directory domain the smart card’s chain of trust must support the Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication (OID 1.3.6.1.5.5.7.3.2) application policies. Active Directory smart card logon is supported with the following EKU configurations:

• All certificates in the chain of trust do not assert Enhanced Key Usage (except for the end entity certificate) the anyExtendedKeyUsage EKU is implied.
• All certificates in the chain of trust do not assert Enhanced Key Usage except for the root trust point certificate. Root trust point EKU field asserts Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication (OID 1.3.6.1.5.5.7.3.2).
• All certificates in the chain of trust Enhanced Key Usage field assert Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication (OID 1.3.6.1.5.5.7.3.2).

Best practice is for the root trust point certificate not to include an Enhanced Key Usage extension. The Federal Common Policy CA certificate does not assert an EKU; therefore all application policies are implied.

Deployment methods

Windows Update

The Microsoft Root Certificate Program is a mechanism Microsoft provides to distribute root certificates via the Windows Update program. The intent of the Program is to enable PKI scenarios for the mass consumer market such as e-commerce, secure e-mail, and code signing. It is not intended to enable enterprise-only scenarios (e.g. smart card logon). The Program attaches a certificate’s EKU as metadata in the Windows certificate store.

The behavior of Windows Update placing certificates in the Trusted Root Certification Authorities store can be controlled by the group policy setting Turn off Automatic Root Certificates Update (Computer Configuration -> Policies -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication settings).

The Federal Common Policy CA certificate to be deployed via the Windows Update Root Certificate Program will not contain the smart card logon OID required to enable HSPD-12 smart card logon within an enterprise environment. The smart card logon purpose must be added to the Federal Common Policy CA certificate contained within the authenticating domain controller’s Trusted Root Certification Authorities store. The domain controller is the Kerberos Key Distribution Center and performs the certificate path / policy validation and certificate revocation checks. In large scale environments modifying every domain controller’s Federal Common Policy CA certificate EKU can become an arduous task.

Group Policy and Enterprise Root CA Store

There are two methods (Group Policy and Enterprise Trusted Root Certification Authorities store) available to enterprise administrators to distribute the Federal Common Policy CA certificate to all systems within an Active Directory domain. Both deployment methods use the auto-enrollment mechanism which is traditionally controlled within the Default Domain and Default Domain Controllers Policies (Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Public Key Policies -> Certificate Services Client: Auto-Enrollment).

Group Policy publication of certificates to domain computers’ Trusted Root Certification Authorities certificate store provides the ability to manipulate a certificate’s Enhanced Key Usage field. This method of deployment must be used if the root trust point certificate does not contain the EKU OIDs necessary for smart card logon.

Since the Federal Common Policy CA certificate does not have an Enhanced Key Usage extension ‘any policy’ is implied (“All application policies”). This certificate can be published to the Active Directory forest’s Trusted Root Certification Authorities store. The Federal Common Policy CA certificate will then be pushed to all domain joined computers.

To publish a certificate to the Active Directory forest’s Trusted Root Certification Authorities store type the following command with Enterprise Administrator rights certutil -f -dspublish FederalCommonPolicyCA.cer RootCA. To view the contents of the Enterprise Trusted Root Certification Authorities store type certutil -viewstore -enterprise root.

Removal of the old Common Policy Certificates

The method of removal for the old Common Policy certificates is dependent upon how the certificates were originally placed in the store:

• Group Policy – remove the Common Policy certificates from the group policy that distributes them. The next group policy refresh will remove the certificates.
• Enterprise Certificate Store – with Enterprise Administrator rights type certutil -viewdelstore -enterprise root, select the Common Policy certificate and select OK.
• Windows Update
  • Manually remove certificates – MMC -> Add/Remove Snap-In -> Certificates -> Computer Account -> <select Local or remote computer> -> Certificates -> Trusted Root Certification Authorities -> Certificates -> Right click, Delete
  • Powershell – The following PowerShell script takes two command line arguments ComputerName and CertificateSerialNumber. Save the PowerShell script into a file named “delete_cert.ps1”. For example to remove the Common Policy certificate from a computer named DC1 the command would be ./delete_cert.ps1 DC1 39e3815404c50ab247effef336cfc698

Automatic Root Certificates Update Behavior on Vista and Higher Operating Systems

If the group policy setting Turn off Automatic Root Certificates Update (Computer Configuration -> Policies -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication settings) is not enabled on Vista and higher operating systems the new Federal Common Policy CA certificate will appear in the Trusted Root Certification Authorities store after a chaining event. If you delete the old Common Policy certificate it may reappear in the computer’s certificate store. When a chaining operation occurs and the root certificate is not in the computer’s Trusted Root Certification Authorities store, the system will call Windows Update to retrieve the root trust certificate. Even if there is no network connectivity to the Windows Update site the system’s crypt32.dll contains root certificates that were published via Windows Update when the operating system was released to market. The root certificate will be retrieved and placed in the computer’s Trusted Root Certification Authorities store.

Intermediate Certification Authorities

To facilitate chaining all intermediate certification authorities’ certificates can be distributed within the enterprise environment. Consult with your HSPD-12 Share Service Provider (SSP) before deploying to identify any potential chaining issues during this transition period.

More Information

• Microsoft officially supports SHA-256 starting with the Vista operating system. Here is a TechNet PKI Blog entry explaining what operating systems and applications work with SHA-256 prior to the release of Vista. Please note this is not an assertion of what is supported but more of what has been tested and works.
• How to configure your environment to support HSPD-12 smartcard logon.

Background

On December 1, 2010 the Federal PKI Management Authority (FPKIMA), in compliance with NIST guidance, created a new SHA-256 Federal Common Policy root certification authority. Windows Update will include the new Federal Common Policy Root CA (FCPCA) certificate as part of the Microsoft Root Certificate Program on March 22, 2011. The FPKIMA will not be publishing the FCPCA certificate to subordinate certificates’ Authority Information Access locations (http://http.fpki.gov/fcpca/caCertsIssuedTofcpca.p7c). Therefore it is critical that the FCPCA certificate is deployed to systems Trusted Root Certification Authorities store to enable U.S. Federal PKI applications. The goal of this blog entry is to explain the new Federal Common Policy CA architecture, the Windows Update Root Certificate deployment process, and methods used to deploy the new Federal Common Policy CA certificate within your enterprise environments.

Federal PKI Architecture

Click the picture to maximize it to its original size.

Federal Common Policy CA Certificate

AIA:

• http://http.fpki.gov/fcpca/caCertsIssuedTofcpca.p7c
• ldap://ldap.fpki.gov/cn=Federal%20Common%20Policy%20CA,ou=FPKI,o=U.S. %20Government,c=US

CRL:

• http://http.fpki.gov/fcpca/fcpca.crl
• ldap://ldap.fpki.gov/cn=Federal%20Common%20Policy%20CA,ou=FPKI,o=U.S. %20Government,c=US

Make sure your firewalls are configured to allow the downloading of these certificates and CRLs.

Legacy SHA1 Support

The FPKIMA has also stood up a new SHA-1 certification authority (SHA-1 FRCA), subordinate to the old Common Policy, to support legacy SHA-1 certificates (e.g. HSPD-12 SHA-1 smart cards). Existing subordinate CAs to the Common Policy whose users still require a pure SHA-1 certificate path have since been issued cross certificates signed by the SHA1-FRCA. The certificates issued to these CAs from the old Common Policy CA will be revoked and published to the final Common Policy certificate revocation list (CRL). The final Common Policy CRL will not have a Next Update field and will be removed when all SHA-1 authority to operate extensions have expired. The new Federal Common Policy CA has signed a cross certificate to the SHA-1 FRCA as well.

The SHA-1 FRCA certificate will not be distributed by the Windows Update program and the certificate should be placed in a computer requiring pure SHA-1 chaining Trusted Root Certification Authorities store.

Chaining to old Common Policy

The old Common Policy CA has issued a cross certificate to the new Federal Common Policy CA to allow for the chaining to a root trust point prior to the deployment of the new Federal Common Policy CA certificate.

Enhanced Key Usage

The Enhanced Key Usage field defines one or more purposes for which the public key may be used. RFC 5280 states “in general, [sic] the EKU extension will appear only in end entity certificates.” Certification authorities’ certificates may contain EKU entries. To allow smart card logon within an Active Directory domain the smart card’s chain of trust must support the Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication (OID 1.3.6.1.5.5.7.3.2) application policies. Active Directory smart card logon is supported with the following EKU configurations:

• All certificates in the chain of trust do not assert Enhanced Key Usage (except for the end entity certificate) the anyExtendedKeyUsage EKU is implied.
• All certificates in the chain of trust do not assert Enhanced Key Usage except for the root trust point certificate. Root trust point EKU field asserts Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication (OID 1.3.6.1.5.5.7.3.2).
• All certificates in the chain of trust Enhanced Key Usage field assert Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication (OID 1.3.6.1.5.5.7.3.2).

Best practice is for the root trust point certificate not to include an Enhanced Key Usage extension. The Federal Common Policy CA certificate does not assert an EKU; therefore all application policies are implied.

Deployment methods

Windows Update

The Microsoft Root Certificate Program is a mechanism Microsoft provides to distribute root certificates via the Windows Update program. The intent of the Program is to enable PKI scenarios for the mass consumer market such as e-commerce, secure e-mail, and code signing. It is not intended to enable enterprise-only scenarios (e.g. smart card logon). The Program attaches a certificate’s EKU as metadata in the Windows certificate store.

The behavior of Windows Update placing certificates in the Trusted Root Certification Authorities store can be controlled by the group policy setting Turn off Automatic Root Certificates Update (Computer Configuration -> Policies -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication settings).

The Federal Common Policy CA certificate to be deployed via the Windows Update Root Certificate Program will not contain the smart card logon OID required to enable HSPD-12 smart card logon within an enterprise environment. The smart card logon purpose must be added to the Federal Common Policy CA certificate contained within the authenticating domain controller’s Trusted Root Certification Authorities store. The domain controller is the Kerberos Key Distribution Center and performs the certificate path / policy validation and certificate revocation checks. In large scale environments modifying every domain controller’s Federal Common Policy CA certificate EKU can become an arduous task.

Group Policy and Enterprise Root CA Store

There are two methods (Group Policy and Enterprise Trusted Root Certification Authorities store) available to enterprise administrators to distribute the Federal Common Policy CA certificate to all systems within an Active Directory domain. Both deployment methods use the auto-enrollment mechanism which is traditionally controlled within the Default Domain and Default Domain Controllers Policies (Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Public Key Policies -> Certificate Services Client: Auto-Enrollment).

Group Policy publication of certificates to domain computers’ Trusted Root Certification Authorities certificate store provides the ability to manipulate a certificate’s Enhanced Key Usage field. This method of deployment must be used if the root trust point certificate does not contain the EKU OIDs necessary for smart card logon.

Since the Federal Common Policy CA certificate does not have an Enhanced Key Usage extension ‘any policy’ is implied (“All application policies”). This certificate can be published to the Active Directory forest’s Trusted Root Certification Authorities store. The Federal Common Policy CA certificate will then be pushed to all domain joined computers.

To publish a certificate to the Active Directory forest’s Trusted Root Certification Authorities store type the following command with Enterprise Administrator rights certutil -f -dspublish FederalCommonPolicyCA.cer RootCA. To view the contents of the Enterprise Trusted Root Certification Authorities store type certutil -viewstore -enterprise root.

Removal of the old Common Policy Certificates

The method of removal for the old Common Policy certificates is dependent upon how the certificates were originally placed in the store:

• Group Policy – remove the Common Policy certificates from the group policy that distributes them. The next group policy refresh will remove the certificates.
• Enterprise Certificate Store – with Enterprise Administrator rights type certutil -viewdelstore -enterprise root, select the Common Policy certificate and select OK.
• Windows Update
  • Manually remove certificates – MMC -> Add/Remove Snap-In -> Certificates -> Computer Account -> <select Local or remote computer> -> Certificates -> Trusted Root Certification Authorities -> Certificates -> Right click, Delete
  • Powershell – The following PowerShell script takes two command line arguments ComputerName and CertificateSerialNumber. Save the PowerShell script into a file named “delete_cert.ps1”. For example to remove the Common Policy certificate from a computer named DC1 the command would be ./delete_cert.ps1 DC1 39e3815404c50ab247effef336cfc698

Automatic Root Certificates Update Behavior on Vista and Higher Operating Systems

If the group policy setting Turn off Automatic Root Certificates Update (Computer Configuration -> Policies -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication settings) is not enabled on Vista and higher operating systems the new Federal Common Policy CA certificate will appear in the Trusted Root Certification Authorities store after a chaining event. If you delete the old Common Policy certificate it may reappear in the computer’s certificate store. When a chaining operation occurs and the root certificate is not in the computer’s Trusted Root Certification Authorities store, the system will call Windows Update to retrieve the root trust certificate. Even if there is no network connectivity to the Windows Update site the system’s crypt32.dll contains root certificates that were published via Windows Update when the operating system was released to market. The root certificate will be retrieved and placed in the computer’s Trusted Root Certification Authorities store.

Intermediate Certification Authorities

To facilitate chaining all intermediate certification authorities’ certificates can be distributed within the enterprise environment. Consult with your HSPD-12 Share Service Provider (SSP) before deploying to identify any potential chaining issues during this transition period.

More Information

• Microsoft officially supports SHA-256 starting with the Vista operating system. Here is a TechNet PKI Blog entry explaining what operating systems and applications work with SHA-256 prior to the release of Vista. Please note this is not an assertion of what is supported but more of what has been tested and works.
• How to configure your environment to support HSPD-12 smartcard logon.