Edit this page

Federal Common Policy CA Removal from Microsoft Trust Store Impact

 Publish Date: May 18, 2018

Upcoming changes regarding Microsoft’s Trusted Root Program could impact your agency. The Federal PKI Policy Authority has requested that Microsoft remove our U.S. Government Root CA certificate (Federal Common Policy CA [COMMON]) from Microsoft’s globally distributed Certificate Trust List (CTL).

The Federal PKI Policy Authority is working with Microsoft on the timeline for removing COMMON. As more information and additional procedures become available, this announcement will be updated. Please watch for updates from the Federal PKI listserves, ICAM listservs, and the ICAM Sub-committee.

How Does This Work?

Today, Microsoft distributes hundreds of trusted root CA certificates, including COMMON, through its Certificate Trust List (CTL). Microsoft distributes two CTLs for Windows operating systems: which root CAs are trusted, and which CAs are untrusted. The Trusted CTL (authrootstl.cab) adds certificates to the Microsoft Trusted Root Certification Authorities certificate store, and the Untrusted CTL (disallowedcertstl.cab) adds certificates to the Untrusted Certificates store.

Starting in Windows 10 and Server 2016, Microsoft may also include date-based CTL entries. For example, a date based CTL entry will disallow trusting code-signing or server authentication certificates issued after a specific date.

Microsoft distributes the Trusted and Untrusted CTLs to the following Windows Operating Systems:

Versions
Windows 10
Windows 8.1
Windows 8
Windows Vista
Windows Server 2016
Windows Server 2012 R2
Windows Server 2008 R2

What Will Be Impacted?

When Microsoft removes COMMON, government users of Windows will receive errors. Errors will occur in the following scenarios:

  1. Performing smartcard logon to the government networks using PIV credentials
  2. Authenticating to the government virtual private network endpoints (VPNs) using PIV credentials
  3. Authenticating to the government internet facing authentication and collaboration portals
  4. Browsing with Microsoft Internet Explorer, Edge or Chrome browsers to a government intranet website that has a TLS/SSL certificate issued by a Federal PKI CA that validates to COMMMON.
  5. Opening an email in Microsoft Outlook that was digitally signed using a certificate issued by a Federal PKI CA that validates to COMMON.
  6. Opening a Microsoft Office document that was digitally signed with a certificate issued by a Federal PKI CA that validates to COMMON.

If you are unsure whether your applications will be affected, email us at: fpki@gsa.gov.

This change will also impact partner users that rely on COMMON. For example, a Department of Defense employee sending a digitally signed email to a business partner.

You can mitigate the risk to government missions, intranets, applications, and government-furnished equipment.

What Should I Do?

To limit the impact to your agency, you’ll need to redistribute the COMMON root CA certificate as a trusted root certificate to all government-furnished Windows workstations and devices.

To redistribute COMMON, follow these procedures:

  1. Download a Copy of COMMON
  2. Verify Your Copy of COMMON
  3. Redistribute COMMON

Download a Copy of COMMON

To download a copy of COMMON, use one of the recommended options:

  1. Download from http://http.fpki.gov/fcpca/fcpca.crt.
  2. Email fpki@gsa.gov to request an out-of-band copy for download.

You should never install a root certificate without verifying it. Follow the procedures below to verify the authenticity of your copy of COMMON.

Verify Your Copy of COMMON

Use one of these options to verify your copy of COMMON. Your certificate details and hash must match the expected values shown below.

  1. Use Microsoft command line via certutil
  2. Use Microsoft command line via OpenSSL
  3. Use Microsoft PowerShell
Federal Common Policy CA (FCPCA/COMMON) Certificate Details
Federal Common Policy CA
(sometimes shown as U.S. Government Common Policy)
http://http.fpki.gov/fcpca/fcpca.crt
Distinguished Name cn=Federal Common Policy CA, ou=FPKI, o=U.S. Government, c=US
Serial Number 0130
SHA-1 Thumbprint 90 5f 94 2f d9 f2 8f 67 9b 37 81 80 fd 4f 84 63 47 f6 45 c1
SHA-256 Thumbprint 89 4e bc 0b 23 da 2a 50 c0 18 6b 7f 8f 25 ef 1f 6b 29 35 af 32 a9 45 84 ef 80 aa f8 77 a3 a0 6e

Note: For the following procedures, replace [PATH\] with the path to your copy of COMMON.

