Thanks for your reply. Do you mean I need to buy a Positive SSL Wildcard or Essential SSL Wildcard? There are dozens of certificates I don't know which one to buy.....Off course it will fix your issues.
Just make sure you have a valid certificate for any URL that an end-user is redirected/pointed to.
If you purchase a wildcard-cert for *.mycompany.com you are completely flexible in what you want to achieve.
i.e. when user tries to connect to e.g. https://google.com, then unless you buy certificate valid for google.com, there will be error. And no, you can't buy certificate for google.com.... user's attempt to reach out a website via https protocol would be considered as insecure and a browser will drop the connection (i.e. a redirect).
Well, I haven't tried a Mikrotik hotspot particularly with SSL certificate however I know how I set up my UniFi Controller. I didn't use a DNS server therefore when a user connected to a hotspot they were redirected locally i.e. using local IP addresses like 192.168.1.10. The problem was that even though I used a self-signed certificate a browser always complained about the certificate. You needed to take your own risk bla-bla-bla.... to make a long story short it was a matter of inconvenience. Sometimes there were drops calling HSTS if I remember correctly they prevented redirects completely. It was impossible to reach out my UniFi contoller. The solution was I installed Let's Encrypt certbot for my dynamic domain , forwarded ports, whitelisted my public IP address in the UniFi Controller and all connected users were correctly redirected to my captive portal. No errors, no attempts to drop requests, no attentions. Just nothing. As it should be.If the problem is:
i.e. when user tries to connect to e.g. https://google.com, then unless you buy certificate valid for google.com, there will be error. And no, you can't buy certificate for google.com.
Well, mate. I described how I've solved the problem. Believe me or not a captive portal service that goes pre-installed in my phone is waiting for about 15-20 seconds before inviting a user to sign in. Most users open their browsers by the time the CP service reacts. What they really get in the end is just many drops while being redirected in Chrome since there are dozens of tabs that have been already opened.This problem cannot be solved in a hotspot, captive portal, etc.
It has to be solved by the client device. And modern client devices already solve that issue. So you should not see it anymore.
The solution varies per manufacturer but the common part is that when you open a browser it first fetches some http page (which you do not see) and checks the response.
When this works OK it assumes that it is on an open network. When it gets some redirect or other error it shows you the page it is redirected to, which will normally be a portal login page.
This all happens before the user has a chance to open some https page. Because that would not work.
EXACTLY. It's exactly what my UniFi Controller does at the moment. If you're unauthenticated user.... and trying to open any https website you'll be redirected without any warnings to my captive portal the same as you requested a website via http protocol. Smoothly....When user tries to connect to https://something, browser won't accept anything else than valid certificate for "something". It's impossible to redirect this request without user seeing warning about invalid certificate.
Here's my settings (see the attachment)!Congratulations, in that case creators of UniFi Controller have successfully broken https. Or the other explanation is that there's something else you don't see.
In mikrotik case you even don't need to have a DNS server, I've forgotten they provide static DNS records. You may try to use a record like this wifi.yourcompanyname.com if you've got a wildcard certificate you can apply it on the subnet. Try to upload it to the router. A user should be redirected to a captive portal not by a local IP address but by this link wifi.yourcompanyname.com otherwise it won't use the certificate.I'll still doubt your words, because there simply isn't any such mechanism in https (specifically in tls part, which handles the encryption) that would allow server to tell client "hey, forget about connecting to X and connect to Y instead". :) I'm sure the checkbox for redirecting https has some purpose, but the question is what exactly it does.
Let's read a little bitThen why does it work even when user starts with https page? It's the previously described hotspot detection. It's standard thing, all common clients have it and use it, and in most cases it works correctly. So hotspot is detected and login page shown even before the doomed to fail attempt to redirect https.
As you will see in my video, my phone running KitKat, Android 4.4.2.Since Android 5.0 (API level 21), Android devices have detected captive portals and notified the user that they need to sign in to the network to access the internet. Captive portals were detected using cleartext HTTP probes to known destinations (such as connectivitycheck.gstatic.com), and if the probe received an HTTP redirect, the device assumed that the network was a captive portal. This technique can be unreliable because there is no standard URL to probe, and such probes could be mistakenly allowed or blocked (instead of redirected) by captive portal networks. The API allows portals to provide a positive signal that login is required, along with a URL to log in to.