I believe this problem occurs because MWG does not have a certificate to sign the connection when the authentication server required authentication. After you have authenticated (which may happen transparently for the user depending on your configuration) to an HTTP site, requests to an HTTPS website will be authenticated because the IP address is known to MWG, and MWG can associate the IP address to a User.
If you browse an HTTPS website without having authenticated before, or access an HTTPS link after the session time configured in the authentication server expired, MWG will try to perform authentication. To perform authentication, a redirect is sent to the browser to cause it to talk to the authentication server. In your example I can see that SSL Scanner is disabled. In this case MWG cannot send a proper redirect. The browser tries to access the HTTPS website. MWG decides that the IP address is unknown and the request cannot be allowed. MWG cannot intercept the connection (because it is SSL and SSL Scanner is disabled), and therefore sends back a HTTP response - Internet Explorer shows something like "page cannot be displayed" in this case.
You could try some things
1.) Enable SSL Scanner (please read about SSL Scanner carefully first, as it requires some prerequisites to be fulfulled - it will cause you serious trouble if you simply enable it without further modifications) or at least add a rule which calls the "Set Client Context" Event. in the Event you will specify a Root CA (import an existing one or create a new one) which will be used to sign SSL connections when MWG has to intercept them. The user may receive a popup warning if the Root CA is not installed on his browser, but authentication will work and access should be possible afterwards.
2.) Do not perform authentication for HTTPS websites. In this case a request to an HTTPS website will not be authenticated but simply allowed. This means that accessing an HTTPS website before authenticating means, that the request stays unauthenticated (no user name in the log). This will only happen if there is not a known authentication server session. If you browse to an HTTP site, the next minutes (depending on the session length) will also cover all HTTPS requests, so the risk of accessing HTTPS sites is minimal (but present).
3.) Build a rule that catches a CONNECT request which is unauthenticated and redirect it to an HTTP site for authentication. This may cause problems for embedded objects, but may be an option. This will only work in explicit proxy environments.
4.) Increase the session length for the authentication server. If you do not have users which share the same PC you can increase the period to 4, 8 or even 12 hours. In this case the user only authenticates once in the morning, and the rest of his shift all requests from this IP address will be associated to this user. In this case the problem would only occur if you wait X hours, then start your browser and access an HTTPS website. If you start the browser in the morning, go to an HTTP website and authenticate, all other requests made during the rest of the period should work fine.
As mentioned earlier this is what I THINK the problem could be. Maybe it would be helpful to get in touch with support for additional assistance as well.