キャプティブポータルでのSSL証明書エラー
状況：キャプティブポータル経由でインターネットにアクセスしようとしているホテルのゲスト。問題：すべてのホームページをHTTPSにリダイレクトするサイトがGoogle、Yahooなどに増え、ログオンページにリダイレクトしたときにゲストが証明書エラーを受け取るようになりました。 SSLの正しい目的はこれを正確に行うことですが、ファイアウォール経由のアクセスを有効にする前に、ゲストのログオンを確認プロセスで管理してIDを確認する別の方法があるかどうか疑問に思います。理解できないゲストをおびえさせます。基本的に、キャプティブポータル/認証プロセスには別のアーキテクチャが必要であり、誰がどのような考えを持っているのか疑問に思います。ありがとう。
「キャプティブポータル」の定義全体は、「ユーザーの知らないうちにユーザーをリダイレクトする」ことを中心にしています。これは、SSLが回避するために作成したものの1つです。
ブラウザが開こうとする最初のURLがHTTPSの場合、証明書エラーを作成せずにトラフィックをリダイレクトする方法はありません。
Chromiumプロジェクトには、キャプティブポータルを検出するための ロジックがどのように機能するかを説明する適切なページ があります。
- よく知られているホスト+ URIに接続（プレーンHTTP）しようとします
- 期待する
HTTP 204 No Content - 別の応答が受信された場合は、それがキャプティブポータルであると想定します。
よく知られているホストなどを解決しようとしたときにDNS障害を処理する方法に関して、提供されたリンクに他の詳細があります。これはほんの一例ですが、（私の個人的な経験では）最新のOS設計はこれと同様のプロセスを使用して検出しますユーザーがブラウザーを開く前に、場合によってはユーザーにプロンプトを表示します。 （検討：IMAPクライアントまたはその他の非HTTPサービスのみを使用したい人。）その場合、検出はSSL/TLS経由で行われませんだからあなたの懸念は避けられます。
RFC 6585セクション6 は、新しいHTTPステータスコード511 Network Authentication Requiredを提案します。これは、SSL/TLSのケースには役立ちませんが、まだ使用していない場合に検討できる別の標準です。
いずれの場合でも、ユーザーが証明書エラーを受け取ったのは、CertificateがSite hostname。
この場合、これは、URLを変更せずにユーザーをポータルにリダイレクトすることを意味します。ユーザーのアドレスバーには " http://www.google.com "が表示されますが、画面にはポータルが表示されます。これらは明らかに一致しませんし、証明書も一致しません。
それらをHTTP（HTTPSジャンプの前）でポータルaddress（またはサーバー名）にリダイレクトし、そこにログインしてからリダイレクトする必要があります。再び意図した目的地に、これは正しく一致します。
HTTP 3xxコード、特に303を使用して実行する方法については、 https://en.wikipedia.org/wiki/URL_redirection#HTTP_status_codes_3xx を参照してください。