After enabling HTTPS Inspection on the Security Gateway, some resources that use HTTPS protocol (like Microsoft Lync) fail to connect.
There are two main scenarios, which can cause this kind of problem:
Inspect Rule: In the HTTPS Inspection policy, there is a rule related to the application, which specifies that it should be inspected.
In this case, the application might fail the connection because HTTPS Inspection presents its own certificate (instead of the original site's certificate), which is signed by a dedicated CA.
For browsers like Google Chrome and Internet Explorer, it is possible to make them trust the Security Gateway's CA certificate, but for some user applications this is problematic, or even impossible.
Currently, there is no solution besides bypassing the application as described below in the Solution section.
Bypass Rule: In the HTTPS Inspection policy, there is a category-based rule related to the application, which specifies that it should be bypassed.
Currently, in order to bypass a site, HTTPS Inspection must know, which IP address is used by the site, so it can decide whether to inspect it or not. The correlation between the site's URL and its IP address is done on the first connection. The bypass mechanism is based on inspecting the site once and saving the IP address in the cache for bypassing it the next time a connection is opened to the same destination.
As mentioned, some user applications may fail to connect the first time due to attempted HTTPS inspection. The application should connect on the second attempt once the HTTPS bypass is in place.
If an error occurs during the SSL handshake, the Bypass based on categories will not work, the site will not be saved as bypassed and it will continue to be inspected. In such case, the application will always fail the connection.
Examples of SSL handshake errors:
In case there is a problem with fetching CRLs while validating the certificate, the server's IP address will not be saved, and the following log will show in the SmartView Tracker:
Failed to fetch CRL from the following URL: http://.... Make sure the security gateway has an outgoing http access, and that the proxy and DNS servers are well configured Certificate DN: 'CN=...,O=...,ST=...,C=...'
Another possible reason is if the application does not use standard SSL protocol.