That's exactly what you will need to do. "Allow CONNECT" should be after authentication otherwise you'll have authentication issue as you described.
Specifically this problem has to do with whitelisting the URL.Path for HTTPS websites. If this was an HTTP site, you wouldnt have this problem.
During SSL connection establishment, the MWG (or any other proxy) only knows the host you are connecting to (e.g. facebook.com), there is NO path information available. This SSL connection establishment is the CONNECT and CERTVERIFY phases.
Only after we've cracked open the tunnel do we get the URL.Path information.
So, if there is a site you wish to whitelist based on the path AND it's HTTPS, then we need to allow the CONNECT and CERTVERIFY for the domain first, then allow the path.
What what the SR # you opened by chance?
Yesterday, case 4-17668322823. They (the tech was asking a colleague) were going in the right direction (bypassing the Default – Category Blocklist for the Connect/CertVerify cycle) but not correctly integrated with the ruleset.
A week ago (I had to close the case because it was nearly 22h30 and I had to prepare for a trip to another site), case 4-17646339299. The tech diagnostic the whole connection and arrive by himself to the correct conclusion (that I didn’t understood at that point) but he evidently didn’t know about Doc-4810.
I must say that I didn’t realized until yesterday that with each cycle, we are going across the whole ruleset (except when reaching a Block, Stop Rule Set and Stop Cycle). My request was going through the SSL Scanner so, URL.Path value was supposed to be available… And the rule tracing was driving me crazy… Why didn’t it match on the whitelist rule!!!
Ok, I know a little bit more now…