Same problem here. We do not currently intercept SSL, so our users get the same error. If you enable "detect protocol on your Proxy Services (HTTP and HTTPS), then the proxy will attempt to perform "SSL Intercetion on Exception" by default, even if you do not explicitly enable any SSL Interception in policy. Then when HTTPS sites are blocked due to policy exception, the proxy attempts to create a secure conenction to the browser using its self-signed certificate so it can display your cofingured exception page. If your clients do not trust your appliance certificate, they will get a certificate mis-match error, which they should be able to click through to see your exception page.
The proxy is probably returning your configured exception page, however, without "detect protocol", there is no TLS session between the browser and the proxy, so the browser displays this generic "page cannot be displayed" error. If you run Wireshark on the client or capture on the proxy with the client IP as a filter, you can see the actual HTML of the proxy's exception page trying to be delivered to the browser. The browser ignores this because it was delivered unencrypted from the proxy, and the client is expecting a TLS session.
Be aware that enabling detect protocol can increase CPU utilization , since the proxy begins resigning all HTTPS certificates it see to prepare for "Intercept on Exception" conditions. Re-signing and caching server certificates requires a lot of crypto processing. If you experieince high CPU usage, refer to this article for suggestions on mitigation.
https://support.symantec.com/en_US/article.TECH245157.html
Harry