Again, you need to understand how it works. What hotspot is doing is basically MITM attack. User wants to open http://someserver.net, hotspot hijacks the connection and redirects it elsewhere. User's browser actually thinks that the redirection came from someserver.net and has no way to tell that it's not true.
Https prevents MITM attacks. If browser tries to connect to https://someserver.net, only thing it will accept is response from server with certificate valid for someserver.net (*), and hotspot doesn't have it. There's no mechanism for hotspot to say "no, it's ok, ignore the error just once now, I'm not evil attacker, I'm friendly hotspot". The reason is clear, it's exactly what any evil attacker would say.
(*) Users can choose to ignore certificate errors, but it's extremely bad practice to teach them to do that. Because when they encouter real MITM attack, they will think that it's ok, as so many errors before.
Since people want to create hotspots and it's not possible to compromise https, hotpot detection must be done using other method. It's responsibility of either web browser or operating system. They have own servers that return always the same response. They try to send http request to these servers and check what they get back. If it differs from predefined response, something must have changed it, most likely hotspot. So they open new window with what they got, which is hotspot redirection and resulting login page.
If it doesn't happen, then either browser or OS is doing something wrong, or the hotspot operator whitelisted some servers and among them the ones used for hotspot detection. So it looks like internet access is available, but it isn't.
Instead of redirecting https, you can block all https connections (an option was recently added for that
), so users won't get certificate errors. But it doesn't really solve the problem with failed hotspot detection, because if that doesn't work, it will look like there's no internet at all.