Normis... you can fix the https://www.google.com error in hot spot ???????????????

please be more specific & in English please

Problem is when users type google.com, they are redirected to https://www.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.

I think there is topic talked about this matter in past. I think in the end they say you should walled garden google or something like this

But I don't know, I don't have such problem with my hotspot....

I know you think Mikrotik is the problem, and that they are ignoring you because they are evil and too busy spending your money at strip clubs and casinos to help you, the first person who has ever experienced the https: hotspot issue.

Or, you could calm down for a moment and listen:

This is not a bug in Mikrotik.

This is not something that Mikrotik can fix.

This is not the first (or even 1000th time) that someone has reported this "bug"

This is how SSL is DESIGNED to protect the end user from someone intercepting their connection.

All that you can do is allow ssl to google.com in your walled garden so that users do not get such errors.

My company has an enterprise web filtering solution, (which costs over $10k per unit) and even THAT system requires that we install our own private root trust certificate on the filter and use Active Directory to force our workstations to trust anything that this certificate signs. Now the server can intercept any SSL that it wants and the client will accept it, but you cannot install your own CA into all users' trust chains. Since you can't do that, SSL will recognize that you're breaking into the connection - because that's what it SUPPOSED to do - it is SUPPOSED to warn a user that they're not talking to the server they think they are.

Calm down, and resolve to work with the problem and stop throwing a temper tantrum like a little child.

EDIT:

If you really want to avoid the SSL problem, then you can implement MAC address logins to your hotspot. The hotspot will recognize and authorize all registered MAC addresses so they don't get the warning. Of course, new users will still get the SSL warning . . . most people just allow *.google.com in the walled garden so that the warning doesn't pop right up immediately.

@ZeroByte

Still I don't know why I don't have such problem....
and yes. I'm not looking for problem. Just looking for knowledge of it

Apparently, current versions of IE, windows 8, and Chrome all try to detect a captive portal. If they detect one, they open the login page without using ssl, so no security warning happens. If your users don't have https:// websites as their default page, then they won't get the problem either - the hotspot just redirects them.

The certificate warning happens when a client tries to open an ssl-protected website before doing anything else. The browser thinks it's going to "my secure website" - so when it gets a certificate from your hotspot server for "myhotspot.com - signed by verisign - 100% legitimate) it is correctly alarming the user: "Warning - you are talking to a web server that is not the one you asked for!"

Many people respond by asking: "But I'm redirecting them to myhotspot.com ssl login page, and my certificate is valid!"
"Why should the client's browser give warning?"

Redirect is a message that happens in the http protocol... certificates and ssl happen on port 443 BEFORE the http messages can begin. SSL starts by giving a certificate - before the client can ask for a website by name. So a browser sends TCP:443 packet to "google.com" and your Mikrotik answers in stead - SYN,ACK" - client acknowledges and starts the SSL request. The Mikrotik's certificate is for myhotspot.com - even if it is signed by Verisign, it is NOT the certificate for the web site that the client was asking for, so the browser will give a warning "certificate does not match website" - if the user clicks "do it anyway" - only THEN does the browser say "I want http 1.1, host=google.com, etc - " to which your Mikrotik finally gets to respond with the redirect header: "site moved to myhotspot.com"

Only a valid certificate signed by a trusted authority, matching the website you requested will work.
Jumping in the middle will break one of these - so there will be a warning, or else you could just as easily intercept connections to the users' banking websites without any warnings.....

So this is why it's good that browsers and operating systems are starting to check for a hotspot as soon as the device joins the network. If the device knows it's on a hotspot, it can open a non-ssl browser window and let the hotspot direct to the login page without any SSL warnings.

Apparently, current versions of IE, windows 8, and Chrome all try to detect a captive portal. If they detect one, they open the login page without using ssl, so no security warning happens. If your users don't have https:// websites as their default page, then they won't get the problem either - the hotspot just redirects them.

As I said in the other topic around this issue, if you have SSL on the hotspot, users will get the SSL protected login page.

Yes, Windows sends users to the HTTP variant, but RouterOS then redirects to the HTTPS variant, if you have one, so users are ultimately protected.

Apparently, current versions of IE, windows 8, and Chrome all try to detect a captive portal. If they detect one, they open the login page without using ssl, so no security warning happens. If your users don't have https:// websites as their default page, then they won't get the problem either - the hotspot just redirects them.

As I said in the other topic around this issue, if you have SSL on the hotspot, users will get the SSL protected login page.

Yes, Windows sends users to the HTTP variant, but RouterOS then redirects to the HTTPS variant, if you have one, so users are ultimately protected.

Of course, but this ssl connection is after the one which makes the alarms go off on the customers' screens, so I didn't focus on this part of the transaction. It was outside the scope of my explanation, so I kept that part shorter. I guess I could've been more clear.

(I figured I am already long-winded enough as it is - haha)