An Exercise in Frustration: Setting up Web Filter Certificates in Sophos UTM

By now, you may be tired of looking at the web filter stuff. However, we’ve only just gotten started.

Right now, the filtering may be enabled, but chances are that you are seeing certificate errors for every HTTPS website your visiting. To fix that, we need to use a Signing CA Certificate. This will be used to re-encrypt the HTTPS traffic. But not only does that need to be installed into Sophos, but you must also install it into each and EVERY client that will be accessing the internet behind the router.

Well, for the most part.

Since a lot of people looking at this guide will be from the Home Server communities, chances are that you’ll have a server that is also a Certificate Authority (CA).

If you’re not, skip down to the “Import CA Certificate into Clients” section below.

Installing a CA Certificate into Sophos

Now, if you have Windows Home Server 2011, Small Business Server 2011 Essentials, Storage Server 2008R2 Essentials, Windows Server Essentials, or a domain controller, then you have the Certificate Authority installed. Why is this important? Because it means that any domain joined or “connected” PC should have the “Signing Certificate” installed into the clients already. This means one less step that has to be done for a bunch of your machines. And less work is better here!

It also means that we can create a signed certificate for your Sophos machine, so you no longer receive certificate errors when you open the Web Admin site.

If you don’t have one of the listed OS’s, then you can skip this section, and go to the “Import CA Certificate into Clients” option below.

For simplicity, we’re going to use the “Internet Information Services (IIS) Manager” on your server. You can run “inetmgr” to bring this up. Click on the Server’s name and this will bring up a bunch of “feature” sections for the server. Look for “Server Certificates” and open this up by double clicking on it.

InetMgr-Main

This is where it gets tricky. The CA certificate we want will be named based on how you named your system. For WHS2011, it will be the certificate listed that was issued to and issued by “SERVERNAME-CA”. On any of the domain controllers (SBS2011E and WSE), it will issued to and issued by “DOMAINNAME-SERVERNAME-CA”.

InetMgr-Certificate

 

Right click on this certificate, and select “View”. This will bring up details about the Certificate. Open the “Details” tab here, and click  the “Copy to File…” button.

InetMgr-CertificateExport

 

This will bring up the “Certificate Export Wizard”. Click on “Next” to start the process. Here, you want to export the “Private Key” so you resign new certificates, so select the “Yes, export the private key” option and hit “Next”.

This will allow you to choose some of the options here, but you should be fine with just the defaults (if anyone believes to the contrary, please let me know, and I’ll edit). Hit “Next”.

InetMgr-CertificateExportpfx

The next page lets you specify a “group or user names” (depending on the OS), or specify a password. You ABSOLUTELY want to specify a password here, or anyone that gets a hold of these files could impersonate websites for you. Set a good password here, and click “Next”.

InetMgr-CertificateExportPassword

 

Then you’ll be prompted to save the password. Save it someplace secure, but accessible. We’ll need this for both Sophos, and any client device that isn’t joined to the domain (such as non-Pro Windows systems, cellphones, and the like).

Now, head back to the Sophos UTM WebAdmin. You’ll want to open the Web Protection section, and open the “Filtering Options” entry. Then find the “HTTPS CAs” tab and open that.

Here you can see the Signing CA section, as well as Verification CAs. Click on the “Upload” button in the “Signing CA” section. This will bring up a popup to upload ta “PKCS#12” certificate file. If you noticed, that’s EXACTLY what we exported. Select the certificate file, and input that password you just created for the certificate here. And then click on “Save”.

Web Filter Options CAs

 

Once you’ve done that, if you load a page, you should notice that it’s being signed by your CA (in my case “LANDSRAAD-ARRAKIS-CA”) instead of VeriSign, GeoTrust, or the other various Certificate Authorities.

Web Filter Signing

 

We’re almost there! But we’re not done yet.

Import CA Certificate into Clients

If you’re using one of the server OS’s that I listed above, and the computer you are on is connected to the server already, then you should notice that you are able to browse the HTTPS sites already, without any certificate errors. That’s fantastic.

Also, at this point, if all of this feels shady, then you’re doing it right. This is EXACTLY why the whole SnapFish thing is a huge deal. Not only could people potentially read your data and resign it without your knowledge, they could also impersonate websites and you’d never know.  This is also why it’s so important to password protect that certificate file.

But now we need to make sure that all the client computers are using this Signing CA as well.  If you have the server CA from before, skip the next section and jump to the “Install the CA” section for your device.

Download the CA Certificate

If you didn’t export the CA Certificate from your server because you don’t have one, choose not to use it, or deleted the file you exported from the server; then you need to download the automatically generated one from Sophos instead.

To do so, head back to the Sophos UTM WebAdmin. You’ll want to open the Web Protection section, and open the “Filtering Options” entry. Then find the “HTTPS CAs” tab and open that. See the “Download” button in the Signing CA section? Click on that, and select the PKCS#12 option (default). Input a password here, and make sure you know this password. Every time you import it into a client, you’ll need this file and password.

This will prompt you to save the file.

Export CA

Or apparently, you can just use the following link from any system behind Sophos UTM to grab the certificate:

http://passthrough.fw-notify.net/cacert.pem

