Hi @Corsani, this is to do with the way the browser handles HTTPS sites. When you put something in the walled garden then Meraki allows access to it before the user has authenticated, so it just passes the traffic straight to the site. This is exactly the same for whether you're accessing an HTTP or HTTPS site. It's just as if the Meraki didn't exist - hence why it works.
In the scenario where you are trying to authenticate you need to think about what is happening (this is going to be a pretty high-level explanation, but should help you to understand it). In the case of an HTTPS request you're asking to fetch a page from bing.com using an encrypted connection - that's what starting the URL with HTTPS means. So your browser goes out to get the public certificate from bing.com to encrypt the connection. However, at this point the Meraki device intercepts it and can't do anything. It could pass back the bing.com public certificate, but then it doesn't have the private key so can't encrypt/decrypt the messages. Or it could pass back its own certificate and become a 'man-in-the-middle', but then the browser will generate all sorts of errors because the certificate name won't match the website name (i.e. bing.com). And this is where the problem lies, there is no easy way to do web-based authentication for HTTPS based sites. The user needs to first go to a HTTP (unencrypted) site to authenticate successfully, and then once that's happened all should be good.
