Partager via

Deployment of the new Federal Common Policy CA Root Certificate

  • Article

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 (https://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 PKI Architecture

Federal Common Policy CA Certificate

AIA:

CRL:

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

Federal Common Policy CA Federal Common Policy CA - Subject Federal Common Policy CA - Subject Key Identifier

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.

CA properties

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).

Auto Enrollment Properties

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.

Warning message

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

Comments

  • Anonymous
    January 01, 2003
    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.

  • Anonymous
    January 01, 2003
    Hello !
    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 carevocation 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 ?
    Help please

  • Anonymous
    April 20, 2011
    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.

  • Anonymous
    April 20, 2011
    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.

  • Anonymous
    June 02, 2012
    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.

  • Anonymous
    June 14, 2012
    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

  • Anonymous
    September 18, 2017
    Hello I think I have this issue as PatMCTThe cert trust list for trusted root is going into enterprise trust.Is this wrong?