最近、私の大学がWiFiネットワークで認証するための証明書を更新しました。何を受け入れるのか、それが何で何のために使われるのかさえわからなかったので、受け入れるのをためらっていました。
私の検索が明らかにする限り、それらについての一般的な質問は何もなかったので、誰かがいくつかの一般的な光を放ち、より多くを学ぶ正しい方向に私を向けることができることを望んでいました。
ますます、WiFiアクセスポイント(または訪問者とゲストの「サインイン」ページとして機能するポータル)がSSL証明書をサポートするようになっています。これらの証明書は、2つの目的を果たすように設計されています。
1)検証:訪問者に、接続先のデバイスが本当に接続していると思われる組織に属していることを、暗号化された方法で保証します。
2)暗号化:クライアントデバイスとサーバー/ホストエンド(この場合は、wifiホスティングデバイス)間の接続を暗号化します。
ほぼすべてのWebブラウザーには数十個のプレインストールが付属しています。Verisign、Comodo、Digicertなどの公的(または外部)認証局(CA)に属する数百ものID証明書です。これらのベンダーのいずれかによって証明書が署名されているサイトに接続すると、一般の人々の99%がブラウザに正当なものとして認識させます。
ただし、ほとんどの大規模な民間組織は、ある時点で独自のPKIを導入して、より優れた制御とコスト削減を実現したいと考えています。したがって、彼らは独自の認証局を実装します。次に、Microsoftネットワークを構成して、その内部CAの証明書をすべての組織のクライアントデバイスのトラストストアにプッシュします。そのため、Digicert、Comodo、Verisignに加えて、そのラップトップまたはモバイルデバイスは、その内部CAによって署名された証明書を信頼するようになります。
その最後のステップは重要です。これを行わないと、訪問者には、証明書が信頼されていないことを警告する醜いエラーメッセージなどが表示されます。証明書は、訪問者に暗号化を提供しますが、検証のメリットはありません。大学が独自の内部PKIを展開し、証明書を従業員のデバイスにプッシュし、学生に頭を悩ませるようにさせた可能性があります。接続しようとすると、なぜWebブラウザーまたはクライアントソフトウェアがエラーをスローするのでしょうか。そして、特に大学があなたのマシンを制御していないので、それは理にかなっています。
大学が内部PKIを使用していて、デバイスのCAの証明書が証明書信頼ストアにインストールされていない可能性があります。これを解決するには、提示されている証明書が本物であることを確認します(サービスデスクに連絡して、証明書のフィンガープリントを確認できます(探し方がわかっている場合は、そうでない場合は、証明書の詳細を確認します)。確認したら、ルート証明書または中間証明書をダウンロードして、信頼されたルートストアにインストールします。ブラウザを再起動する必要があるかもしれません。ただし、それが完了すると、これらのエラーは表示されなくなります。
これが参考になる良い記事です: https://technet.Microsoft.com/en-us/library/cc754841.aspx