Use Microsoft command line via certutil

  1. Click Start, type cmd, and press Enter.
  2. Run command:

        certutil -hashfile [PATH\]fcpca.crt SHA256
    

Use Microsoft command line via OpenSSL

  1. Click Start, type cmd, and press Enter.
  2. Run command:

         openssl sha256 [PATH\]fcpca.crt
    

Use Microsoft PowerShell

  1. Click Start, type cmd, and press Enter.
  2. Run command:

         Get-FileHash [PATH\]fcpca.crt | Format-List
    

Sample steps run on Microsoft Server 2012: Sample Steps

Redistribute COMMON

Use one of these options to redistribute COMMON:

  1. Use Microsoft certutil
  2. Use Microsoft Group Policy Object
  3. Use third-party configuration management tools
  4. Manually use Microsoft Certificate Manager

Use Microsoft certutil

You must have Enterprise Administrator privileges for the Domain to use these procedures. The commands must be run from an agency Domain Controller.

  1. Click Start, type cmd, and press Enter.
  2. Run command:

         certutil -dspublish -f [PATH\]fcpca.crt RootCA
    
  3. Verify that COMMON was distributed. Run commands:

         gpupdate /force
         certutil -viewstore -enterprise
    
  4. Confirm that COMMON is contained in the output details.
  5. [OPTIONAL] Verify the certificate details against the expected values shown above (e.g., Serial Number).

Sample steps run on Microsoft Server 2012: Sample Steps

Use Microsoft Group Policy Object

You must have Enterprise Administrator privileges for the Domain to use these procedures. The commands must be run from an agency Domain Controller.

  1. Navigate to Server Manager.
  2. Select Tools.
  3. Select Group Policy Management from the drop-down list.
  4. Right-click your desired domain(s), and select Create a GPO in this domain, and Link it here….
  5. Enter a GPO Name and click OK.
  6. Right-click the newly created GPO and click Edit….
  7. Navigate to Policies -> Windows Settings -> Security Settings -> Public Key Policies.
  8. Right-click Trusted Root Certification Authorities, and select Import. The Certificate Import Wizard will open.
  9. Browse to and select your copy of COMMON.
  10. Verify that the target Certificate Store presents Trusted Root Certification Authorities, and select Next.
  11. Select Finish to complete the import. You’ll see the message, The import was successful.
  12. Close the Group Policy Management window.
  13. [OPTIONAL] Wait for clients to consume the new policy or you can force consumption:
    • Click Start, type cmd, and then press Enter.
    • Run command:
           gpupdate /force
    

Sample steps run on Microsoft Server 2012: Sample Steps

Use third-party configuration management tools

You must have Enterprise Administrator privileges for the Domain to use these procedures. The commands must be run from an agency Domain Controller.

You can use third-party configuration management tools, such as BigFix.

  1. Using BigFix, schedule a task and push the certificate file:
    • Run command (example):
         certutil -f -addstore root “fcpca.crt”
    

Manually use Microsoft Certificate Manager

For unmanaged devices, use the following manual procedures:

  1. Click Start, type certmgr.msc, and then press Enter.
  2. Right-click Trusted Root Certification Authorities and select All Tasks -> Import. The Certificate Import Wizard will open.
  3. Browse to and select your copy of COMMON.
  4. Verify that the desired Certificate Store presents Trusted Root Certification Authorities, and select Next.
  5. Select Finish to complete the import. You’ll see the message, the import was successful.

Note: If multiple users share a device, administrators should run certlm.msc to concurrently update the certificate stores of those accounts vs. updating each account separately.

How Can I Test?

Testing by government teams did not allow locally administered certificate stores to override the Microsoft CTL distributed settings. The decision was made to remove COMMON entirely from Microsoft’s trust store. No further testing on overriding the CTL settings will be conducted.

To review the previous testing procedures:  CTL Testing.

Frequently Asked Questions

1.  Why is COMMMON being removed?

The Federal PKI CAs don’t comply with Microsoft’s requirements for globally trusted TLS/SSL certificates. Microsoft’s requirements include:

a.  Requirement for Fully-Qualified Domain Names (FQDNs)
Microsoft plans to restrict TLS/SSL certificates to only those certificates using FQDNs ending in .gov, .mil, or fed.us. Some Federal agencies issue TLS/SSL certificates to intranet assets. These certificates either:  don’t have FQDNs; contain intranet domains that don’t end in .gov, .mil, or fed.us; or use short names (aliases). Under Microsoft’s requirements, these agencies would need to reissue, re-install, and reconfigure all “non-compliant” certificates and applications. The Federal PKI community has determined that this would have a negative impact on mission applications on the intranets.

