Hi all,
I have activate hotspot for wifi user on my RB951. Problem is when users type google.com, they are redirected to https://google.com and an SSL error appears. "Unable to make a secure connection to the server."

This only happens when users try to access a https site. Normal http sites redirect correctly to the hotspot login page.

Does anyone have a possible solution to this?

If the hotspot is not re-directing that traffic correctly then there may be something wrong with the dynamic rules that get created. Look in the firewall, under NAT, and see if there are rules for port 80 and port 443. They should be dynamically created. Make sure that there are not any static NAT rules above the dynamically created ones. Which router OS version are you using?

Hotspot does not redirect SSL 443 sites , unless you enable HTTPS redirection and run the hotspot on 443 on the Mikrotik.

You will then substitute the lack of redirects for an HTTPS certification error.

Hotspot does not redirect SSL 443 sites , unless you enable HTTPS redirection and run the hotspot on 443 on the Mikrotik.

You will then substitute the lack of redirects for an HTTPS certification error.

That is sad to hear. No known workaround yet without using https on hotspot? I think is better not to have certificate error as it would confuse the customers.

hi friends,
i install hotspot on rb2011, my problem is no redirect https page,
can any help me to redirect https ?? the ssl alert never mine

YOU STILL NEED ONE SSL CERTIFICATE (TRUSTED OR YOURSELF MADE, BUT VALID) TO MAKE HTTPS WORK!!!


Create one fake for you own (change the fileds accordingly):
and enable ip / service / www-ssl and set the service to use certificate "common-name"
and enable, on hotspot profile, login by https, selecting as certificate "common-name"


You can not remove browser warning.
If you buy one ssl certificate, buy it for 1.2.3.4, not for hs.pippo.com or when redirect warning appear.
But if IP are correct, all work without warning, because the certificate are for IP, not for DNS name...

I don't actually mind the error when its a https site... it seems that using the above method does work but still brings up SSL error on every page... is there anyway of getting MT to use https when a https site is requested and using http every other time?

Best,
Patrick.

Hi,

I have same issue, may i know where to buy the Cert to avoid the warning page?

Thanks & regards

You can buy certs through most of the hosting sites like Go Daddy, Site Ground, Network Solutions, ect.

YOU STILL NEED ONE SSL CERTIFICATE (TRUSTED OR YOURSELF MADE, BUT VALID) TO MAKE HTTPS WORK!!!


Create one fake for you own (change the fileds accordingly):

Code: Select all

/certificate add name=self-signed-certificate common-name=common-name country=it days-valid=365 key-size=2048 locality=locality organization=organization state=state trusted=yes unit=organization-unit subject-alt-name=DNS:my.local.net,IP:192.168.0.101,email:my@email.it key-usage=digital-signature,key-cert-sign,crl-sign;
/certificate sign template=self-signed-certificate ca-crl-host=192.168.0.101 name=common-name ca-on-smart-card=no;

and enable ip / service / www-ssl and set the service to use certificate "common-name"
and enable, on hotspot profile, login by https, selecting as certificate "common-name"


You can not remove browser warning.
If you buy one ssl certificate, buy it for 1.2.3.4, not for hs.pippo.com or when redirect warning appear.
But if IP are correct, all work without warning, because the certificate are for IP, not for DNS name...

I have V6.10 and the second command show an error: expected end of command (line 1 column 52), the firts command is ok.

Update to 6.18

on 6.7 ca-crl-host and ca-on-smart-card are unsupported, try to remove it:

rextended

We are now working with 100% secure hotspot with a valid SSL,

but when users try to access initial page with ssl like https://www.google.com

still warning.

in other post you say anything about 2 redirects to solve this kinf of problem.

can you explain how you do this?

Ps: Sorry about English.

rextended

We are now working with 100% secure hotspot with a valid SSL,

but when users try to access initial page with ssl like https://www.google.com

still warning.

in other post you say anything about 2 redirects to solve this kinf of problem.

can you explain how you do this?

Ps: Sorry about English.

As write on my post before:

You can not remove browser warning.
If you buy one ssl certificate, buy it for 1.2.3.4, not for hs.pippo.com or when redirect warning appear.
But if IP are correct, all work without warning, because the certificate are for IP, not for DNS name...

Hello,
to bypass the ssl warning on the redirecting https sites to hotspot login page (because they are not in the walled garden), I assume we can solve with a certificate?
Do we need multiple certificates for multiple hotspot ip addresses? For example one hotspot is on 10.1.10.x/24, next is on 10.1.11.x/24 etc.

Thanks in advance,
Vedran

yes, one for each IP

my solution to this long time problem as high percentage of browsers home pages are set to google.com

add this expression to your walled garden in the host field

:^www\.google\.com$ with port 443

now when they are directed to https://google.com the google page will load instead of an error, Better in my opinion than an error. 99 times out of a 100 the user will click on a http link and get the login page.

yes, one for each IP

I wasnt clear enough, we have multiple hotspot locations, each hotspot in each city; however, all of them are going trough vpn to one public ip address, the central data center.
I was wondering if one certificate for that one public ip address is going to be enough to cover all of the hotspots that go trough it?


Thanks in advance,
Vedran S.

my solution to this long time problem as high percentage of browsers home pages are set to google.com

add this expression to your walled garden in the host field

:^www\.google\.com$ with port 443

now when they are directed to https://google.com the google page will load instead of an error, Better in my opinion than an error. 99 times out of a 100 the user will click on a http link and get the login page.

Thank you karina, after 4 hours of trying to get rid of the warning your sollution is the best suited for my config. I only use the hotspot to tell users to connect via PPPOE and show them a small tutorial on how to create a PPPOE connection, so buying a certificate yearly for 55 euros was the LAST option. And the warning translated from my native language in chrome says that someone is trying to steal their passwords and hijack their web pages witch for a small ISP is very bad publicity.

You can not buy a certificate to a local IP. All certification's companies require a public IP or public DNS.

Only be possible by creating a certificate from Linux, but then the browser displays a warning that the certificate is not trusted.

Is there any solution?

You can not buy a certificate to a local IP. All certification's companies require a public IP or public DNS.

