Not all digital certificates are equal. The quality of the Certificate Authorities (CA’s) that issue digital certificates and the integrity of their issuing processes are often not what they should be.

It is bad enough to know that even when presented with a certificate warning nag screen in the browser, individual users in your enterprise often still click through and ignore the warning to get to the site they are after.

But fraudulent certificates issued by real public CA’s are even worse, because no warning is ever shown to the user. The most well known example of this is DigiNortar. This Dutch CA was compromised, and fraudulent wildcard certificates were issued and used in the wild.

This led to a scramble to try and fix the problem. Browsers and systems had to patch or update their software to no longer trust the CA.

Since the scope of the compromise was not fully detailed, doing a single certificate revocation would not have helped (you can’t revoke what you don’t know needs to be revoked). The certificate revocation bailed out Comodo during their breach, but realistically, when a CA has been compromised, it has been compromised.

Sophos UTM of course allows you to block individual sites and categories of sites, but it is also able to block access to sites that are signed by an untrusted CA. This is good news from an administrator’s perspective. Should something like this occur again, you could use Sophos UTM to immediately block access to sites signed by a suspect CA.

Blocking an Untrusted Certificate Authority

The first and most important point is that you need to enable HTTPS inspection on your Sophos UTM. Everything that follows only applies if this is configured correctly.

As you know, Sophos UTM works as a proxy, and this means two conversations. There is the client side conversation from your browser to the UTM, and the server side conversation from the UTM to the website. In previous articles about how SSL inspection works we have focused on the client side conversation. This article focuses on how the UTM handles the server side conversation.

Like your browser, Sophos UTM has a list of CAs it trusts by default. The list of CAs is actually the same as the currently maintained list in Mozilla Firefox. You can add and remove CAs from the UTM in the same way you can add or remove CAs in your browser.

In this section, we will focus on the Global Verification CAs. These are the public CAs. Some of them are good and can be trusted, and some of them are kind of ‘on the fence’. The bad ones such as DigiNortar are removed periodically as Mozilla updates their CA list.

To block a particular CA follow these steps:

  1. Log in to the Sophos UTM’s Web Admin console
  2. Select Web Protection | Filtering Options | HTTPS CA’s
  3. Locate the CA you want to block and Toggle the switch from 1 to 0
  4. In my testing, I sometimes had to restart the UTM for this to take effect

 

After disabling the required Global Verification CA’s, the UTM will no longer trust sites signed with certificates from those CAs. The page is not retrieved on the server side, and a block page is displayed to the user.

This is already a great start but there is one problem here. By default this block page allows you to “Add exception for this URL”.

 

Clicking this link in the page will trigger Sophos UTM to add the specific domain (not the CA), into a common exclusion list. The site will then be allowed and never prompted for again. This site exclusion list is used across all of the rules implementing HTTPS inspection.

Disable User Exceptions

If your intention is to block access to sites signed by a bad Certificate Authority, then you want to prevent a user from bypassing this block.

To disable the ability for users to add URLs exceptions:

  1. Select Web Protection | Filtering Options | Exceptions
  2. Locate Skip certificate checks
  3. Disable the exception list with the toggle switch

 

If a user now clicks the “Add exception for this URL” link nothing happens and the block remains in place. With this configuration your UTM if playing hardball. Unless it trusts the CA, users will not be allowed access to sites signed by its certificates. Generally speaking this is exactly where you want to be.

The reality however is that sometimes you need to make exceptions…

Adding a local or private CA

If you have ever enabled HTTPS inspection and distributed your own UTM’s signing certificate, you know that sometimes there are legitimate reasons for adding additional CA’s that are not public CAs.

An example of this could be that your company is dealing with a contractor or newly acquired company that uses their private PKI to sign certificates for use on the public Internet. This is not generally considered best practice but there might be good reason for this.

Fortunately, it is easy to add your own local or private CA’s to Sophos UTM:

  1. Download the CA’s public cert and save it on you local machines
  2. Select Web Protection | Filtering Options | HTTPS CA’s | Verification CAs
  3. Click the folder icon next to Upload local CA
  4. Click Choose file and specify the .cer file you downloaded. Click Start Upload.
  5. Click the Upload button

Your local or private CA has now been added to the UTM and will be trusted.

 

When one of your users browses to a site signed by that CA, the traffic will be allowed. Something to keep in mind when testing this is that your user’s browser will not need to be configured to also trust the new CA. This is because during HTTPS inspection your UTM signs the client side conversation with its own certificate, which you would have already distributed.

Conclusion

Blocking a CA is very different from blocking a site or category of sites. The block action is focused around the integrity of the site rather than the content of the site.

Attacks on HTTPS mechanisms are becoming more commonplace, as we have seen with HeartBleed, Poodle and Freak just to mention a few.

If all you do is enable HTTPS inspection and educate your users to not add exception you are in a reasonably good shape. The Sophos UTM CA list is periodically updated, so as long us you keep up with Up2Date updates, and SSL inspection is enabled for user traffic, you have a common HTTPS verification system that does not rely on all client devices being up to date too.