Captive portal does not work with https!

Here to help

Captive portal does not work with https!

I have a cisco meraki AP infrastructure. I defined an SSID with radius authentication and a walled garden. Everything was ok until the web-world migrate to https. That's the problem:


- the domani is not in the walled garden;
- correctly redirect the user to the login splash page to authenticate the user;
- does nothing and the browser got time out;

Asking to meraki they said that can't works because: "Meraki devices are not able to decrypt. This is why it's working fine with http (no encryption) but not with https (encryption)".




- if I put the domain in the walled garden;

- works!

Why? I'm not an expert but seems to me that meraki can detect the url the user ask for, to check the walled garden. Isn't it? Why if the domain is not in walled garden, meraki won't redirect to the login splash page even if it's in https? Let me understand, please, why if a request is out of walled garden, meraki won't redirect to splash login page regardless of http or https.

Kind of a big deal

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 using an encrypted connection - that's what starting the URL with HTTPS means. So your browser goes out to get the public certificate from to encrypt the connection. However, at this point the Meraki device intercepts it and can't do anything. It could pass back the 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. 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.


I have been telling my users to go to to log in. Do you have any HTTP sites that you tell them to hit to see the authentication page? 


I know this isn't a Meraki thing but an Internet thing about how https is designed to work. 






Kind of a big deal

I also use, etc. when I know I have to go to a captive portal.

Luckily, modern operating-systems have captive-portal detection which always uses HTTP. In the future a new DHCP-option will be used to find the captive portal.

Normally I have 500 users a day! Not now under covid situation. But normally I have such numbers, most

of them use their own laptop with wahtever configuration. 

Good day! I am also encountering this issue using Google as authentication. It was working fine recently then our end-user reported that the redirect to google splash page is not working on mobile devices. Is there any solution to this other than instructing their users to go to an HTTP site first since most of their users are not tech-savvy.

My library has some free pc access. We give users: firefox, chrome and edge. Firefox can detect the captive portal and suggest, in a bar, to login - no ones watch it! - the other browser don't.


As you can immagine I give to users our web page, that is free. Only when user want to get out the walld garden they should authenticate themselves. Users can't understand such "trick": using rather than They normaly use google as internet. That's it! And google gives back only https link. And nothing works. And user call us that nothing works.


That is very annoying!

Getting noticed

I'm dealing with this right now and I'm not actually sure how to handle this.  We use the splash page on our guest network so the guests can accept the terms of service.  It seems that I have three options.  1) Allow non-HTTP traffic and allow guest users to bypass our network firewall rules.  2) Block all access to the network until the splash page is clicked.  Knowing that half of the guest users will just time out because they are accessing HTTPS.  3) Turn off the splash page and just have an open network with no terms of service

I've opened a ticket with Meraki support and I'm not sure they even understand what I'm talking about.  The Meraki documentation clearly states that what we are experiencing is as designed.  

Curious, how are you all handling your guest network portals?

Kind of a big deal
Kind of a big deal

We took over a site that had option 1 and the odd thing is,  for pretty much every device it does make you click through the portal...  However we changed to option 2 as that seemed better and we found Android devices seemed fine, but Apple devices had issues.   We're not sure of the best way forward either!

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.