After Chrome 58+ started to check for presence of subjAltName extension in SSL certificates presented by the remote sites, it turned out that the order of sslbump directives that Admin UI generates is not completely incorrect. If you have blocked http://www.youtube.com in Web Safety, then accessing https://www.youtube.com in Chrome 58+ results into ERR_CERT_COMMON_NAME_INVALID error message instead of the expected access forbidden page.
Consider the following.
* We have blocked access to .youtube.com in Default Policy / Block by Domain.
* User types https://www.youtube.com into address bar of the browser. Note the httpS:// schema!
* Browser tries to establish CONNECT tunnel to http://www.youtube.com through Squid proxy.
* Squid forwards this request to ICAP web filter.
* Web Safety instructs Squid to decrypt the HTTPS connection (to be able to show the blocked page later).
* Squid mimicks the SSL certificate of http://www.youtube.com without contacting the actual YouTube. Thus mimicked certificate does not have subjAltName extension included.
* Chrome 58+ shows “Your connection is not private” message.
This happens because by default Squid does not include subjAltName extension into SSL certificates generated without contacting origin servers. See bug http://bugs.squid-cache.org/show_bug.cgi?id=4711 (will be fixed in Squid version 3.5.25+).
To fix this issue we need to reorder the SSL bump directives that Web Safety generates. Continue reading at https://docs.diladele.com/faq/squid/chrome_ssl_filter/wrong_order_of_peek_and_splice.html