Federal Common Policy CA Removal from Microsoft Trust Store Impact

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

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:

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.

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.

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:

• DHS NCATS pshtt

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:

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