SSL証明書をActive Directory環境のすべてのブラウザーに配布する

Question

私は単一の自己署名SSL証明書を生成しました（5000年で有効期限が切れます）。証明書の目的は、複数の企業イントラネットサイト上のさまざまなWebブラウザーによってアクセスされる、信頼された deno アプリケーションのhttpsトラフィックを単純に暗号化することです。

前の質問のコメントで、ドメインコントローラーのグループポリシーを使用して、自己署名されたパブリックSSLキーをActive Directory環境内のすべてのコンピューターに配布することが可能であると誰かが私に助言しました。

私の目標は、ユーザーがこの自己署名証明書を手動で受け入れる必要がないようにすることです。

このアプリケーションのセキュリティは最優先事項ではありません。最優先事項は、自己署名証明書の自動受け入れです。新しいユーザーがChromeまたはFirefoxを使用してこのアプリケーションに初めてアクセスする場合でも、アプリ内のページを表示するために証明書を手動で受け入れる必要はありません。

（httpsの代わりに）httpを使用していないのはなぜかと不思議に思っているのは、プロトコルがhttpsでない限り使用できないWeb標準の機能があるためです。通知API はその一例です。

私のユースケースの完全なチュートリアルはありますか？

私はここを右クリックしました：

これにより、グループポリシーエディターが表示され、実際に自己署名された公開キーをここにインポートすることに成功しました：

ただし、これは効果がありませんでした。たとえば、LAN上のいくつかのワークステーションにログインし、FirefoxとChromeの両方からログインしましたが、証明書を手動で許可するように求められました。

私の正確なユースケースと目標の詳細な説明はどこにありますか？ ChromeとFirefoxの両方が、配布しようとしている証明書の事前認証を自動受信するようにするにはどうすればよいですか？

これは、複数の企業イントラネットサイトで複数のインストールを行うために達成する必要があることです。各インストール場所で、この証明書を配布するようにActive Directoryを取得する必要があります。これにより、各ワークステーションのすべてのブラウザーが証明書を受け入れます。

Esa Jokinen · Answer

これに関する包括的なチュートリアルを書くことはQ/Aサイトには適さないかもしれませんが、ここにいくつかのアドバイスがあります。また、これは自分のイントラネット内の単一のクライアントのインストールを管理する観点からです。例えばSaaSインストールの場合、グローバルFQDNとPKIを使用することをお勧めします。

ソフトウェアベンダーとして、あなたはすべきではありません：

独自のPKIを実装してクライアント全体にプッシュします。これにより、任意のホスネームの証明書を発行できるため、インフラストラクチャ全体に神モードを提供できます。
他のクライアントに対して簡単に抽出して使用できるため、ハードコードされた秘密鍵を持つ複数のクライアントに同じ自己署名証明書を使用します。
これらの間違いを組み合わせると、すべてのクライアントに他のすべてのクライアントよりも神モードが与えられます。

個々の証明書を信頼する代わりに、独自のPKIを作成する

これは主にセキュリティ上の考慮事項ですが、複数のイントラネットサイトに複数のインストールがあることからもわかるように、維持も容易です。

セキュリティの観点から、すべてのアプリケーションが任意のホスト名の証明書に署名できるようにする必要はありません。したがって、個々の自己署名証明書がすべて信頼できる認証局である必要はありません。
メンテナンスの観点からは、ポリシーを更新して、新しいWebアプリケーションを追加する必要があるたびにポリシーが反映されるのを待つ必要はありません。
望ましいことですが、外部のCAから証明書を取得することができない（または望まない）場合があります。イントラネットサイトにはグローバルに有効なFQDNがない可能性があり、ドメインの検証が不可能になるか、インターネットへの接続が制限され、証明書の更新を維持することが難しくなります。

この場合、推奨される代替策は、クライアント用に独自の認証局を作成することです（PKIをソフトウェアベンダーとして複数のクライアントにプッシュしないでください）を使用して、すべてのアプリケーション証明書に署名します。この方法では、GPを使用して信頼できる認証局に単一の証明書を追加するだけでよく、それで署名されたすべてのアプリケーション証明書が信頼されます。

この目的のためだけに小さな認証局だけが必要な場合は、OpenSSLを使用できます。

