Well,
Firstly, I would like to start complaining since a PM's envelope for no reason is invisible and I can't figure out if it's a kind of a limit that has been set on my account or the problem is globally?
When I'm trying to open the url I get an error relating to a module being inaccessible.
Then I reported the problem to support@mikrotik.com, I even got a reply with my case which is SUP-30646 though the recovery password module doesn't want to send me an email so that I can reset my password.

So I decided to write about the problem at my post while the forum is working yet.
-------------------------------------------------------------------------------------------------------------

My question is about certificates. As you might already know if a self-signed certificate is used in a hotspot in all likelihood a 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). I've been thinking of what if I buy a certificate for our domain (company.com) from CA, then install an internal DNS server, create a subdomain like internal.company.com and use the certificate with a local portal website let's say it's located by the link: wifi.internal.company.com. Would it help me to deal with the brower's drops?

Thank you for helping me!

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.

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.

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.....

If the problem is:

... 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).

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.

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, 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 a Positive SSL Wildcard would work for my subdomains as I expect - yeah! The result should be the same I even don't need to forward ports making visible my hotspot from outside.

p.s. It doesn't matter google, facebook, youtube or any other domain. The most important that the domain you use has its own a wildcard SSL certificate. The browser should fetch any https request and redirect an authorized user to a captive portal.

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.

There are two parts:

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. That's solved by hotspot check described in previous post. The fetched http page is some predefined one with known content, so when browser gets something else, it knows there's something in the way and assumes it's hotspot.

And then there's actual hotspot login page, to which user is redirected, and that's what you can buy certificate for.

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.

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.

The problem relates to not a captive portal or phone. It's a matter of security/ When a website like google.com should have a particular certificate and a browser you're opening a website prevents those redirects since it considers those redirects like someone is trying to substitute a genuine certificate with a self-signed one.

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.

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....

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.

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.

Here's my settings (see the attachment)!

I should be at work tomorrow provided I don't forget I'll record a short video so that you don't doubt my words. :)

However, I think that it's also possible on any hotspot. The most important thing is to have a valid SSL certificate issued by CA and in my case DNS server would help me to use a certificate in my subdomains.

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.

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.

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 haven't dived deeper into the subject. I don't know answers. However I remember reading a message about the issue on the unifi forum like this one. Someone explained that it happens because of a self-signed certificate since it's considered as untrusted by browsers and if you use a local IP address you cannot assign a certificate issued by CA to your local IP address - that's the whole magic of preventing users from being redirected via https protocol.

Ok, so here you have quick start:

Each certificate is valid only for listed names. It can be just one (www.example.net), multiple (www.example.net and www.example.com) or any subdomain (*.example.net; that's wildcard certificate). When browser tries to connect to server X, it requires that certificate provided by server includes X. If not, it's not valid and you'll get warning. Certificate also needs to be signed by trusted certificate authority (browsers has built-in list of CAs).

You can get trusted certificate for own domain, either commercial one or free from Let's Encrypt (and few others). This certificate is good for your actual hotspot login page. If it's e.g. hotspot.company.tld, you will have certificate for this name and clients won't complain when they connect there.

But the same certificate is completely useless for redirection, because user is connecting to some random internet site (and has no idea that it will be intercepted by hotspot) and your certificate doesn't contain that name. So browser will complain.

Then 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.

Then 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.

Let's read a little bit
https://developer.android.com/about/ver ... ive-portal

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.

As you will see in my video, my phone running KitKat, Android 4.4.2.
From my experience it makes no difference what Android version you have or which hotspot you connect to. It doesn't matter detects your phone a captive portal to sign in. As long as you don't have a SSL certificate issued by CA all those attempts will fail in the end. Even if your phone detects a hotspot service it won't be redirected to a capitve portal provided there is a https request and the captive portal doesn't have the certificate. Chrome takes precedence over those redirects, not a captive portal service in your phone (or not only). Doomed will definitely fail since a browser sees an unreliable certificate which has been self-signed.

I took my old Samsung Galaxy Note 3 to demonstrate how UniFi controller intercepts and redirects any https requests to my captive portal even on KitKat.
https://youtu.be/TEnUKKItMB8

It's been working for about three years.... Thousands phones of all kinds running on different OS and using a wide variety of browsers have been connecting to the hotspot. No problem so far.


p.s. If you paused the video (or I'll pause it instead) you will see that the first request sent is google (which is https), not a captive portal itself even though I hit to sign in to the network

I'm no Android expert, but right after you connect, there's immediatelly "Sign in to Wi-Fi network" on top of screen, which sounds very much like hotspot detection. You can test if you see the same thing when you connect to unlimited network. For example here:

https://android.stackexchange.com/quest ... -in-or-not

they say that it's already in 4.4.4, so your 4.4.2 is likely to have the same thing.

One thing I'm sure about, you can't intercept and redirect https request without having valid certificate for requested server. That would require breaking https. And if you could break https for hotspot redirection, then someone else could break your https connection to your bank, for example.

You can easily test what exactly your phone does, create hotspot on RB, run packet sniffer on wireless interface, save all packets to file, open it in Wireshark or something, and look for request to http://clients3.google.com/generate_204 or possibly any other http (not https) request.

But just that we are clear, I don't say that certificate is useless. When your hotspot login page uses https, then after the redirection "somehow" succeeds, browser sends another https request to your hotspot. And it of course expects valid certificate, as with any other https website.