Windows 10: Removal of the U.S. Federal Common Policy CA certificate from the Microsoft trusted root

Re this notice.Does this mean that everyone's PC must install the G2 protocol? Or is it for Windows servers only?How does this work for people OUTSIDE the US accessing US services / servers and for Servers situated outside the US but sometimes serving US customers?

:)

 

Microsoft updates Trusted Root Certificate Program

Source: Microsoft updates Trusted Root Certificate Program to reinforce trust in the Internet | Microsoft Malware Protection Center

 

Trust root or leaf certificate in 802.1x setup?

I am setting up 802.1x via wired or wireless (WPA2 Enterprise) connections in our office, backed by a OneLogin RADIUS server. The certificate is not self-signed, so it's not clear to me whether it's safe to import it into the Trusted Root CA store, but that seems to be the only way to enable certificate checking.

The certificate chain looks like this:

• *.us.onelogin.com
  
• RapidSSL SHA256 CA - G3
  
• GeoTrust Global CA (already in the Windows Trusted Root CA store)
  

The leaf and intermediate certificates are passed by the RADIUS server (verified using eapol_test).

If I only enable the GeoTrust Global CA in the Protected EAP settings window, I still get a warning in Windows 10, as if no certificate checking was enabled ("Continue connecting? If you expect to find in this location, go ahead and connect. Otherwise, it may be a different network with the same name."). The warning does not show if I import the OneLogin certificate in the Trusted Root CA store and enable it in the EAP settings. The "Connect to these servers" field is set to radius.us.onelogin.com, so a MitM attack doesn't seem possible with just the actual GeoTrust root certificate enabled?

Is this expected behaviour? This (unrelated) Lync support article says that the Trusted Root CA store should only store self-signed certificates (which makes sense), and could cause issues otherwise. Also, in this answer to a similar question, I see "Some clients might be convinced to trust [the leaf certificate] directly, but not all of them permit such direct trust, and it would mean trouble when that certificate expires."

 

Accept self-signed certificate system-wide without installing as root CA

If the server is under your control:

1. Create an actual root CA (e.g. with easy-rsa or Xca or Windows Server CA role).
   
2. Replace the self-signed server certificate with one issued by your custom CA.
   
3. Make sure the certificate you just issued is actually marked as a "leaf" / "end-entity" certificate. Look for the "X.509v3 Basic Constraints" extension – it must be present and say "CA: FALSE".
   
4. Install the custom CA's root certificate into your computer.
   
5. Safely store the CA private key so that it's only accessible whenever you need to issue a new cert.
   

As the server's certificate contains "Basic Constraints: CA: FALSE", it will not be able to issue new certificates using just its own key.

(The reason you need the CA to be separate is because directly installing the server's self-signed certificate into the "Trusted CA" folder may cause the system to ignore Basic Constraints – after all, it's installed as an authority. Separation avoids this problem, because you can safeguard the root CA keys.)

As a bonus feature, you won't need to re-trust the server certificate when it expires or when its name changes – just use the same root CA to issue a new cert.