I have a query regarding the SSL inspection functionality on the USG110 series and above. I have a requirement to provide a public Wi-Fi access point, and I’m looking at using a USG110 to provide application control, and content filtering which I can get working ok with HTTP traffic, the challenge I’m having is with HTTPS traffic and being able to use application control and content filtering with this type of traffic to provide protection for the client I’m working with.

I have been able to use IDP to block traffic based on the signature for traffic for example I have been able to block HTTPS to the Spotify website and then with app control also block access to the Spotify desktop application. What I’m looking to do is not have to create a rule for each website or application we want to block through IDP as with the Spotify example it did not block all elements of Spotify and I had to use a mixture of App Patrol and IDP. This is where I’m looking to use the SSL inspection feature along with App Patrol and Content filtering on the USG110 to give me a complete overview of all traffic being passed through the network and apply polices to this traffic.

The query I have around SSL inspection is regarding the SSL certificate, as it is a public Wi-Fi access point I’m unable to control the devices that will connect to this network and thus cannot install the self-signed certificate on to each device so it will recognise any HTTPS traffic that is scanned by the USG as being from a trusted source. If I was to purchase a third party SSL certificate from a certificate authority and then import this onto the USG would this take away the need for the self-signed certificate on the USG to be used, and allow the HTTPS connection to an external source to show as a trusted connection on the devices?

Thanks in advance for your response

1 Answer 1


Can't be done. Not without you buying a Sub-CA certificate. (Which no self-respecting CA will/should sell to just anybody.)

While there are ways around this, none of them are practical. (And that's a good thing.):
1) You don't care about detection. You just man-in-the-middle everyone, give them an untrusted certificate and hope they will click through the certificate warnings. This is ugly.

2) You don't care about detection too much. You just man-in-the-middle everyone, strip HTTPS and certificates right out (using SSLStrip). Then you won't have to worry about certificates.

3) You care about detection somewhat more and are very, very powerful. You are in a position to have a recognized CA issue an unrestricted sub CA cert for your interception business. This will require the cooperation of said CA. (So this will only be an option if you are a nation-state.) -- Then you will hopefully be found out and named and shamed by Google Chrome. (Which is what happened in 2013: http://googleonlinesecurity.blogspot.ro/2013/12/further-improving-digital-certificate.html )

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .