SSL Inspection Policy and URL Filtering

SSL inspection policy scan traffic based on the source and destination. By default, SSL Inspection Rule blocks Untrusted Server Certificates

With URL Filtering policy in place (or URL Categories in SSL Inspection Rule Criteria used), if you hit a website with an untrusted SSL cert (revoked, expired etc), Zscaler Untrusted Certificate Check kicks in prior to URL Filtering Policy. Browsing sites that fall under block URL Category with trusted certs will trigger URL Filtering block (Log: not allowed to browse this category).

In the following example, User A access gambling site with Gambling category blocked by URL Filtering policy.

For HTTP traffic, SSL Inspection policy not applied, we go straight to URL Filtering policy (Blocked Policy Type: URL Filtering) and the configured Web Traffic action, Caution, is applied (Policy Action: Request method cautioned).

For HTTPS traffic, SSL Inspection policy comes into play before URL Filtering Policy. As User A accessed, the Server Certificate from is untrusted and blocked by SSL Policy (Blocked Policy Type: SSL Policy filter). Also notice Certificate Chain Validity failed.

User B with similar SSL and URL Filtering policies access gambling site (HTTPS). SSL Inspection policy applied first and passed (server certificate looks trusted). We moved on to URL Filtering Policy (Blocked Policy Type: URL Filtering) and the configured Web Traffic action, Caution, is applied (Policy Action: Request method cautioned). Note for User B, the Server IP ( which fed the trusted server certificate.

To confirm feds untrusted server cert, browse using IP shows the server certificate from blocked by SSL Policy

To conclude, SSL Inspection Policy provides the first line of defense against untrusted server certs. URL Filtering Policy provides additional granular control based on URL Categories.


Hi there,

We have an issue with a customer that seems to be linked to this “parameter”.

Users are invited to open a website that do not present it intermediate CA certificate,
because the server is not configured to present the intermediate CA certificate.

This is not a problem when you don’t use zscaller because Iinternet browsers are all configured correctly with regards to certificate verification standard RFC 5280 and will look at the AIA (Authority Information Access) field of the certificate and download the CA certificate that issued it, but it seems that zscaller don’t do it.
(seems that in fact we can’t be sure that it’s zscaller the issue…)

For the customer end users they simply have a “network access issue” with the server.

If you want to verify this you can check by yourself,
the customer tries to access hxxps://, impossible, but they can access other sites of like the web one hxxps:// because it’s not using the same PKI certificate (or more because, yes, technically the site is presenting the sub CA certificate in addition of it’s own server cert)

BUG or not BUG ?

Any chance that the zscaller engine use the standard AIA field instead of relying only on the technical configuration of the web server ?

For information,
the website that was not correctly configured to present the Sub CA certificate has been updated last Friday, but zscaller still forbid the access to the site.