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
- ldap://ldap.fpki.gov/cn=Federal%20Common%20Policy%20CA,ou=FPKI,o=U.S. %20Government,c=US
- 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 184.108.40.206.4.1.3220.127.116.11) and Client Authentication (OID 18.104.22.168.22.214.171.124.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 126.96.36.199.4.1.3188.8.131.52) and Client Authentication (OID 184.108.40.206.220.127.116.11.2).
- All certificates in the chain of trust Enhanced Key Usage field assert Smart Card Logon (OID 18.104.22.168.4.1.322.214.171.124) and Client Authentication (OID 126.96.36.199.188.8.131.52.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.
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.
- 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.