b.  Requirement for public audit
The Federal PKI follows a government auditing standard, and we have not restricted our issuance of TLS/SSL certificates to only the .gov and .mil domains. Under the requirements, all CAs in Federal PKI that could issue TLS/SSL certificates are required to submit a non-government audit or be technically constrained. Federal PKI has not technically constrained our CAs.

c.  Requirement to disclose Certificate Practice Statements and Incident Post-Mortem Reports
Public trust requires public disclosure and transparency. All Federal PKI CAs would be required to publicly post their Certificate Practice Statements and their Audit Letters. The Federal PKI community has attempted to disclose all Certificate Practice Statements for a number of years. However, some federal agencies include sensitive information in these documents and cannot disclose the documents publicly.

d.  Requirement to create new issuing Certification Authorities (CAs)
Any Federal PKI CA that issues TLS/SSL, code-signing, or email-signing certificates would have to establish a new CA for each type of certificate. This effort requires time, planning, and funding.

2.  How can I determine which of our intranet websites and applications will be impacted, including those used by cross-agency users?

All Windows-based websites and applications configured with certificates (email, Virtual Private Network, digital signature, etc.) issued by a Federal PKI CA that validates to COMMON will be impacted. For agencies and mission partners that are cross-certified with the FBCA, external users could also be impacted if COMMON is used instead of your root.

You can run a report on all issued certificates or, if your agency has an agreement with a Federal PKI Shared Service Provider (SSP), you can request that the SSP run the report.

You can scan your intranet websites in coordination with your CISO teams. There are existing tools to use, or you can use the DHS NCATS “pshtt” tool, which will also check for cipher suites and mis-configurations on the intranet websites:

Note:  This tool will look for not just Federal PKI certificates. Its outputs will include all certificates and information.

3.  How can I determine whether my agency users and government-furnished equipment will be impacted?

Check your enterprise trust store configurations in your Microsoft domain and devices. You must verify how COMMON was installed and managed.

View where and how a certificate is being installed using the certificates snap-in (certmgr.msc). Under View -> Options, click the Show Physical certificate stores option.

If COMMON is already in the Trusted Root Certification Authorities or Enterprise Trust store and the source is a group policy object or the enterprise trust domain, you don’t need to reinstall or change.

4.  Is PIV network login impacted?

Yes. See Install Using Group Policy Objects to mitigate this risk.

5.  Do I need to remove the “baked-in” version of COMMON?

No, don’t remove COMMON. When Microsoft does the update for the CTL, it will be removed during normal patching cycles.

You may see two versions of the certificate in Trusted Root Certificate Authorities. You must verify how COMMON was installed and managed.

View where and how a certificate is being installed using the certificates snap-in (certmgr.msc). Under View -> Options, click the Show Physical certificate stores option.

6.  Do I need to add COMMON to the Trusted Root Certification Authorities store, or should I add it to the Enterprise Trust Store?

Microsoft Operating Systems use different physical containers and logical views of these containers for trust stores. In addition, different tools will have different names for the same physical or logical view. For example:

Certificates snap-in (certmgr.msc) Enterprise PKI snap-in certutil Registry
Trusted Root Certification Authorities Certificate Authorities Container tab Root and RootCA Root

It can be confusing–the easiest model is to follow one of the two methods in What Should I Do?

To read detailed information on certificate stores, logical views, physical views, and registry locations: Managing Certificates with Certificate Stores

7.  Do I need to change any trust property for COMMON managed by group policy objects?

No, trust properties are not set by group policy objects. If your agency currently distributes COMMON through a group policy object, no change is needed.

8.  What Windows versions are affected?

All Windows versions from Vista forward are affected.

9.  Can I create a custom CTL for our enterprise?

Yes, a trusted or untrusted, custom CTL can be created for your agency enterprise: Creating, Signing, and Storing a CTL.

However, we don’t recommend this. Simplicity can help security, and it can be simpler to manage a group policy object than a custom CTL.

Additional Resources

  1. Certificate Trust List Overview
  2. Managing Certificates with Certificate Stores
  3. Configure Trusted Roots and Disallowed Certificates