ルートキー（rootCA.key）とルート証明書（rootCA.crt）を生成します。
```
openssl genrsa -aes256 -out rootCA.key 4096 openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 7300 -out rootCA.crt 
```
キーを安全に保管し、できればオフラインにし、グループポリシーを使用して証明書を配布します。

キーと証明書署名リクエスト（.csr）で始まるアプリケーションの証明書を作成します。

openssl genrsa -out app.example.com.key 2048 openssl req -new -sha256 \ -key app.example.com.key \ -subj "/C=US/ST=CA/O=My Application/CN=app.example.com" \ -out app.example.com.csr

CAで署名されたアプリケーション証明書を作成します。

openssl x509 -req -in app.example.com.csr \ -CA rootCA.crt -CAkey rootCA.key -CAcreateserial \ -days 730 -sha256 \ -out app.example.com.crt

アプリケーションでapp.example.com.keyおよびapp.example.com.crtを使用します。

より重いソリューションには Active Directory証明書サービス（AD CS）がありますが、これには実際にいくつかの計画が必要であり、スキルセットはまだ十分ではない可能性があります。

デフォルトのドメインポリシーを編集する代わりにGPOを使用する

補足として、デフォルトのドメインポリシーは編集せず、代わりに新しいグループポリシーオブジェクト（GPO）を作成します。変更の範囲を制限することがはるかに簡単になります。最初に、それらをテストコンピュータのグループに適用できるようにします。また、問題が発生した場合に、変更を元に戻すのが容易になります。

Firefoxには独自の証明書ストアがあります。Windowsの証明書を使用できます。

MozillaのCA証明書プログラムルート証明書の包含を管理します Network Security Services（NSS）、セキュリティ対応クライアントのクロスプラットフォーム開発をサポートするように設計された一連のオープンソースライブラリとサーバーアプリケーション。 NSSルート証明書ストアは、FirefoxブラウザーなどのMozilla製品で使用されており、他の会社でもさまざまな製品で使用されています。

つまり、Windows証明書ストアに追加された証明書は、デフォルトではFirefoxに適用されません。メンテナンスを簡単にするために、Windowsにインストールされている認証局をFirefoxで使用することをお勧めします。独自の証明書ストアを使用することは、Firefoxを使用している個人のプライバシーの保護には良い考えですが、Windows AD環境には適していません。幸いにも、それを無効にする方法があります。

FirefoxのインストールディレクトリがC:\Program Files\Mozilla Firefox\であるとすると、ANSIエンコードされた2つの構成ファイルを追加する必要があります。

C:\Program Files\Mozilla Firefox\defaults\pref\local-settings.js持っている
```
pref("general.config.obscure_value", 0); pref("general.config.filename", "ownsettings.cfg"); 
```
これは、実際の構成パラメーターを持つ次のファイルを単に参照します。
C:\Program Files\Mozilla Firefox\ownsettings.cfg持っている
```
// lockPref("security.enterprise_roots.enabled", true); 
```
実際の設定は、//の後の2行目から開始することが重要です。

これらのファイルは同じGPOを使用して配布できます：

Computer Configuration \ Preferences \ Windows Settings \ Files

marcelm · Answer

ルートCAを他の組織に導入しないでください

自己署名証明書を使用してActive Directory経由で配布することは可能ですが、かなり複雑です。エサ・ヨキネンは彼の答えでより詳細に行きます。

さらに重要なのは、セキュリティへの影響です。ルート証明書はマスターキーのようなものですADのルート証明書によって署名されたすべての証明書は、すべての会社のコンピューターによって信頼されます。アプリケーションでルート証明書を制御している場合、 yourapp.intranet 信頼できます任意のドメインを使用できます。 bigbank.com 、または google.com の場合も同様です。

基本的に、誰かにルート証明書をインストールさせると、HTTPS接続すべてを攻撃できるようになります。つまり、これらのキーを処理したり、失効を処理したり、セキュリティ違反を処理したりするための適切な手順が必要です。また、これらの企業はあなたに非常に多くの信頼を置く必要があることを意味します。申し訳ありません。

正直なところ、サプライヤが関連する懸念を完全に理解せずにすべてに適切な計画を立てることなく、独自のルートCAを組織に導入しようとした場合、拒否します。私はおそらくそれらの計画で彼らを拒否するでしょう。