Install the CA on Windows

Now, you need to install it. To do so, … just double click on it!

No, that’s not all. This will start a wizard to import the certificate. Select “Local Machine” so that all users and system services will be able to use this certificate (this last bit is important for Windows Update and other back group services you may have running), and hit Next.

Import CA-Start

This will double check which file you want to import. That is fine. Make sure it’s the right file, and hit “Next” again.

Once you’ve done that, it will ask you for the password for the private key. This is the same password you specified it when you exported/downloaded the certificate. Input it here, and hit “Next”.

Import CA-Password

The next page will prompt you on WHERE to place the certificate. This part is very important, as it controls how the certificate is used.  You want to select the “Place all certificates in the following store”, and the click “Browse”. Then find and select the “Trusted Root Certification Authorities” folder, and hit “Ok”. Then click on “Next”.

Import CA-Location

Just click through the rest of the prompts, because you’re done. Now you should be able to connect to HTTPS sites seamlessly!!

 Install the CA on Android

There is a downside to using the HTTPS decrypting… To import the Signing CA Certificate into Android, you MUST specify a pass code (Pattern/Pin/Password, depending on the specific version) for your phone. You can’t just use the lock screen without a password anymore.

You’ll need to find a way to send the certificate file to your phone or tablet. Emailing it to yourself is probably the simplest. Or if you use something like ES File Explorer and connect to a shared folder, that will work to.

Just “run” the file directly, and use the Certificate Installer. You’ll need that same password from before to import it.

Alternatively, you can open up Settings -> Security and then scan for the file and install it that way. This will also require the password for the certificate.

Once you’ve done that, it’s smooth browsing!

Install the CA on iOS

Since I don’t own any iOS devices, I couldn’t tell you how to do this. But here is a link that should be in the ballpark.

https://support.citrix.com/article/CTX125655

https://support.quovadisglobal.com/KB/a64/how-do-i-install-digital-certificate-onto-an-iphone-ipad.aspx

Like Android, this will require you to set a pin or password on your device.

Install the CA on Windows Phone

I don’t know any of these devices either… so I can’t help. And I’m not finding good info on how to install them.

But email yourself the certitifcate and run it. It should prompt to install it. Then you’re set.

However, like iOS and Android, this will likely require a Pin or passcode to be installed on your phone.

 

Up Next…..

Yes, there is indeed more!

I know, right?! I’m getting sick of this too.

See, I really do mean “An Exercise in Frustration” here!

Next, we will be looking into how to troubleshoot issues, add exceptions to the web filter, and even set it up to do some ad blocking on the router level!

Author: Drashna Jael're

Drashna Jael're

14 thoughts on “An Exercise in Frustration: Setting up Web Filter Certificates in Sophos UTM”

      1. Neither I think. After installing my certificate, your website is now seen as ‘safe’. I don’t remember what it was flagged as, but I was warned you might be trying to record anything I did on the site.

  1. After installing the certificate (Sophos or Server) on my IOS device when I browse I get “Cannot Verify Server Identity” dialog. I have tried several of the fixes found on google – turning wifi off and on again, checking the date and setting to auto or manual. None of that worked – so for now I will just leave the HTTPS setting to URL filtering only. I will come back to this later. Other than that it does work on the computers though.

  2. Hello, is there any way to import CA certificate automatically to all internal clients? or we have to add it one by one manually?

    1. Well, the signing CA needs to be trusted on the systems. This means either using a CA cert that all of the systems already trust, or “manually” importing one.

      I use quotes for “manually”, because if you’re using a domain, you can use the Active Directory Certificate Authority certificate for this. As all domain computers will already trust that CA, it makes things *much* easier.

      But if you’re not on a domain, the URL filtering option may be better, as you don’t need to import the CA Certificate, at all.

    2. When your pc are in a windows domain and your computers are running windows you could use a Group Policy. At home this is likely not the situation.

  3. On clients you should not import a pfx file. It is password protected because it holds the private key. For clients export the certificate also WITHOUT the private. No password needed. This file will have the extension cert or cer. You can safely publish this file, even by mail. It only holds the public key.

      1. Almost the same as procedure as you used:

        Right click the certificate
        Export
        Do not select ‘Yes, export the private key’
        Finish the wizard

        It will no longer offer the option to create a pfx, but a cer instead.

        The reason why you should be very careful with the private is, that everyone that has the private key can imposter the device that is identified by the certificate. In this case the utm. The utm is being trusted for issueing certificates, so an impostere also will be trusted.

        Lets say a company uses a pac file to deploy the utm proxy with ssl scanning. It uses in the url a fqdn. Dns is configured on the clients using dhcp. Now life of a hacker is not to difficult:
        – He installs his own dhcp on his pc, using the same config, except dns server.

        – He runs a dns server. This one points the ip address a the fqdn for the url of the pac file to his pc.

        – Now he can be the proxy for all internet traffic, and because he als has the certificate with the private key he can do a ‘man in the middle’ and eaves drop on all the decrypted ssl traffic. There will be no suspicion raised, because the certificates he issues for this attack are trusted.

        So private keys should be kept that way: private

        Sorry for the long sermon on the subject, especially when it already has been a long week

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.