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 install COMMON as a trusted root certificate on all government-furnished, Windows workstations and devices. You should use a group policy object (GPO) managed in your agency network domain. You can also publish the root certificate from the enterprise network domain using certutil.

The certificate details for COMMON are:

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
SHA-1 Thumbprint 90 5f 94 2f d9 f2 8f 67 9b 37 81 80 fd 4f 84 63 47 f6 45 c1

You should never install a root certificate without verifying it.

To verify it, download the certificate or email fpki@gsa.gov for an out-of-band copy.

Use a utility (certutil on Windows or openssl or sha1sum on UNIX platforms) to verify that the SHA-1 thumbprint of the certificate file matches the SHA-1 value provided above.

	certutil -hashfile fcpca.crt SHA1
	openssl dgst -sha1 fcpca.crt
	sha1sum fcpca.crt

Install Using Group Policy Objects

You can add COMMON to the Trusted Root Certification Authorities certificate store by using group policy objects.

Microsoft TechNet articles and other online resources outline the general procedures for setting up group policy objects. Specific to the installation of COMMON:

  • You must have Enterprise Administrator privileges
  • You can set up a group policy object from a Domain Controller (or other approaches you use in your agency)
  • You may need to use multiple group policy objects to apply the configurations to all workstations in all groups and containers
  • Settings are under:
	Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies\
  • Import the fcpca.crt into Trusted Root Certification Authorities

Install Using Certutil

You can add COMMON to the Enterprise Trust certificate store by using certutil.

  • You must have Enterprise Administrator privileges
  • You can run certutil from a Domain Controller
  • To publish/add a certificate to the Enterprise Trust certificate store:
	certutil –dspublish –f fcpca.crt RootCA
  • To view all certificates in the Enterprise Trust certificate store:
	certutil –viewstore –enterprise RootCA
  • To propagate from the Domain Controller(s) to the enterprise:
	gpupdate /force

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