情况：酒店客人试图通过我们的强制门户进入互联网。 问题：Google，Yahoo以及现在越来越多的网站将所有主页redirect到HTTPS，因此，当我们将其redirect到我们的login页面时，客户会遇到证书错误。 欣赏SSL的目的是为了做到这一点，但不知道是否有另一种方式来pipe理访客login确认过程，以确认他们的身份，通过防火墙启用访问之前。 这吓坏了谁不明白的客人。 基本上需要一个不同的体系结构来进行强制门户/authentication过程，并想知道有什么想法。 谢谢。
“俘虏门户”的整个定义围绕着“不用他/她的知识而redirect用户”，这恰恰是SSL要避免的一个问题。
如果浏览器尝试打开的第一个URL是HTTPS，则无法重新定向通信，而不会创build证书错误。
Chromium项目有一个很好的页面来描述他们的逻辑如何检测被俘门户：
HTTP 204 No Content 在提供的链接中还有其他一些细节，例如在尝试parsing知名主机时如何处理DNS故障等。这仅仅是一个例子，但是（以我个人的经验），现代OSdevise正在使用类似于这个的过程来检测甚至在用户打开浏览器之前甚至提示用户。 （考虑：只想使用IMAP客户端或其他非HTTP服务的用户）。在这种情况下，检测不会通过SSL / TLS发生，因此您的疑虑将被避免。
RFC 6585第6部分提出了一个新的HTTP状态码511 Network Authentication Required ，它不能帮助你的SSL / TLS情况，但是如果你还没有使用它，你可能会考虑另一个标准。
在任何情况下，如果用户收到证书错误是因为证书不符合站点主机名 。
在你的情况下，这意味着你将用户redirect到你的门户网站而不改变URL。 用户在地址栏中看到“ http://www.google.com ”，但在屏幕上显示您的门户。 这些显然不匹配，证书也没有。
您需要将它们以HTTP（在HTTPS跳转之前）redirect到您的门户网站地址 （或服务器名称），让它们在那里login，然后再将它们redirect到预期的目的地，这将正确匹配。
请参阅https://en.wikipedia.org/wiki/URL_redirection#HTTP_status_codes_3xx了解如何使用HTTP 3xx代码执行此操作，特别是303。
临时解决scheme是引导用户只有在连接wifi信号后才能以“http”开始URL。
但不幸的是，用户不喜欢它。 他们说“你有多复杂的wifi服务”