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.