I'm having two issues that I'm hoping someone can help me with since I've found so many answers here as of late...

The first is not necessarily an issue, but I want to understand how it's working. I'm currently seeing that a lot of our blocked traffic is the downloading of crl files from CAs. These are getting blocked according to the Malware Content Type Filter. The question I have is should I be concerned about this? I'd like to make sure we're getting legitimate CRLs, but I believe that the web gateway may be handling CAs and their CRLs for us?

Then we're also having an issue where HTTPS traffic is being blocked, but the users aren't getting an error message from the gateway saying why they don't have access to the site. They're simply told that the connection failed by their browser. Is this because we don't currently have the SSL Scanner enabled and we're not able to intercede in the encrypted connection to deliver a block page? Is there any way around this without decrypting SSL traffic?

We're currently running Web Gateway version 7.2.0.3.0. Thanks for any help and information you can provide!

1.) You are right that MWG will handle CAs and CRLs in case you have SSL Scanner enabled. However there are still applications with do have their own certificate handling. iTunes is a good example. If SSL Scanner is enabled the server certificate will be replaced by a certificate signed by MWG. iTunes will check the certificate and tries to check if the certificate is signed by Apple. If it is not, access will be denied. So in such an example you will have to bypass SSL Scanner. In this case we tunnel the certificate and iTunes has to perform CA/CRL checks, so we want to pass CRLs usually.

I recommend to let CRL lists pass MWG. A whitelist entry should help. If you check the access.log you may see that the CRLs are downloaded by a "Microsoft SSL something" User-Agent, and not by a browser user-agent. This seems to be a background service on Windows OSes which do the certificate stuff for applications. You could allow this traffic to pass.

2.) You are right. If you have no "Set Client Context" rule enabled (part of SSL Scanner) MWG has nothing to sign the error page with. We cannot sign it with the web server certificate and we have not configured a CA to sign the request with. So MWG sends a plain-text response and the browser fails to interprete this, since it expected an SSL connection.

You could add a "Enable Client Context" event and specify a CA. In this case MWG will sign error templates with that certificate, but will not intercept traffic. The certificates will only be replaced if there is a block page displayed.