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.
Click the picture to maximize it to its original size.
Make sure your firewalls are configured to allow the downloading of these certificates and CRLs.
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.
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.
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 22.214.171.124.4.1.3126.96.36.199) and Client Authentication (OID 188.8.131.52.184.108.40.206.2) application policies. Active Directory smart card logon is supported with the following EKU configurations:
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.
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.
The method of removal for the old Common Policy certificates is dependent upon how the certificates were originally placed in the store:
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.
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.
This certificate is causing problems with a bunch of PCs in our organization. We are seeing very long connect times to gmail, yahoo mail, and hotmail just to name a few sites. Sometime we cannot connect to these sites at all. It is also taking a long time to connect using Remote Desktop to the PCs exibiting this problem. As soon as I delete this certificate I can access gmail, yahoo mail, and hotmail quickily and Remote Desktop also connects immediately. I also check some PCs that were not exibiting this problem and they did not have the Federal Common Policy CA installed.
Steve - what version of the operating system are you seeing this issue on? If you are using Vista or greater enable the CAPI2 eventlog (Eventvwr -> Application and Services Logs -> Microsoft -> Windows -> CAPI2 -> Operational -> right click Enable Log) to determine where the certificate validation process is taking a long period of time.
I came across this blog from this "How to configure a MSFT Root CA" post security.stackexchange.com/.../396
And I looked at the root certificate for the Federal Common Policy CA. It makes sense there is no CRL for this cert, but why is the AIA populated? What is the reasoning for populating this, since other guidance on Technet asks us not to.
I’m looking at Federal Common Policy CA issued by Federal Common Policy CA (thumbprint: 90 5f 94 2f d9 f2 8f 67 9b 37 81 80 fd 4f 84 63 47 f6 45 c1). I am not seeing an AIA field. If you are looking at a different version of the certificate (like one of the cross-signed ones), then the AIA path would be used to help build the remainder of the chain.
We seem to be having Steve's issue. Sometime arount June 7, something unknown to me changed. On our Windows 2008 Enterprise server, anything that uses SSL takes forever. All web traffic is fine, but if I try an encrypted page, it takes a really long time. According to paket captures, the server is sending out ldap queries to ldap.fpki.gov and others. What would be the impact of just removing this CA?
Thanks in advance
Sorry for my bad english (i am french)
A question on publish crl in AD ...
I publish the crl of an offline ca root with : certutil -dspublish -f mycrlfile.crl srvcaroot (where srvcaroot is my netbios name of my server where is my caroot)
All is fine, and i saw the publication in the node sevices in the mmc "sites and services" under the cdp container (i have well a srvcaroot container created and mt crl in)
The probleme is that when i do a Gpupdate on a computer in the domain and see in the mmc certificate if the crl is coming down in the entreprise ca\revocation list folder nothing comes ... the revocation folder is not created at all
If i install ... manualy the revocation list on the computer of the domain ... the folder appears and the crl is in it
What is the problem ?