組織によっては、おそらく独自の内部CAを既に持っています。その場合は、証明書を要求することができます。 CAの管理は彼らの責任であり、あなたの責任ではないので、これはこれらの問題のほとんどからあなたを解放します。また、アプリケーションのみの証明書を提供します。

代わりはありますか？

この代替アプローチを検討してください。アプリケーションの適切なドメイン名を取得し、任意のCAから通常のSSL証明書を取得します。コストが問題になる場合は、証明書を無料で提供している団体がいくつかあります。 Let's Encryptが好き。

ドメイン名の場合、最も明白なオプションはcompany.yourapp.comおよびyourapp.company.com。 1つ目は、ホスト名と証明書の取得がすべての展開で標準化されているため、管理が簡単です。後者では、クライアントのITに対処する必要がありますが、クライアントの統合が向上します。

ちなみに、これらのオプションはどちらも、アプリケーションがパブリックにアクセス可能である必要はありません（これは確かにオプションです）。ドメインは、アプリケーションが展開されている会社の内部のIPアドレスをポイントするだけの場合もあります。証明書を取得するには、メール検証または DNS検証を使用する必要があります。

別のオプションは、スプリットDNSを使用することです。ドメインは、証明書を取得できるように必要なCA検証をホストする、管理下にあるサーバーをポイントします。アプリケーションがデプロイされている会社では、内部DNSがドメインをプライベートアプリケーションサーバーにポイントします。

いくつかのコメントに返信する

私の意見では、セキュリティの狂信者はこのトピックを不釣り合いに吹き飛ばしています。彼らはオンラインバンキングのようなあらゆる状況を扱いますが、開発者が望むすべてが暗号化されたデータ転送である場合もあります。

欲しいものがありません。「単純な暗号化」を設定できますが、暗号化キーを交換すると、攻撃者は単純にそれらのキーを傍受して、そのキーを置き換えるになり、暗号化されたトラフィックをすべて読み取ることができます。証明書は、ブラウザが実際に攻撃者ではなく目的のサーバーと鍵を交換していることを保証します。この部分は安全な暗号化に必要です。

結局、本人確認は暗号化された通信を取得するために不可欠です。オプションではありません。

真実は、自己署名証明書がバンクオブアメリカで使用されているものと同じレベルの暗号化（データ転送中）を提供できることです。

これらの証明書を正しく配布できる場合のみ。これは、証明書を必要とするローカルコンピューターが1台だけの場合は簡単ですが、スケーリングが非常に悪く、 very 任意の数のコンピューターに対して正しく実行することが難しくなります。

そのため、認証局を使用しています。それらは、スケーラブルで合理的に安全な方法で証明書を配布する方法を提供します。

私の意見では、プライベートIPアドレスから提供されるアプリは、国際銀行と同じルールでプレイする必要はありません。

ことは、コンピュータは常識を持っていないということです。彼らは銀行のWebサイトにアクセスするには優れたセキュリティが必要であることを理解していませんが、アプリにアクセスするにはセキュリティが問題ありません。彼らはそれを理解できない。そして、彼らは試してはいけません。アプリが医療記録の処理を開始した場合はどうなりますか？突然、アプリのセキュリティを受け入れるという「常識」は受け入れられなくなります。コンピュータはその区別を知ることができません。

コンピュータがあなたのサイトでずさんなセキュリティを受け入れる必要がある場合、他のサイトでもそれを受け入れる必要があります。そして、幸運にも、それが受け入れられないほどになっています。それを受け入れ、誇りを持ってアプリケーションに同じ暗号化銀行が使用しているものを与えてください！

開発者にひどい不必要な負担をかける

いいえ、ありません。

はい、HTTPSでWebサイトを保護すると、開発者に負担がかかります。それをひどいまたは不必要なものと呼ぶことは、物事を不釣り合いに吹き飛ばしています。

正直なところ、サイトでいくつかのLet's Encrypt証明書を平手打ちします。それはあなたにあなたが望むセキュリティをプラスします（そして少し余分です）、そしてこれすべてについて不平を言うよりもはるかに少ない労力です。また、クライアントのCAになろうとするよりも労力が少なく安全です。