hello guys, now all the pages where you browse are 80% in https.
On the RB 3011 until the customer searched for pages in http, the problem of the login request was not a problem, now instead if a customer looks for example google, the page is in https and therefore the login page does not appear and therefore from connection error. Did Mikrotik do something about this?
For now I have buffered creating an ssl certificate and activated the https protocol with certificate on the rb, only that new customers don't know that they have to install the certificate the first time.
For the certificate I followed this guide https://www.youtube.com/watch?v=CAvDMtyOx5k
but if you have any better advice I am grateful.
Thank you all

Some Facts about HTTPS redirection

• Hotspot does not redirect SSL 443 sites , unless you enable HTTPS redirection and use a signed or self-signed certificate.

• By using self signed certificate, SSL redirect warnings will still be present. As part of SSL protocol, cause hotspot captive portal will be seen as Man-in-the-Middle by SSL.

• Browser will still warn end-user about redirection even with CA signed certificate! This warning message cannot be avoided. They will always get a certificate error, because the hotspot page is not the page they requested.

Most browsers tend to remember which sites use HTTPS and will automatically send you to the secure page. So when you type 'google.com' without the 'https://', chances are that you are taken to the secure (HTTPS) page.

Workaround to alleviate the issue..

As high percentage of browsers home pages are set to google.com, we can add it to the walled garden.

When users are directed to https://google.com the google page will load instead of an error. This is better than displaying the “no internet connection error”.

While they are in google page, there’s a high tendency that the user will click on a http link and get the login page.

Make sure that you aren't allowing any sites in the hotspot before user auth, if you allow connectivity to Google / Apple / etc, the browser will think it has internet and will not trigger the captive portal. Any modern browser otherwise will notice the connection test is failing and prompt the user to log in to the portal.

Beyond this there is nothing else you can do, as the security of HTTPS negates attempts to intercept such requests.

How can I ensure that I do not allow access to any site in the hotspot before the user's authorization? should I make a special rule about RB?
Could you tell me how can I do?

Make sure that you aren't allowing any sites in the hotspot before user auth, if you allow connectivity to Google / Apple / etc, the browser will think it has internet and will not trigger the captive portal. Any modern browser otherwise will notice the connection test is failing and prompt the user to log in to the portal.

Beyond this there is nothing else you can do, as the security of HTTPS negates attempts to intercept such requests.

As Op noted, great advice but how????

Just make sure nothing is in the walled garden. As long as the user is using a modern browser or phone, they should get the prompt for the portal.

Just make sure nothing is in the walled garden. As long as the user is using a modern browser or phone, they should get the prompt for the portal.

This has been my experience too in testing. I only use HTTP CHAP and Cookie for my Hotspot server login settings, not HTTP(s). I will have more live experience in a few months.

could you share your configuration? I would be grateful

Could you share your configuration? I would be grateful.

See here in this post.

it would be ideal to create a script that intercepts the call to the https page and verifies if that ip that requests the https page is authenticated.
If authenticated, there are no problems, otherwise it will load the login page.
Easy to say but to do I wouldn't know where to start

You don't start, since that is impossible. The security of HTTPS negates attempts to intercept such requests, unless you want to teach your users to blindly ignore serious security errors.

so we have no hope for a solution