While what you say is true, there is another way: You can go to www.startssl.com and get yourself a FREE level1 SSL certificate for your domain (whoich must exist) and use that DNS name for your mtik HS portal like this:
1. make sure you have a real domain, for example: mysite.com
2. create an working email address webmaster@mysite.com
3. decide which FQDN will your hotspot portal use, for example: hotspot.mysite.com
4. on mikrotik edit server profile, general, and for DNS name use hotspot.mysite.com
5. on startssl website verify your domain through email and create a free ssl cert for hotspot.mysite.com
6. have in mind that mikrotik hotspot portal IP address can be any address, even 1.1.1.1 it does not matter!
7. import the ssl cert (I Know how to do it, but that's another topic) and try to login as guest - it will work with HTTP and your browser will redirect to https://hotspot.mysite.com/login?dst=wh ... ried.to.go

I hope this solves most of your issues so you can now help me:
When the person tries to go to http://www.domain.com it redirects to https portal and the ssl cert Works and everything is very cool
But when the person tries to go to https://www.google.com then the mikrotik does not redirect anywhere - the connection is just Dead!

I have checked firewall rules and they seem OK to me, but obviously something is wrong because many people complain for this problem. Does anyone Know what is the problem?

Zvjer,

Go to IP > Services and enable www-ssl. Then go to IP > Hotspot > Server Profiles and click on your profile. Then check "HTTPS" under "Login By"

Zvjer,

Go to IP > Services and enable www-ssl. Then go to IP > Hotspot > Server Profiles and click on your profile. Then check "HTTPS" under "Login By"

No, it does not work properly.

The truth is that I have not had www-ssl enabled before you told me to, but after enabling it (and giving it a proper certificate) it did not help at all. Even before I have enabled www-ssl my HTTPS captive portal was WORKING OK with Internet Explorer, but not with Firefox.

For example: when I try going to Facebook web page (it is https) through Internet Explorer - mikrotik opens it's own https login page (as expected) and show no error because the certificate IS VALID. But if I do the exact same thing with Firefox - an error shows that my certicifacate for mydomain is not valid for Facebook.com - which is understandable, because mikrotik hotspot system did not open that magic url: mydomain.com/url?facebook whatever...

My opinion is that Mikrotik OS 6.22 has some kind of a bug with all the browsers except IE and I'm very serious about it. Where can I file a bug?

You can not buy a certificate to a local IP. All certification's companies require a public IP or public DNS.

While what you say is true, there is another way: You can go to http://www.startssl.com and get yourself a FREE level1 SSL certificate for your domain (whoich must exist) and use that DNS name for your mtik HS portal like this:
1. make sure you have a real domain, for example: mysite.com
2. create an working email address webmaster@mysite.com
3. decide which FQDN will your hotspot portal use, for example: hotspot.mysite.com
4. on mikrotik edit server profile, general, and for DNS name use hotspot.mysite.com
5. on startssl website verify your domain through email and create a free ssl cert for hotspot.mysite.com
6. have in mind that mikrotik hotspot portal IP address can be any address, even 1.1.1.1 it does not matter!
7. import the ssl cert (I Know how to do it, but that's another topic) and try to login as guest - it will work with HTTP and your browser will redirect to https://hotspot.mysite.com/login?dst=wh ... ried.to.go

I hope this solves most of your issues so you can now help me:
When the person tries to go to http://www.domain.com it redirects to https portal and the ssl cert Works and everything is very cool
But when the person tries to go to https://www.google.com then the mikrotik does not redirect anywhere - the connection is just Dead!

I have checked firewall rules and they seem OK to me, but obviously something is wrong because many people complain for this problem. Does anyone Know what is the problem?

Hi !
I did this and my certificate is working good on the hotspot login page but I still get the Certificate warning if a Hotspot client has his browser set to open https://www.google.com or any https website... I already put the certificate in www-ssl in "services" too.
Does someone has successfully resolved this issue with the "https" website using the "hotspot" feature ?

Thanks

Hi !
I did this and my certificate is working good on the hotspot login page but I still get the Certificate warning if a Hotspot client has his browser set to open https://www.google.com or any https website... I already put the certificate in www-ssl in "services" too.
Does someone has successfully resolved this issue with the "https" website using the "hotspot" feature ?

Thanks

Can you please confirm that there is no problem with Internet Explorer 11? (I use Windows 8.1)

Hi !
I did this and my certificate is working good on the hotspot login page but I still get the Certificate warning if a Hotspot client has his browser set to open https://www.google.com or any https website... I already put the certificate in www-ssl in "services" too.
Does someone has successfully resolved this issue with the "https" website using the "hotspot" feature ?

Thanks

You can't "resolve" this issue as it's how https works. The certificate is to prove your identity. When you interrupt a connection from the client to a https website you are NOT that website therefore the client will show a warning.

Please see also my post http://forum.mikrotik.com/viewtopic.php ... 71#p458147

You can't "resolve" this issue as it's how https works. The certificate is to prove your identity. When you interrupt a connection from the client to a https website you are NOT that website therefore the client will show a warning.

Please see also my post http://forum.mikrotik.com/viewtopic.php ... 71#p458147

You are wrong because when the client asks to open a https web site (for example Google) the mikrotik WILL INTERCEPT this attempt and redirect the user to ANOTHER page which is https://myhotspot.mydomain.com/?dst=htt ... google.com and the certificate will be valid.

FURTHERMORE both Netlantique and I have already tested this and confirmed it is working (at least I have confirmed) with Internet Explorer 11 on Windows 8.1 so the problem remains in some kind of a bug on the mikrotik which prevents the redirection if another browser is in question.

EDIT: Let me refraze the problem. The problem is that MIKROTIK FAILS TO REDIRECT the user to the page where the certificate will be valid... This happens on Chrome and Firefox.

You are wrong because when the client asks to open a https web site (for example Google) the mikrotik WILL INTERCEPT this attempt and redirect the user to ANOTHER page which is https://myhotspot.mydomain.com/?dst=htt ... google.com and the certificate will be valid.

The client first makes a TCP connection to google on port 443 which get intercepted. The client is not aware of this interception. During the SSL handshake the the router is presenting it's own certificate which is obviously not issued for "google.com" but for "myhotspot.mydomain.com". At that point a proper SSL implementation hangs up and shows a warning as the Hostname of the certificate is not matching with the one which is expected. "myhotspot.mydomain.com" != "myhotspot.mydomain.com". The redirection is happening via HTTP. As the client hangs up before it sends the HTTP-request there is no chance for the Router to send a HTTP-response with a redirect instruction.

Why it's working with Internet Explorer? I don't know. Maybe it handles such a hostname missmatch in an uncommon way. I might research that later as it would be a bad implementation of SSL i'm interested in.

The client first makes a TCP connection to google on port 443 which get intercepted. The client is not aware of this interception. During the SSL handshake the the router is presenting it's own certificate which is obviously not issued for "google.com" but for "myhotspot.mydomain.com". At that point a proper SSL implementation hangs up and shows a warning as the Hostname of the certificate is not matching with the one which is expected. "myhotspot.mydomain.com" != "myhotspot.mydomain.com". The redirection is happening via HTTP. As the client hangs up before it sends the HTTP-request there is no chance for the Router to send a HTTP-response with a redirect instruction.

Why it's working with Internet Explorer? I don't know. Maybe it handles such a hostname missmatch in an uncommon way. I might research that later as it would be a bad implementation of SSL i'm interested in.

This is very nice explanation and I suppose you are right which also means that this solution will not work.
But having taken into consideration the fact that more and much more hotspot guests arround the world are trying to Access the HTTPS page as their First page after connecting to a network we have this global problem which must be solved one way or another. Many of my clients are now asking me to fix this for them and I thought I have had it fixed but it appears that the fix only Works with IE.

If you will Research this please post your observations on why does it work with IE. If it could help I could make two wireshark traces on the guest machine. One with IE and another with Firefox.

Just a thought... Maybe if the Hotspot's certificate is issued for the IP address, and not the domain name? (which AFAIK is allowed by the protocol)

THAT, coupled with making the router, before login, redirect all DNS requests to a custom DNS server where any name is resolved to the router's IP address (with a TTL of 1 second, to minimize requests to the router post login).

If you do that, then maybe browsers will treat the certificate as valid, since the IP matches, and you're redirected to a site that also has a valid certificate. I haven't researched this, but I'm writing it down non the less (so that I don't forget to try it out... eventually).

Is it possible to issue a certificate per IP address? I don't think that "StartSSL" CA has this service. Don't Know about Comodo either.

Can you please confirm that there is no problem with Internet Explorer 11? (I use Windows 8.1)

I have tested Internet Explorer over Windows 7 and its not working, still show a Certificate Warning.
Firefox also show an certificate warning but Chrome handle this differently, Chrome show a certificate warning but instantly pops another "Tabs" with the Login page without the warning.

So if a resume this. Google Chrome is the best browser for this situation since its open automaticly a new Tab with the Hotspot Login Page but also open the Certificate warning on the first Tab. When you "Log On" the Tab closes and the first Tab where the certificate warning was showing, will appeir as your https://www.google.com or any other https "welcome" page you had set on Chrome.

Google Chrome has some type of "Hotspot Detection" mechanisim.

Same problem here... I have bought an ssl certificate and it is loaded fine. When it captures an http request it is taking me to my https://my.domain.xx and it accepts my certificate... everything is ok... green lock on the address bar and so on...
when it captures an https request it is trying to load my certificate on the requested page eg. https://www.facebook.com and it is trying to validate my certificate on the requested page not on the page that it shall redirect to !!!

I think that there has to be an update on the way it redirects.. it should first redirect to the login page and then request a certificate validation or else it is a big problem for the end users to realize they manually have to request an http page in order to get the proper login page...

I haven't tried buying an intranet ssl certificate to see how it works...

any ideas for a workaround?

Zvjer,

Go to IP > Services and enable www-ssl. Then go to IP > Hotspot > Server Profiles and click on your profile. Then check "HTTPS" under "Login By"

No, it does not work properly.

The truth is that I have not had www-ssl enabled before you told me to, but after enabling it (and giving it a proper certificate) it did not help at all. Even before I have enabled www-ssl my HTTPS captive portal was WORKING OK with Internet Explorer, but not with Firefox.

For example: when I try going to Facebook web page (it is https) through Internet Explorer - mikrotik opens it's own https login page (as expected) and show no error because the certificate IS VALID. But if I do the exact same thing with Firefox - an error shows that my certicifacate for mydomain is not valid for Facebook.com - which is understandable, because mikrotik hotspot system did not open that magic url: mydomain.com/url?facebook whatever...

My opinion is that Mikrotik OS 6.22 has some kind of a bug with all the browsers except IE and I'm very serious about it. Where can I file a bug?

Same problem me too.

Google Chrome: https://www.google.it wrong redirect and connections refused
Mozilla Firefox: https://www.google.it sec_error_inadequate_key_usage
Internet Explorer: work

Same problem me too.

Google Chrome: ERR_CERT_AUTHORITY_INVALID
Mozilla Firefox: sec_error_inadequate_key_usage
Internet Explorer: work

RouterOS version tested: 6.22, 6.23, 6.24rc4

I also have this issue

I started to play with this out of curiosity, because it interested me how IE could magically work, while other browsers don't. But all browsers behave exactly the same here, no exceptions. No working IE, no extra tab in Chrome, just plain and simple certificate error in all of them (IE11 in Win8.1, latest Chrome, Firefox and Pale Moon). Which is exactly what I expected would and _should_ happen.

If your IE works or if your Chrome shows you extra login tab, is there perhaps anything special in your hotspot config (I just used defaults from Hotspot Setup)?

The problem is that isn't a "simple and plain" cert error... i can't continue to the site, there is no "Continue" in Chrome and Firefox, in IE i see the cert error but i can continue. It seems that FX/GC test the hotspot cert with www.google.it hostname and not the hotspot hostname.

I started to play with this out of curiosity, because it interested me how IE could magically work, while other browsers don't. But all browsers behave exactly the same here, no exceptions. No working IE, no extra tab in Chrome, just plain and simple certificate error in all of them (IE11 in Win8.1, latest Chrome, Firefox and Pale Moon). Which is exactly what I expected would and _should_ happen.

If your IE works or if your Chrome shows you extra login tab, is there perhaps anything special in your hotspot config (I just used defaults from Hotspot Setup)?

For my test I used Windows 7 x64 with latest version of Chrome. Nothing special in my Hotspot configuration. In my browser its https://www.google.ca that I have set to open.

@tobiagrosselle: In your case, are you sure there's nothing wrong with the certificate? Does it work correctly when you access https://<your_hotspot_hostname>/ directly? Because neither ERR_CERT_AUTHORITY_INVALID nor sec_error_inadequate_key_usage (from your previous post) sound like the usual untrusted certificate problem. Is the certificate from trusted CA, some custom CA, self-signed, ...?

It seems that FX/GC test the hotspot cert with http://www.google.it hostname and not the hotspot hostname.

Of course. If client tried to establish encrypted connection to www.google.it, it expects to get certificate valid for www.google.it. Hotspot can't provide that and client must treat it as possible attack and show warning. This is to be expected.

@Netlantique: So in Chrome settings, out of the startup options, you have selected the last one, to open a page or group of pages, with only one page set, which is https://www.google.ca? If so, I'd really like to know, where the login tab comes from. If it happened here, I'd try to sniff packets to see if there's anything interesting going on.

@Netlantique: So in Chrome settings, out of the startup options, you have selected the last one, to open a page or group of pages, with only one page set, which is https://www.google.ca? If so, I'd really like to know, where the login tab comes from. If it happened here, I'd try to sniff packets to see if there's anything interesting going on.

I only have https://www.google.ca in the startup option (Open a Page only)
I have figured out someting also... When Google Chrome open the new tab, its open that link first: http://www.gstatic.com/generate_204
then its open my Hotspot Login Page with this: https://hotspot.MYDOMAIN.com/login?dst= ... nerate_204
I dont know where this address come from?!?

Google Chrome Version: 39.0.2171.95m
Router: CCR1016-12G
Packages Version: 6.23
Routerboard Firmware: 3.20

My certificate shows up fine when I access the login page directly (https) or if I access an http page which redirect me to my https login... all green locks... all fine... when the redirect starts from an https page then it tries to load my certificate with the page I tried to access eg. https://www.google.com ...

@tobiagrosselle: In your case, are you sure there's nothing wrong with the certificate? Does it work correctly when you access https://<your_hotspot_hostname>/ directly? Because neither ERR_CERT_AUTHORITY_INVALID nor sec_error_inadequate_key_usage (from your previous post) sound like the usual untrusted certificate problem. Is the certificate from trusted CA, some custom CA, self-signed, ...?

It seems that FX/GC test the hotspot cert with http://www.google.it hostname and not the hotspot hostname.

Of course. If client tried to establish encrypted connection to http://www.google.it, it expects to get certificate valid for http://www.google.it. Hotspot can't provide that and client must treat it as possible attack and show warning. This is to be expected.

+1 waiting for this solution! I have the same problem of you!

I have figured out someting also... When Google Chrome open the new tab, its open that link first: http://www.gstatic.com/generate_204
then its open my Hotspot Login Page with this: https://hotspot.MYDOMAIN.com/login?dst= ... nerate_204
I dont know where this address come from?!?

A 204/No Content is a relatively uncommon response, and is unlikely to be a response you'd get from a hotspot login page. Google apparently uses this to determine if you really have internet access:

http://stackoverflow.com/questions/1989 ... nerate-204

So it seems like Chrome does this 'generate 204' test itself natively, and in other browsers it can only run once the browser has already loaded a bit of Google javascript, or has it in cache.

I don't Know if any of you even considered what HSTS does, but effectively it kills any attempt of solving this issue whether you have a valid hotspot certificate or not! Look it up on Wiki and you will understand why I believe this cannot be solved on HTTP(s)level.

But maby we can solve this nightmare with DNS redirection if this will work:
Mikrotik should intercept all DNS requests and not only put his own IP address in place of EVERY DNS request but also it shoud add a TXT record to EVERY DNS request, something like this: domain.com IN TXT "1|yourhotspot.mikrotik.local" where domain.com is the client desired destination.

I have no idea how to configure this, so please help me out if someone knows how to implement it. Or even if someone knows if this theory stands at all? Thx!

If you stick some TXT record to DNS replies, then what? I guess that you mean it as some redirection mechanism, but unfortunately no such thing exists, it will simply be ignored by client.
Returning own IP address also does not help with anything. No matter where the connection goes to, once client tries to connect to https://somesite.tld, it expects to get valid certificate for somesite.tld and nothing else.

OK, it seems you are right. SPF is the only mechanism that is really useful in TXT records while everything else is for humans primarily.

Not a Solution, But a Work Around

We Walled Garden'd all Google.

Due to the fact that Google is a very popular Homepage, and the fact that although FF and IE will throw up and error - which is ok, due to the nature of connection, however Chrome would not allow continue (assumedly, due to the fact that it would believe google's Cert to always be valid and working), We decided that Bypassing www.google.(Whatever) was a suitable solution to an otherwise sticky problem.

Those who do then get to google search free, Image as well, however on click of a website, the get the redirect - and as a large chunk of the web is http - no cert errors (unless dates are having a spaz)

Youtube is not included in the free, gmail is also not free (tested), only thins that start with www.google.

Have used in the garden...
www.google.com
www.google.co.??
www.google.com.??
www.google.??

From what I gather, google in chrome is the only site to not allow a continue option - other https is "Errored" and allows to "Continue"

It's a little free data - that has saved us roughly 50-60 phone calls this last couple of months

is there any way to just redirect all HTTPS 443 requests to secure hostspot means when one person enter http://yahoo.com redirect to http://172.20.32.1/login and when enter https://yahoo.com redirect to https://172.20.32.1


now when enableing https from (Login by ) in hostspot profile , all traffics redirected to https://ip

No, you can't. You can't impersonate an HTTPS site without either causing a certificate error or getting your own CA certificate onto the client. That's just how HTTPS works.

To explain this problem with an analogy:
Suppose you go to a police station, and ask to speak with officer "Lindsey Smith" because you have been told you can trust her. Then a large, burly-looking male officer comes to you, shows "his" police officer ID and it says "Officer James McBurley" and has his photo, and a valid-looking police department seal. He says "Hi, I'm officer McBurley. You have to talk to me first."

Even if the I.D. is valid and it is really officer McBurley, you didn't ask for officer McBurley. You asked for Lindsey Smith. You immediately know something is different than you expected. If you don't trust the police, then you're going to be nervous now, right?

Different scenarios:

If you try to spoof DNS replies (i.e. http://www.google.com = 192.168.1.1) then in the above analogy, Officer McBurley would show up with his own (valid) ID, but speak in an obviously-fake female voice "Hi, I'm officer Lindsey Smith."

If you make up your own certificate for google.com, it would be as if Officer McBurley hands you a post-it note with a stick-figure drawn where the photo should be, and writing in pencil: "Offissur Lynn Z. Smith (this iz reel poleese badj and not fake)"

Long story short - a hotspot re-direction is EXACTLY the type of thing that SSL is designed to protect users against.
If a browser gives a warning, then it's SSL working as designed.

If you can take someone's request for google and present a different web site to them without anything suspicious happening, then you are doing a man-in-the-middle attack. You could do this for their bank's web page and steal their bank login credentials, etc.

Adding google.* to the walled garden is the best solution to the SSL warning problem that I've seen so far.

No, you can't. You can't impersonate an HTTPS site without either causing a certificate error or getting your own CA certificate onto the client. That's just how HTTPS works.

People don't understand it, i've tried to explain it multiple times in this forum.

The problem not is the people,,, Te problem is MIKROTIK Team,, dont answer never nothing !!!!!

This is not support forum.

The problem not is the people,,, Te problem is MIKROTIK Team,, dont answer never nothing !!!!!

And I think you should convinced by people's guidance ....

I finally tried my own suggestion about issuing a certificate to an IP address, and trusting that certificate, as opposed to a DNS bound certificate... And I'm sad to report that is not a solution.

Even if you are at the actual hotspot IP (not being nat-ed from Google), even if the DNS name corresponds to that same IP... The browser still complains. The only way the certificate works is if it is explicitly issued to that domain or subdomain. What's worse is that setting a wildcard to an entire TLD (e.g. "*.com" or even "*.*") doesn't work... I'm going to guess by design.

There is however good news... sort of...

At least in Windows 8.1, the captive portal always appears by default upon connecting to the network (regardless of the home page set), and the HTTPS version at that (win!). The only way to get the error is to explicitly type another HTTPS site before logging in, or after logging out.

And to solve THAT annoying bit (and perhaps with earlier Windows versions; Assuming they don't do that; I haven't checked)...

Using OpenSSL, it's possible to create certificates that have MULTIPLE alternative names, and thus you can add "google.com", "*.google.com", "facebook.com", "*.facebook.com", and other common HTTPS pages that users specify as their home page, all in addition to the real site name of course. RouterOS however does not support adding multiple alternative names though, and using this feature with OpenSSL directly is a PITA.


There's also an easier alternative... block all HTTPS connections before login, using the following two rules: This is not exactly the best alternative... Users will see an error equivalent to not having internet access, as opposed to being redirected... But that's still more "accurate", in that they indeed don't really have internet yet. If they explicitly type in a site (without a scheme that is), that will result in an HTTP connection, which will in turn be redirected normally, and then (potentially) to the HTTPS login.

Didn't you miss a tiny little bit? You can create certificate containing all *.google.com, *.facebook.com", etc.. But no trusted CA will ever sign it for you. And if you sign in yourself, no user browser will trust it, unless you install your CA into it first.

Didn't you miss a tiny little bit? You can create certificate containing all *.google.com, *.facebook.com", etc.. But no trusted CA will ever sign it for you. And if you sign in yourself, no user browser will trust it, unless you install your CA into it first.

Sounds like an acceptable sacrifice to me.

If access to devices is problematic, you could always instruct your first time users to install the certificate out of the login page itself, perhaps printing the fingerprint on their vouchers or what have you, for the more security cautious.

"Not everyone is so security cautious" I hear you say, and you're right... Most users that aren't would have no problem bringing in their PC to your office when it's just a "one time" configuration, and if you're installing any cables, you'd end up in their home anyway, with access to their device, at which point you could install the CA certificate yourself.


At the end of the day, there's always also the alternative of blocking all other HTTPS, as above.

I give you points for blocking https for unauthenticated users, no connection is better than certificate error. Well, maybe not much better, but at least proper.

But I was under impression that the problem is random Joe Visitor who somehow accesses hotspot and then gets confused, when he receives neither his https homepage, nor hotspot login page. And the goal is to just make it work, so he automatically gets the latter.
If you have to interact with him, you might skip whole juggling with untrusted certificate and simply tell him, that in order to access internet, he must first log in by going to https://hotspot.your-actual-domain-with ... ficate.com (or skip https and save on certificate, if you don't mind credentials going in plaintext over your network).

But I was under impression that the problem is random Joe Visitor who somehow accesses hotspot and then gets confused, when he receives neither his https homepage, nor hotspot login page.

That's not a problem, at least with Windows 8.1, since the HTTPS login page always opens as soon as the user connects.

Again, I don't know about earlier versions.

If you have to interact with him, you might skip whole juggling with untrusted certificate and simply tell him, that in order to access internet, he must first log in by going to https://hotspot.your-actual-domain-with ... icate.com/

My point exactly. At that very point, you can also give install instructions for the CA (or actually do the installation), if you don't have an "official" certificate.

(or skip https and save on certificate, if you don't mind credentials going in plaintext over your network).

There's CHAP even for HTTP, so plaintext is not really the problem...

Still though, a self-signed HTTPS certificate you have to install is better than no certificate at all, because that way, you can guarantee to users they're giving their credentials to the right server. Otherwise, a random rogue DHCP server could come, and intercept everyone's passwords.

Sure, a lot of users won't notice, unless you explicitly tell them to look for the "padlock" icon, but once they learn, they'll be better off.

That's not a problem, at least with Windows 8.1, since the HTTPS login page always opens as soon as the user connects.

And that's with your certificate installed as trusted in client browser or without?

If it's with the certificate, then it won't happen to random visitor (at first access at least), because they won't have it and will get ssl error instead.

It it's without it, then it gets interesting, because the only way how that could happen would be some kind of hotspot detection mechanism in browser. And that's exactly what got me interested in this thread, because someone wrote that it worked for them in IE on Win8.1. But when I tried it here, nothing, always ssl error no matter which browser or OS I tried.

That's not a problem, at least with Windows 8.1, since the HTTPS login page always opens as soon as the user connects.

And that's with your certificate installed as trusted in client browser or without?

If HTTPS is enabled on the hotspot, it goes to it, and if not, to HTTP, regardless of whether the certificate is trusted or not.
(But never to the user's homepage, regardless of whether that homepage is HTTP or HTTPS; That's the important bit)

If the HTTPS certificate of the hotspot itself is not trusted (i.e. is a self signed, non installed certificate), a warning would still be (rightfully) displayed.

If it's with the certificate, then it won't happen to random visitor (at first access at least), because they won't have it and will get ssl error instead.

If your certificate is self signed, yes, as expected by design.

If it is issued by a trusted authority, they won't get an error.

So yeah, if you care too deeply about random unregistered users passing by the login page, and want to make them feel safe, rather than alerted and/or confused, you'll want to get your certificate from a trusted authority, and block other HTTPS requests, to minimize "exposure" to certificate errors.

I personally wouldn't be too worried even with a self signed certificate. Most people would, despite the strongly worded warning messages in browsers, click through such warnings, at least out of curiosity (coupled with the fact that they won't have internet access, so it's not like they feel they have anything to "loose"). As long as the login page contains your phone and a link to the CA certificate, people can always call you (and be like "I just stumbled on your web site, and would like to get internet access, but... uhm... It's giving me some creepy warnings... What? That's NORMAL?!"), and be told the signature the certificate should have, so that they can be sure they're importing the right CA certificate (rather than a rogue CA certificate to a rogue hotspot server).

If someone would ask me to install a CA just to get rit of a warning i would not use that Hotspot at all. It shows me that the operator of the hotspot has no sense for security. From a security point of view installing random CAs is very dangerous.

Think of a person who is travailing a lot, (s)he would end up with dozens of hotspot CAs added to the browser/system. All these CAs can be abused for man in the middle attacks. We have already enough problems as even the "real" CAs to get compromised sometimes. How can you expect that the manual added "hotspot" CAs are safe?

As Sob already mentioned the right way to do it is to tell your customers to browse to https://hotspot.you-company.com rather than telling them to install your creepy CA.

If someone would ask me to install a CA just to get rit of a warning i would not use that Hotspot at all. It shows me that the operator of the hotspot has no sense for security. From a security point of view installing random CAs is very dangerous.

A "random" one, sure. But one that you know belongs to the party you're communicating with, and have verified by other means (e.g. phone or "physical" confirmation by the very person registering you) is not any less secure.

Inconvenient, yes, but not less secure... Assuming the operator you call is knowledgeable enough to tell you the fingerprint, and tell you to look for it, as opposed to them saying "Just click Install, Next, Next, Next, OK"... And yes, I realize few hotspot operators would go to that length, but that's not a technological problem - it's a human problem.

Think of a person who is travailing a lot, (s)he would end up with dozens of hotspot CAs added to the browser/system.

And would have dozens of different hotspot accounts by dozen of different providers? Sounds like installing a random CA is the least of such a person's problems, security wise...

All these CAs can be abused for man in the middle attacks. We have already enough problems as even the "real" CAs to get compromised sometimes. How can you expect that the manual added "hotspot" CAs are safe?

By virtue of being used by fewer people, fewer attackers would target the PCs where you keep your CA's private key. => The fewer people you have, the more secure a custom CA is compared to preinstalled ones.

Now, if you're already a very big ISP with a very big subscriber base that's like a monopoly in an entire state area... It's about time you get yourself a certificate from a trusted authority, and in fact, at that point, you may as well make it an EV one. For small ISPs, price is a big factor, but big ones have no excuse.

As Sob already mentioned the right way to do it is to tell your customers to browse to https://hotspot.you-company.com rather than telling them to install your creepy CA.

I agree it's the better way.

But it's not "the only" right way. If the price of the certificate is a big limiting factor, installing CA is a secure way to eliminate the cost... At the expense of the process being less convenient.

And yes, as a customer, if there are multiple ISPs in an area, all using hotspot, I would prefer to register with the one that doesn't require a CA installation. If multiple ones have such certificates, I would prefer one with an EV certificate at that...

But that is only if I have access to all such ISPs from my area. If I don't, I wouldn't care - I would pick the one I have access to (regardless of requirements), or if I have access to multiple, all requiring a CA installation, I'd pick the one who's office is closest, all other things being equal.

A "random" one, sure. But one that you know belongs to the party you're communicating with, and have verified by other means (e.g. phone or "physical" confirmation by the very person registering you) is not any less secure.

Just because i communicating with you as the party who offers me internet access via a hostspot makes you not trustworthy enough to accept you as a CA. As you are operating the network between me and the internet you could easily do a man in the middle attack, therefore you're one of the last partys i should accept as a trusted CA.

Inconvenient, yes, but not less secure... Assuming the operator you call is knowledgeable enough to tell you the fingerprint, and tell you to look for it, as opposed to them saying "Just click Install, Next, Next, Next, OK"... And yes, I realize few hotspot operators would go to that length, but that's not a technological problem - it's a human problem.

You can tell me the fingerprint of your certificate for hotspot.your-campany.com and i could add that to my browser. No need to trust your CA certificate which can sign every other certificate.

But it's not "the only" right way. If the price of the certificate is a big limiting factor, installing CA is a secure way to eliminate the cost... At the expense of the process being less convenient.

For your hotspot login you don't need an EV certificate. You just need a just need a cert which proves you own hotspot.your-company.com such certificates you can get for less than $5 per year.

It's not the only way, i agree. If the users have to get in connect with you anyway you could just handout username/password and use 802.1x. 802.1x also has the benefit that the wireless traffic of you customers is encrypted.

You can tell me the fingerprint of your certificate for hotspot.your-campany.com and i could add that to my browser. No need to trust your CA certificate which can sign every other certificate.

AFAIK, if the hotspot certificate is signed by my CA, you need to add the CA too.

Unless I'm missing something, and you could just add that one certificate and its chain, without trusting every other thing its CA has signed.

If browsers allow for that, then yes, it's better to go for that. I'm not sure if they allow for that though...

EDIT: OK, I checked... IE11 for one doesn't let you do that (or I'm not seeing how). You need to add some certificate as a root CA. Even if the certificate is a single self signed certificate (one that is explicitly tied to your hotspot page, and isn't tied to a separate CA certificate), that certificate must still be able to act as a root CA, meaning that if you trust that certificate, you're also trusting any other certificates it might sign. I don't see a way to only trust specific certificates signed by the root CA.

For your hotspot login you don't need an EV certificate. You just need a just need a cert which proves you own hotspot.your-company.com such certificates you can get for less than $5 per year.

From where? The cheapest certificates I've seen are more around $11 a year... Which admittedly is not prohibitively expensive either, but still.

EDIT: Found one, if you pay for 3 years together... Which is reasonable. I'm even more impressed by the EV certificates price though... The cheapest one I've seen before are about 2.5 times as expensive. Their EVs are still prohibitively expensive for my relatively small network, but yeah, an EV is not a "must" anyway, just a "nice to have".

If the users have to get in connect with you anyway you could just handout username/password and use 802.1x. 802.1x also has the benefit that the wireless traffic of you customers is encrypted.

For WiFi, yes. I agree. Hotspot in general is not as good of a solution as WPA2-EAP.

It is however good for wired connections, hence my earlier comment about you having access to user's computers when you get cables on their premises the first time around (and installing the certificates then).

AFAIK, if the hotspot certificate is signed by my CA, you need to add the CA too.

Unless I'm missing something, and you could just add that one certificate and its chain, without trusting every other thing its CA has signed.

If browsers allow for that, then yes, it's better to go for that. I'm not sure if they allow for that though...

EDIT: OK, I checked... IE11 for one doesn't let you do that (or I'm not seeing how). You need to add some certificate as a root CA. Even if the certificate is a single self signed certificate (one that is explicitly tied to your hotspot page, and isn't tied to a separate CA certificate), that certificate must still be able to act as a root CA, meaning that if you trust that certificate, you're also trusting any other certificates it might sign. I don't see a way to only trust specific certificates signed by the root CA.

I have to admit i don't know how that is in IE. I'm not a Windows person at all. In Firefox i'm 100% sure it's possible. But i would be a bit shocked if you only can add self signed certs in a way you give full trust to it.

From where? The cheapest certificates I've seen are more around $11 a year... Which admittedly is not prohibitively expensive either, but still.

EDIT: Found one, if you pay for 3 years together... Which is reasonable. I'm even more impressed by the EV certificates price though... The cheapest one I've seen before are about 2.5 times as expensive.

Last time a checked, as i needed a cheap cert for a project, i found a few <$5/year offers. Ok as you mentioned they where all for at least 3 years. If you look for 1 year certs i think we talk about around $10/year. Still not that much money.

It is however good for wired connections, hence my earlier comment about you having access to user's computers when you get cables on their premises the first time around (and installing the certificates then).

Why not use PPPoE on wired connections or have vlans?

Why not use PPPoE on wired connections or have vlans?

How can users be certain they're not connecting to a rogue PPPoE server? Last I checked, PPPoE supports encryption, but no certificates.

I now looked a little closer, and it seems Windows at least supports PPPoE with EAP, meaning that there's a way for a client to demand a particular certificate, but not only is setup not as trivial (or so it seems; It's not occurring at a wizard, just an extra option in the properties, post creation), but there's a bigger problem: RouterOS doesn't seem to support that at all.

But if we're talking just "in principle"... Yes, I believe a combined approach of PPPoE-EAP, WPA2-EAP and HTTPS-Hotspot is the best combo. That last one being useful for devices that may not support the former two for one reason or another. Also, as a means to advertise in front of randomly connected wireless clients (over a separate, unencrypted virtual AP).

Now if only User Manager supported EAP, and RouterOS supported PPPoE-EAP...

I have to admit i don't know how that is in IE. I'm not a Windows person at all. In Firefox i'm 100% sure it's possible. But i would be a bit shocked if you only can add self signed certs in a way you give full trust to it.

Yes. I just checked it too, and it's there indeed. Chrome however uses the OS' certificate store, as does IE, and that option is missing from there.

(One more thing to add to the list of reasons Firefox is the best browser for power users...)

How can users be certain they're not connecting to a rogue PPPoE server? Last I checked, PPPoE supports encryption, but no certificates.

Usually you can achieve it with port-isolation on your switch.

I now looked a little closer, and it seems Windows at least supports PPPoE with EAP, meaning that there's a way for a client to demand a particular certificate, but not only is setup not as trivial (or so it seems; It's not occurring at a wizard, just an extra option in the properties, post creation), but there's a bigger problem: RouterOS doesn't seem to support that at all.

But if we're talking just "in principle"... Yes, I believe a combined approach of PPPoE-EAP, WPA2-EAP and HTTPS-Hotspot is the best combo. That last one being useful for devices that may not support the former two for one reason or another. Also, as a means to advertise in front of randomly connected wireless clients (over a separate, unencrypted virtual AP).

Now if only User Manager supported EAP, and RouterOS supported PPPoE-EAP...

The problem is most home routers do not support PPPoE-EAP.

Usually you can achieve it with port-isolation on your switch.

It would be too expensive to have the entire network with managed switches (i.e. ones that would support this).

The problem is most home routers do not support PPPoE-EAP.

Yeah, that one's a (separate) big problem too.

So in practice, the perfect combo is more like PPPoE-PAP/CHAP (for home routers; sadly, they're an important factor too, and yet at that point, those users would essentially have to take the risk...), PPPoE-EAP (for Windows PCs and the few routers that might support this), WPA2-EAP (for WiFi enabled devices), HTTPS-Hotspot (for everyone else; notably WiFi guests).

It would be too expensive to have the entire network with managed switches (i.e. ones that would support this).

All my cheap TP-Link managed switches have such feature. As far as i can see the Mikrotik CRS support it as well. Even with a RB2011 using the switch rule table you can ensure that a client ports can only talk (pppoe) towards the router and not towards other clients. If you are afraid of users doing bad things like a fake pppoe-server on the network you need a managed switch anyway. Think about arp spoofing, dhcp spoofing, floods, etc.

But maybe even these devices are to expensive for someone who would not spend 5-10$ for a certificate?

So in practice, the perfect combo is more like PPPoE-PAP/CHAP (for home routers; sadly, they're an important factor too), PPPoE-EAP (for Windows PCs and the few routers that might support this), WPA2-EAP (for WiFi enabled devices), HTTPS-Hotspot (for everyone else; notably WiFi guests).

From my point of view hotspot is only nice if you offer a open WiFi where the user get the login page and can directly buy/signup without any interaction with the operator. But you miss encryption on the WiFi and in 2015 even a 12 year old script kiddy can sniff unencrypted wifi-traffic.

If you are afraid of users doing bad things like a fake pppoe-server on the network you need a managed switch anyway. Think about arp spoofing, dhcp spoofing, floods, etc.

I'm personally not "too" afraid in all honesty, hence my reluctance to needlessly spend a lot of money on that. But if it can be done with little to no monetary cost, I'm all for it, willing to invest the time and effort to set it up, and maintain it.

If anything, I'm afraid users will plug their cables the wrong way on their new home router, resulting in an unintentional rogue DHCP server, but that's the kind of problem PPPoE, even a plain one, can solve.

All my cheap TP-Link managed switches have such feature.

How cheap? Which models? I can't find an 8 or 16 port managed switch worth a 2 figure sum. Only unmanaged ones.

Replacing 1 is fine. But I have more like nearly two dozen. Replacing all of them is too much, especially if, like a lot of my existing routers, they are bricked at the first electrical surge and/or lightning storm.

But maybe even these devices are to expensive for someone who would not spend 5-10$ for a certificate?

For my network, I'm willing to pay that for a certificate. But I install other networks for others (mostly offices), where customers may not want to pay even that (i.e. they think of my work as a "one time thing" rather than "a recurring service"), and yet want the same features.

From my point of view hotspot is only nice if you offer a open WiFi where the user get the login page and can directly buy/signup without any interaction with the operator.

That's the ultimate goal I'd like to eventually reach with my network. It's a little further off though, as online payments aren't exactly popular where I live, and SMS payments, while more embraced, are an extra cog to be set up after everything else is ready.

But you miss encryption on the WiFi and in 2015 even a 12 year old script kiddy can sniff unencrypted wifi-traffic.

Amen.

How cheap? Which models? I can't find an 8 or 16 port managed switch worth a 2 figure sum. Only unmanaged ones.

I'm using the "jetstream" devices. For example TL-SG3210 8x Cupper + 2xSFP ~100€. It looks even the "smart switches" have port isolation. At least i found it in the manual of the TL-SG2008

Replacing 1 is fine. But I have more like nearly two dozen. Replacing all of them is too much, especially if, like a lot of my existing routers, they are bricked at the first electrical surge and/or lightning storm.

Have you so many lightning storms in you area? Maybe you need to review your grounding concept? I always ask my electrician how to do proper grounding at a place.

For my network, I'm willing to pay that for a certificate. But I install other networks for others (mostly offices), where customers may not want to pay even that (i.e. they think of my work as a "one time thing" rather than "a recurring service"), and yet want the same features.

That's obviously a problem if the customer is not willing to pay. Who is maintaining their network afterwards if your work is a "one time thing" for them?

If i would offer hotspot wifi solutions i would offer es as a full service with a monthly fee. And then just tunnel everything from the APs to my datacenter.

I'm using the "jetstream" devices. For example TL-SG3210 8x Cupper + 2xSFP ~100€. It looks even the "smart switches" have port isolation. At least i found it in the manual of the TL-SG2008

Yeah, too much for all switches... Somewhat bearable if I had just 2 or 3 in the entire network, at key junctions.

Have you so many lightning storms in you area? Maybe you need to review your grounding concept? I always ask my electrician how to do proper grounding at a place.

At least twice a year, usually at summer time, where each time, at least 4 go down.

Due to... let's call it "territorial disputes"... sometimes it's just physically impractical to do grounding well.

During the rest of the year, sometimes, the local electricity provider will do maintenance unannounced, or will have outages in their old grid that cause large electrical surges that fry not just switches, but even tower PCs that are plugged in, or more often their LAN cards.

And unlike ISPs, I can't choose my electricity provider. They're a regional (well... a 1/3rd of the country to be precise) monopoly.

In fairness, last year, I haven't had a single such outage (I mean, there were some shutdowns, but no damaging surges), but I consider this more of a statistical anomaly than a sign of electrical grid stability.

That's obviously a problem if the customer is not willing to pay. Who is maintaining their network afterwards if your work is a "one time thing" for them?

I do, but only when they need me to, and they pay per visit (or per hardware piece, if needed), rather than per month. Requirements change often (like, as soon as a device is introduced for one reason or another), so this suits me, as much as it suits them (as they don't feel "shackled" to me, giving them a sense of "flexibility"; The fact this feeling is more of an illusion is something that so far, only one client found out the hard way ).

Our company does offer an annual subscription model, where each visit and configuration change is free for the entire year, and only hardware is paid for in addition, and only if necessary and with explicit approval by the client each time. Before the crash of 2008, we had a few customers who subscribed to that (including said 1 customer above), but after that, pretty much everyone decided this is not for them, and they want to cut ties... Only to then bring us back, "just this once!", a few times throughout the year, which for some of them resulted in more expenses (i.e. higher annual profit for us), soooo... We'll let them figure it out, reminding them we offer the annual subscription for when they're ready.

If i would offer hotspot wifi solutions i would offer es as a full service with a monthly fee. And then just tunnel everything from the APs to my datacenter.

Well, I haven't previously deployed hotspot solutions... I've done mostly DHCP and static setups, often with one or few APs involved in the mix... So this is certainly an interesting idea. Hadn't thought about it.

The only problem I see with it on first inspection is the electric grid... If my neighborhood network goes down, users in the neighborhood will understand, but one on the other side of the city, where it all looks fine on the surface, will be extremely pissed, and rightfully so.

AFAIK, if the hotspot certificate is signed by my CA, you need to add the CA too.

You can manually trust individual certificates if they're not signed by a CA you recognise. If you trust a CA, however, it can sign certs for *anything* which is what jaykay2342 was worrying about.

The cheapest certificates I've seen are more around $11 a year... Which admittedly is not prohibitively expensive either, but still.

StartCom do free SSL certs which I think are limited to one per domain. Also there's this Cisco/Mozilla CA project in the works [the name of which escapes me] that will issue free certs soon.

Their EVs are still prohibitively expensive for my relatively small network, but yeah, an EV is not a "must" anyway, just a "nice to have".

The trusted CA model is so broken that in my opinion, EV is just fiddling around the edges. About the only purpose I can see to it is to extract a bit more money from people who buy certs [and I can see why CAs would want to do this, when you can get a cert for either $0 or $10].

You can manually trust individual certificates if they're not signed by a CA you recognise. If you trust a CA, however, it can sign certs for *anything* which is what jaykay2342 was worrying about.

StartCom do free SSL certs which I think are limited to one per domain. Also there's this Cisco/Mozilla CA project in the works [the name of which escapes me] that will issue free certs soon.

StartCom free SSL certs are not for business use. The free certs CA you mean is called letsencrypt https://letsencrypt.org/

The trusted CA model is so broken that in my opinion, EV is just fiddling around the edges. About the only purpose I can see to it is to extract a bit more money from people who buy certs [and I can see why CAs would want to do this, when you can get a cert for either $0 or $10].

Full ack on that, maybe dnssec+dane can fix/replace the CA model. But i'm sure it will not happen in the near future.

You can manually trust individual certificates if they're not signed by a CA you recognise. If you trust a CA, however, it can sign certs for *anything* which is what jaykay2342 was worrying about.

As jaykay2342 later informed me, this is possible in Firefox, after which I found out how to do that.

But... How to do this for IE and Chrome (on Windows)? I certainly don't see such an option with them. Do you?

Not a Solution, But a Work Around

We Walled Garden'd all Google.

Due to the fact that Google is a very popular Homepage, and the fact that although FF and IE will throw up and error - which is ok, due to the nature of connection, however Chrome would not allow continue (assumedly, due to the fact that it would believe google's Cert to always be valid and working), We decided that Bypassing http://www.google.(Whatever) was a suitable solution to an otherwise sticky problem.

Those who do then get to google search free, Image as well, however on click of a website, the get the redirect - and as a large chunk of the web is http - no cert errors (unless dates are having a spaz)

Youtube is not included in the free, gmail is also not free (tested), only thins that start with http://www.google.

Have used in the garden...
http://www.google.com
http://www.google.co.??
http://www.google.com.??
http://www.google.??

From what I gather, google in chrome is the only site to not allow a continue option - other https is "Errored" and allows to "Continue"

It's a little free data - that has saved us roughly 50-60 phone calls this last couple of months

Again, I re-refer to my earlier post. As far as I can tell 80%+ of people have google as a home page. That is why my calls have dropped by over 80%. I now cannot remember the last time I had a call with this issue. This issue becomes more of an issue in chrome due to google not allowing chrome to continue to "psuedo google" if the cert is wrong, and with chrome being one of the big browsers, this came up a lot.

Yes, it allows "free" searching of videos, web and news. However all of these are hosted off google, so when linking, they are re-directed to login, due to the largest proportion of links being http only.

In saying that, I have found it to bug occasionally and not allow through. Particularly after a log out. Can replicate, but hard to track. In saying that, anyone who chooses to log out, can usually read the instructions they have been given . Anyone logged out from a timeout is now getting mac-cookied back in, so are logged in before the web kicks in.

You can manually trust individual certificates if they're not signed by a CA you recognise. If you trust a CA, however, it can sign certs for *anything* which is what jaykay2342 was worrying about.

As jaykay2342 later informed me, this is possible in Firefox, after which I found out how to do that.

But... How to do this for IE and Chrome (on Windows)? I certainly don't see such an option with them. Do you?

If you save the CA certificate as a file on your computer, you can then import it into windows' certificate store.
http://www.cs.virginia.edu/~gsw2c/GridT ... icates.htm

As Troffasky said, trusting certificates can be quite serious. Trusting your OWN certificates is fine so long as you trust yourself not to lose the private key for your private CA. Trusting someone else's CA - well, I would not ever trust a hotspot's CA - They could easily MITM attack at will after that with no warnings. At the very most, I would create a local account on the computer, trust the CA for only that local user, I wouldn't do anything sensitive while using it, and I would remove the CA and account later.

And no - I don't live in a bomb shelter.

If you save the CA certificate as a file on your computer, you can then import it into windows' certificate store.
http://www.cs.virginia.edu/~gsw2c/GridT ... icates.htm

I know about that, but that trusts the certificate for all sites. I was asking if there's the ability to trust a certificate per domain.

If you save the CA certificate as a file on your computer, you can then import it into windows' certificate store.
http://www.cs.virginia.edu/~gsw2c/GridT ... icates.htm

I know about that, but that trusts the certificate for all sites. I was asking if there's the ability to trust a certificate per domain.

There are Name Constraints in x.509. https://tools.ietf.org/html/rfc5280#section-4.2.1.10 but most SSL implementations do not really check it, therefore i would not trust on it.

We have to admit that the ssl/tls trust model is quite broken.

I know about that, but that trusts the certificate for all sites. I was asking if there's the ability to trust a certificate per domain.

I'm sure you can trust an individual certificate. I saw some of my local corporate-only certificates in there as well when I followed along on my own workstation here.

There are Name Constraints in x.509. https://tools.ietf.org/html/rfc5280#section-4.2.1.10 but most SSL implementations do not really check it, therefore i would not trust on it.

limited-scope CA certs would be so much better than wildcard certs. Too bad this isn't done more.

my solution to this long time problem as high percentage of browsers home pages are set to google.com

add this expression to your walled garden in the host field

:^www\.google\.com$ with port 443

now when they are directed to https://google.com the google page will load instead of an error, Better in my opinion than an error. 99 times out of a 100 the user will click on a http link and get the login page.

Anyway to change this so it apply's to any https domain that ends with google.com?

If you select authentication method MAC and MAC as username and password will this prevent them from being forced through the login page until the HTPP cookie lifetime expires?

Seems like if they are idle for a while even if there cookie has not expired it forces them through the login page to verify the cookie and it fails since its https. I wonder if I just add MAC to this it will not need to do that?

Seems like if they are idle for a while even if there cookie has not expired it forces them through the login page to verify the cookie and it fails since its https. I wonder if I just add MAC to this it will not need to do that?

To solve this, just enable the : login by "MAC Cookie" option (in the server profiles-login options). With this option they will be automatically logged in as long as the cookie is active(it will not force them to login page each time the sesion runs out).
This option has saved me a lot of troubles. Without this option it was almost impossible to use the hotspot in a hotel enviroment. Most of the pages are now https, so the guest didnt realize why they suddenly lost connection (as the redirect page would not appear on https and the session had timed out), also many iphone and other devices had problem with getting to the login page at all.

I am a bit in the dark here.

To start the SSL connection, doesn't the browser need first to connect to the server? By sending a request for connection, isn't it visible to the router on port 443 and as result redirected to hotspot login page? What am I missing here?

To start the SSL connection, doesn't the browser need first to connect to the server? By sending a request for connection, isn't it visible to the router on port 443 and as result redirected to hotspot login page? What am I missing here?

When the client wants to connect to https://google.com, the certificate offered must have a common name or subject alt name that includes google.com. If not, a certificate error will be displayed to the user. You can't get a certificate for google.com, so you can't intercept the request and redirect it without the user seeing a certificate error.

To start the SSL connection, doesn't the browser need first to connect to the server? By sending a request for connection, isn't it visible to the router on port 443 and as result redirected to hotspot login page? What am I missing here?

When the client wants to connect to https://google.com, the certificate offered must have a common name or subject alt name that includes google.com. If not, a certificate error will be displayed to the user. You can't get a certificate for google.com, so you can't intercept the request and redirect it without the user seeing a certificate error.

So what is actually happening, is that router does see the initial request from client and does redirect it, but client is not able to get the certificate and thus the browser displays an error, right?
I have not looked at it thoroughly, but this seem to happen only with google as homepage, and not other https pages. If so, what is google doing differently?

Hi Guys,

Finally after long forum reading and googling, I am able to work with SSL and HTTPS sites. I will post all the details after few other test and post a video also if its a 100% success. Finger crossed.

https://youtu.be/gth9SG_O8j0

Hi Guys,

Finally after long forum reading and googling, I am able to work with SSL and HTTPS sites. I will post all the details after few other test and post a video also if its a 100% success. Finger crossed.

https://youtu.be/gth9SG_O8j0

That video didn't show that much how were you doing it. Can you post some details on it? What was the SSL certificate you were using?

Unless you control all the devices connecting to your hotspot, there is no possible way to redirect https traffic to your login page! If such a way existed, it would mean anyone else on the network would be able to intercept and modify https traffic, breaking the security promise that https gives. The only way to make this possible is if you own all the client devices and can install your own root certificate. This way you can force clients to trust your custom root certificate, and using that root, issue your own certificates for google.com, etc. These certificates would only ever work on devices where you installed the root certificate.

This is less and less of an issue these days, as most devices connecting to a hotspot are smart enough to automatically issue a regular http request and if it's redirected, present the user with the login page.

This is less and less of an issue these days, as most devices connecting to a hotspot are smart enough to automatically issue a regular http request and if it's redirected, present the user with the login page.

Not at the moment though, there are still a lot of devices which don't do that, which gives a lot of headache since customers do not care about technical issue, they just want solution. The situation is a bit sad

I was able to get the result in my testing environment. But I want to do a field test and then only put this solution in forum. Please be patient.

Unless you control all the devices connecting to your hotspot, there is no possible way to redirect https traffic to your login page! If such a way existed, it would mean anyone else on the network would be able to intercept and modify https traffic, breaking the security promise that https gives. The only way to make this possible is if you own all the client devices and can install your own root certificate. This way you can force clients to trust your custom root certificate, and using that root, issue your own certificates for google.com, etc. These certificates would only ever work on devices where you installed the root certificate.

This is less and less of an issue these days, as most devices connecting to a hotspot are smart enough to automatically issue a regular http request and if it's redirected, present the user with the login page.

I guaranty you that I am using CA authorized certificate which I bought from Comodo. Not using self-signed certificate.

Hi Guys,

Finally after long forum reading and googling, I am able to work with SSL and HTTPS sites. I will post all the details after few other test and post a video also if its a 100% success. Finger crossed.

https://youtu.be/gth9SG_O8j0

That video didn't show that much how were you doing it. Can you post some details on it? What was the SSL certificate you were using?

Sorry for the video. Actually I was so happy when it worked for me. And I just capture the video as it is. Will post a video once the field test is done.

Hi Guys,

Finally after long forum reading and googling, I am able to work with SSL and HTTPS sites. I will post all the details after few other test and post a video also if its a 100% success. Finger crossed.

https://youtu.be/gth9SG_O8j0

That video didn't show that much how were you doing it. Can you post some details on it? What was the SSL certificate you were using?

Sorry for the video. Actually I was so happy when it worked for me. And I just capture the video as it is. Will post a video once the field test is done.

Your video shows you ignoring the certificate warning (which is caused by 3rd party antivirus TLS interception).

So what is actually happening, is that router does see the initial request from client and does redirect it, but client is not able to get the certificate and thus the browser displays an error, right?

The client always gets a certificate but because the certificate offered doesn't have a common name or subject alt name that includes the requested hostname, an error is detected [because it knows it's not talking to who it thinks it should be].

I have not looked at it thoroughly, but this seem to happen only with google as homepage, and not other https pages. If so, what is google doing differently?

You need to look more thoroughly. No matter how thoroughly you look, you will find that you cannot intercept HTTPS without causing an error

hello there
I've tried to understand the cause of the probleme and i need a help
1- I have a mikrotik hotspot server with the ip address 10.0.0.5 (it's a private address).
2- My hotspot server redirect to an external login page (in the cloud) for users authentications.
3- I'm using socile media API for user authentication so i need SSL certificate for the hotspot .
Could you please help me to get SSL trusted certificate and wich domaine it wil contain .
Best-regards

Use let's ecnrypt willcard.

For example you own the domain myhotspot.com

Create a certificate for *.myhotspot.com using DNS Only mode.
Then you have to add a DNS Record to your hosting provider

Get the .cer .key files and import them

How to get staretd
https://www.ollegustafsson.com/en/letsencrypt-routeros/

Automatic renewal
https://github.com/gitpel/letsencrypt-routeros