内部ネットワークで適切なHTTPSを実行するにはどうすればよいですか？
この質問は何度か尋ねられました。いくつかリンクします。
- https://superuser.com/questions/791015/https-over-private-network
- https://stackoverflow.com/questions/616055/https-certificate-for-internal-use
- https://stackoverflow.com/questions/2676238/ssl-signed-certificates-for-internal-use
- 内部使用のために署名有効な証明書を購入できますか？
ただし、これらは古い質問であり、少なくともいくつかの点で、提供された回答は古くなっています。研究のどの部分が古くなっていて、何がまだ良いのかを見つけられることを期待して、私の研究を提供しています。私は現代的な答えを探しています。
質問は簡単ですが、ここに状況があります。機密情報にアクセスするWebサービスを持っています（私たちの会社と顧客にとっては悪いかもしれませんが、おそらく生命を脅かすものではないでしょう）。これらのシステムに簡単にアクセスできるようにしたいのですが、セキュリティは明らかに重要です。 （これらのサービスの一部は、Webサービスとして非ブラウザークライアントを介してアクセスされます。一部のサービスは、最新のブラウザーから人間が使用する単なるWebページです。）
そのため、私たちは最も重要なサービスに内部でのみアクセスできるようにしています。このようにして、攻撃者は、a）それらを誤って見つける可能性が低く、b）克服すべき障害が1つあります。
ただし、「セキュリティの詳細」では、トラフィックも内部で暗号化することをお勧めします。これにより、ネットワーク内の誰かがネットワークからパスワードを盗聴することがさらに困難になります。
「宿題をやる」という精神で、いくつかのオプションを集めました。ルールの一部が変更されたことがわかっているので、これらのうちどれが今でも実行可能であるかは完全にはわかりません。
自己署名証明書
これは、ほとんどの場合、この質問に対する「頼りになる」回答のようです。これにより、偶発的なスニッフィングの問題への抵抗が得られますが、「大きな厄介な警告ページは問題ありません。クリックするだけです」とすべての従業員に伝える必要があります。私はそのページを無視しないように彼らを訓練するために一生懸命努力してきました、そして彼らのほとんどは「サイトが自己署名証明書を使用していることを知っていて期待しているとき、ページは時々問題ない」のニュアンスを理解しません（彼らはコンマで聞くのをやめる傾向があります:)）。
自己署名証明書ですが、各システムにインストールされ、信頼されています
これは厄介なページを修正すると思いますが、アクセスしたすべてのコンピューターで信頼できるように設定する必要があります。それは可能ですが、望ましくありません。
また、これが内部アドレスでさえ可能であると100％確信しているわけではありません。最近のブラウザーは、非パブリックIPアドレスに解決される、または完全に修飾されていないマシンを認証すると主張する証明書を拒否することになっているという私の理解。
さらに、モバイルデバイスにシステムルート証明書をインストールするプロセスは...基本的に不可能です。根ざしたAndroid電話、およびiOSデバイスでは比較的難解なプロセスが必要です。
自分のCAをセットアップする
インストールされた証明書と信頼できる証明書で基本的に同じ問題が発生しますが、インストールする必要があるのはルート証明書だけであり、立ち上がっているすべてのシステムに1つの証明書ではありません。それでも基本的には、会議で使用したいタブレットマネージャーを含むすべてのモバイルデバイスをシャットダウンします。
IPは内部にあり、DNSは完全に修飾されないので、これが機能することを私はさらに確信していません。
パブリック証明書を使用しますが、内部アドレス用です。
完全修飾アドレス（「secret.private.example.com」など）を構成して、内部アドレス（「192.168.0.13」など）に解決できます。次に、それらのパブリックDNS名の証明書を使用できます（「* .private.example.com」のワイルドカード証明書でさえも可能）。
これはうまくいくかもしれないし、うまくいかないかもしれません。ブラウザは、ローカルアドレスへの解決を試みるための証明書を拒否する場合があります。
それが機能する場合、それは良い考えではないかもしれません。内部システムから別のネットワークに（おそらく非常に迅速に、VPN接続解除を介して）持ち込まれたラップトップは、他のネットワークのローカルIPアドレスにある秘密のものにアクセスしようとする可能性があります。 HSTSが有効である限り、これは重要ではありません。秘密鍵がないと、クライアントを説得することができないためです。偽造サイトを受け入れ、HTTPへのダウングレードを強制することはできません。しかし、それは望ましくないようで、最近有効になった（たぶん？）「パブリックDNSにプライベートアドレスがない」というルールに違反していますか？
だから、これらすべてを言う...正しい答えは何ですか？暗号化とアプリケーション固有の認証要件によって物事が安全に保たれると信じて、プライベートサービスを「あきらめて」公開することができます。確かに、感度の低いものについては、これは素晴らしいコースです。ただし、アプリケーション固有の認証にバグがあるか、資格情報が他の方法で侵害される可能性があるため（人々は常に最も弱いリンクです）、可能であれば追加の障害が存在することを望みます。
証明書の検証は、ピアが期待どおりのものであることを確認するために行われます。ブラウザでのサーバー証明書の検証は、主に、URLのホスト名が証明書の名前と一致し、ローカルで信頼されたCA証明書（つまり、ブラウザに保存されているルート証明書）への信頼チェーンを構築できることを確認することで行われます。またはOS）。さらに、有効期限と失効のチェックがあります。
このプロセスが意図したとおりに機能することを確認するには、証明書の発行者が証明書のホスト名を実際に所有していることを検証することが不可欠です。これは、この名前を所有していることを証明できる場合にのみ、パブリックCAによって発行された証明書を取得できることを意味します。これには通常、この名前のホストがパブリックに表示されることが含まれます-少なくとも自動検証が行われる安価な証明書の場合。もちろん、実際にホスト名（つまり、*.example.comでアクセスできる単一のサーバー）でホスト名を使用できるようにすることでこの問題を回避し、発行された証明書を内部システムに使用できます。
（ミス）この方法で内部システムにパブリックCAを使用することは、見苦しい方法ですが、ほとんどの場合は機能するはずです。失効チェックはCAからの情報、つまりローカルネットワークの外部からの情報を使用して行われるため、依然としてインターネット接続が必要です。これは、OCSPステープリングを使用することで何らかの形で制限される可能性がありますが、すべてのクライアントとサーバーがこれをサポートするわけではありません。クライアントが外部CAに失効情報を要求することを許可しない場合、クライアントが失効情報を取得しようとして失敗するため、接続のセットアップが遅くなることがあります。
したがって、パブリックCAを使用することは可能ですが、欠点があり、CAシステムを誤った方法で使用するように感じられるため、お勧めしません。多数の証明書を処理する場合の唯一の代替手段は、独自のローカルCAを使用することです。しかし、ご存じのように、これはすべてのローカルシステムにルート証明書をインストールして信頼することを意味します（これは一部のシステムでは自動化できます）。これはまた、ローカル証明書のみを発行することに限定されず、理論的にはgoogle.comなどのパブリックドメインの証明書も発行できるため、悪用からこのローカルCAを保護する必要があることを意味します。また、すべてのローカルシステムがこのCAを信頼しているため、この証明書も信頼します。また、証明書のピン留めは、発行者のCAが明示的に信頼できるものとして追加された場合、ほとんどのシステムでチェックされません。これにより、CAを合法的または違法なSSL傍受（つまり、中間者攻撃）に悪用しやすくなります。
つまり、本当に良い選択肢がないということです。すべての欠点を持つ内部ホストのパブリックCAを誤用するか、すべての欠点を持つ独自のCAを作成します。この問題に役立つパブリックCAもあると思いますが、これはおそらくあなたが望むよりも費用がかかるでしょう。
「パブリック証明書を使用しますが、内部アドレス用です。」
このオプションは非常にうまく機能します。それが私たちの仕事です。
実際にHTTP検証を実行できます。証明書にはIPアドレスが含まれず、DNS名のみが含まれます。したがって、DNSを外部サービスにポイントし、検証してから、内部IPにポイントすることができます。
しかし、更新を行う必要があるたびにエントリを変更する必要がないため、CAがDNS検証をサポートしている場合、DNS検証はより適切に機能します。 SSL証明書が行うことはすべて、名前を制御していることを検証するだけなので、サブドメインエントリを作成できれば、明らかに名前を制御できます。
Letsencryptの手順： https://serverfault.com/questions/750902/how-to-use-lets-encrypt-dns-challenge-validation
私は信じるパブリックIPとFQDNの要件は、ブラウザーではなくCAが担っているので、大丈夫です（少なくとも、誰かが情報については、午後にテストを設定して、どちらか一方の方法で確認できます）。
これにより、少なくとも公開証明書は除外されます。残りの3つのオプションのうち、最高のユーザーエクスペリエンスは独自のCAを作成することによってもたらされます。また、他のオプションにはない認証の利点をすべて提供するため、これは最も信頼できるオプションでもあります。
価値があるのは、ルート証明書をAndroid（ v4.xにインストールするできる）ことです。以降 ）とiOS（ と言うと、比較的難解なプロセス ）ですが、間違いなくそれは苦痛です。
他の唯一の現実的なオプションは、パブリックIPを取得してパブリックドメイン名でDNSを設定し、おそらくVPNなどを介してそれにアクセスすることを制限することです。
ユーザーが間違ったことをするように訓練しているだけなので、ユーザーが使用するたびに受け入れる自己署名証明書を使用することは、最後の手段となるはずです。
これまでに発見した最善の解決策は、Caddyなどのリバースプロキシを使用して証明書を処理し（問題と更新）、すべての内部ホスト名をCaddyサーバーにポイントするようにDNSサーバーを設定すると、すべてが自動的に機能します。内部へのアクセスのみを制限する場合は、証明書の更新が必要になるまでポート80を閉じることができます。
私自身もこれに取り組んでおり、一部の内部Webアプリケーションにhttpsを実装しています。
まず、内部DNSサーバーで、新しい前方参照ゾーンcorp.domain.comをセットアップし、その中にいくつかのA/Cnameレコードをセットアップしました。webapp1.corp.domain.comは、内部LAN IPをポイントしています。
これで、*。domain.comのワイルドカードSSL証明書を既に所有しているので、私の証明書要求で、webapp1.corp.domain.comの複製SSL証明書を作成しました
これをIISにインストールし、ブラウザ内ではSECUREと表示されます:)