Revoking and Pinning Certificate Authorities in Windows

Last updated at Wed, 30 Aug 2017 19:54:07 GMT

Situations come up relatively frequently where a specific certificate authority, trusted by browsers and operating systems, acts in a way that the users of those products would consider untrustworthy.

In the enterprise, with services exposed to the Internet and employees traveling, working from Wi-Fi and other insecure connections, this is also a very important issue, as the use of some of these less than tasteful certificates could lead to data (and credential!) interception.

Fortunately, if you manage Windows systems, you can not only configure the list of trusted authorities, but you can also pin the appropriate one for each service you use.

Untrusting Certificate Authorities on Windows via GPO

Filippo Valsorda, from Cloudflare, discovered and disclosed that Symantec had created an intermediate certificate authority (CA) for Blue Coat, a company that provides network devices with the ability to inspect SSL/TLS.

While there are legitimate uses to these features in the enterprise, such a CA could allow anyone using it to intercept encrypted traffic. This is not the first time, and will probably not be the last time something like this happens, so being ready to revoke certificate authorities is an ability enterprises must have.

Filippo also posted a great tutorial on how to revoke it on OS X and now links to Windows instructions but this article also covers pinning and goes into a bit more detail.

In this post, we will look at doing it on Windows, in an Active Directory environment.

Whitelist Versus Blacklist

Windows does allow you to fully configure certificate authorities, which would be ideal from a security perspective, to keep full control of the approved authorities, but which would result in a whitelist approach, requiring additional management effort as it involves replacing the certificates on all systems via GPO, which could risk breaking custom certificates installed for legitimate purposes. This should be a longer term goal, but a blacklist approach can still be used right away.

In this case, start by downloading the certificate you want to block as a .crt file.

Create A Group Policy Object (GPO)

You could use an existing GPO, or create a new one. The important thing to consider is that this will be a computer policy, that should be linked to the OUs where your workstations are located. As with any GPO changes, it is highly recommended to first link and filter this policy to specific testing workstations, considering a mistake could end up breaking SSL/TLS connectivity on workstations.

Edit the GPO, and under Computer Configuration/Windows Settings/Security Settings/Public Key Policies/Untrusted Certificates, right click in the right pane to get the Import option.

The first wizard screen has greyed out options, as we are modifying a GPO. On the second one, simply browse to the CRT you downloaded. Ensure the imported certificate gets placed in Untrusted Certificates.

At this point, your GPO should look like this, and is ready to block this certificate from the Windows store on all machines where it is deployed.

Pinning Certificate Authorities Via GPO

Revoking known bad certificates is one thing, but a very reliable way to ensure bad certificates have no impact on corporate services is to pin those. Pinning essentially configures the client device to only accept known good values for pre-configured SSL/TLS communications.

Pinning can be done very granularly, at the certificate/public key level, which would require a lot of management, but it can also be done at the certificate authority level, which is much easier to manage.

This would allow us to configure systems to only expect, for example, that communications to the Rapid7 website should use GoDaddy certificates.

By applying this to the services used by traveling employees, you can ensure that captive portals, hotel and plane Wi-Fi environments or even malicious attacks at the ISP levels would require forging a certificate of that very specific authority, and would prevent the use of another illegitimate yet trusted certificate.

Deploy EMET

Deployment of EMET has already been covered in our whiteboard Wednesdays briefly, and Microsoft includes great information about it with the installer. EMET must be deployed to the workstations where you wish to pin certificates, and while other EMET mitigations are great for security, they are not covered in this post, where we will focus only on certificate management.

Create A GPO For EMET

Again, a policy that applies to the appropriate computer objects must be created.

EMET itself comes with the appropriate files to create GPOs, located under Program Files\EMET\Deployment\Group Policy Files.

1. Copy the ADMX to <SystemDrive>\Windows\PolicyDefinitions

2. Copy the ADML to  <SystemDrive>\Windows\PolicyDefinitions\en-US folder

3. Re-open the GPO Management Console

4. You now have a new set of GPO options available under Computer Configuration\Administrative Template\Windows Components\EMET

5. Enable Certificate Pinning Configuration.

6. In Pinned Sites, list all URLs you want to protect, as well as the name of the rule we will create.

7. In Pinning Rules, use the same rule name, then list the thumbprints (SHA-1) of the certificates to accept, or of their authorities. These rules can get very granular, include expiration dates and more - please read the examples provided by Microsoft if you would like to use such advanced rules. Using the EMET GUI, when starting, can allow you to see the types of rules that can be created with more ease than editing those relatively unfriendly GPOs.

8. In our example, I configure www.rapid7.com to only trusted a SHA-1 thumbprint of OBVIOUSLYNOTAREALTHUMBPRINT. We configured this to be a blocking rule, that expires on Christmas 2020.

9. If you run the EMET GUI on a system where the GPO is applied, you'll see the new rule being applied, denoted by the icon showing it is coming from a GPO.

10. If we now browse to Rapid7's website, we get a certificate warning, since the real certificate does not match the fake thumbprint. This is what would happen if a trusted but illegitimate certificate was at play in a man-in-the-middle-attack.

11. EMET logs an error to the Event Log, which you should absolutely detect and investigate.

12. Repeat this for all important services you use, such as webmail, single sign-on portals, reverse proxies, SaaS providers. Additional protection for social network accounts can also be achieved this way.

Warning: Edge does not seem to support this feature yet. You should also look into configuring any alternate browsers in use with similar rules, to obtain better coverage. Again, this is the type of change that should be tested very well before being pushed to a significant amount of workstations, but once done, you will have significantly reduced the chances of a man-in-the-middle attack, and augmented the odds of detecting them.

Enjoy your new GPOs!