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.
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”.
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.
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”.
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”.
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”.
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.
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.
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.
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”.
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”.
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!
s/snapfish/superfish/
After finishing this tutorial your page is no longer flagged as naughty. HTTPS4lyfe.
Glad to hear it! And what category was it flagged as?
And did you add an exception, or change its category under the “Websites” tab?
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.
Oh, btw, I think the link you have at the bottom of this specific tutorial links back to itself rather than to: https://drashna.net/blog/2015/03/an-exercise-in-frustration-fine-tuning-the-web-filter-in-sophos-utm/
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.
Hello, is there any way to import CA certificate automatically to all internal clients? or we have to add it one by one manually?
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.
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.
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.
Probably better.
Since it’s been a long week for me, are you aware of the best way to export *just* the public key here? Or at least strip out the private key?
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
By the way: Nice posts