Without intercepting/decrypting SSL, how to deny HTTPS requests based on content filter category in a proxy deployed transparently


Article ID: 167656


Updated On:


ProxySG Software - SGOS


In an explicit proxy environment, (eg, where client browsers have settings referring to your ProxySG) web access layer rules based on categories will match and allow/deny requests for HTTP and HTTPS URLs because the client includes the requested hostname in the CONNECT request to the proxy.  In a transparent proxy deployment, however, the traffic is encrypted.  Assuming that the ProxySG has an SSL license, and the HTTPS:443 service is set to use the SSL proxy service, the proxy can see both the destination IP address of the server being requested, as well as the certificate it presents to the client.  We can leverage policy to act on the certificate details to perform basic category-based denials.

Steps to configure policy to deny HTTPS requests to specific categories are as follows:

  1. Log in to the proxy's web-based management console.
  2. Select Policy > Visual Policy Manager and click Launch.
  3. In the policy menu, select 'add SSL access layer'.
  4. Right-click the destination in the new rule, click Set > New > Server Certificate Category.
  5. Name the object with a relative name, such as "Denied HTTPS categories"
  6. Extend the Content Filter list, (eg, Blue Coat) and select the categories you wish to deny. 
  7. Click OK, OK.
  8. Ensure that the action in this rule is set to Deny
  9. Click Install Policy

*repeat this process using a 'server certificate'  object, and define the subject as the domain name you're looking to deny, if not using a category.


  • A ProxySG SSL license is required.
  • The HTTPS service on port 443 must be configured to use the SSL proxy engine, rather than TCP Tunnel.
  • Because the SG is not decrypting the request, authentication will need to be bypassed for these requests.
  • Because authentication is being bypassed, SSL access layer rules cannot be sourced using authentication credentials (user/group).
  • HTTP header conditions, (such as user-agent or x-forwarded-for) cannot be used as the source, as traffic remains encrypted.
  • Users will receive a 'page cannot be displayed' error from the browser when these requests are denied, as the proxy would need to decrypt the traffic in order to send the exception page to the user.
  • Since SSL inteception is necessary when displaying the exception page, the browser(s) should have the proxy's SSL certificate installed in order to avoid receiving "Untrusted Certificate" alerts presented by the browser.