イントラネット用に独自のCAを作成する
イントラネット用に独自のCAを作成する必要がありますが、残念ながら、Security.SEにはこれに対する適切な回答がないようです。
これについてはオンラインで多くのリソースがありますが、それらはすべて異なり、信頼できないと思われる古いデフォルト（MD5/SHA1など）を使用するリソースもあります。 openssl.cnfには、10行のファイルから、デフォルトで私のディストリビューションに付属する巨大なファイルまで、数百のバリエーションがあります。
サーバー証明書とクライアント証明書を発行するためのsimpleCAの設定に関する正規の回答をお願いします。
どうやら一部の人々は、私がCAの妥協が数十億の価値の損失を引き起こし、簡単に軽減できないいくつかの大企業ではないことをまだ理解していないようです。
安全でないリンク（インターネット）を介して接続されている複数のサーバーは、安全に通信する必要があります。
10秒ごとにパスワードマネージャーに行ったり来たりすることなく、管理タスクを実行するために、これらのサーバーに対して自分自身を識別する方法が必要です。
そこ。私自身のPKIと各マシンにインストールされた証明書は、ニーズに完全に適合しているようです。私が使用しているソフトウェアの1つでもPKIを使用する必要があるため、自己署名証明書を使用するだけでは選択肢になりません。
PKIを危険にさらすには、誰かが私の作業マシンを危険にさらす必要があります。それが行われた場合、攻撃者はPKIに触れることなくすでにかなりのダメージを与えることができます（とにかく、このマシンからSSH経由でサーバーにログインします）。 。それは私が受け入れることを受け入れているリスクであり、このPKIはすでにあるリスクよりもリスクを追加しません。
インフラストラクチャがtinyの場合、CAの実行に関する詳細の多く（CRLなど）はおそらく無視できます。代わりに、本当に心配する必要があるのは証明書への署名だけです。
このプロセスを管理するツールは数多くあります。何年も前に書いたこともあります。しかし、本当にシンプルなものが欲しい場合に私がお勧めするのは、OpenVPNプロジェクトの easy-rsa です。これは、OpenSSLコマンドラインツールの非常に薄いラッパーです。多くの証明書を管理し、実際に失効などを扱う場合は、はるかに複雑で機能が完全なユーティリティが必要になります。すでに十分な提案が提供されているので、代わりに私はあなたが達成しようとしていることの基本に固執します。
しかし、ここに基本的な手順があります。 OpenSSLで説明しますが、どのシステムでもかまいません。
まず「ルート」CAを作成します。これは自己署名証明書になります。これにはいくつかの方法があります。これは一つです。 2048ビットのキーを使用した10年間の証明書にします。必要に応じて数値を調整します。ハッシュアルゴリズムについて心配しているとのことで、-sha256を追加して、許容できるもので署名されていることを確認しました。 AES-256を使用してキーを暗号化していますが、これはオプションです。証明書の名前などを入力するよう求められます。これらの詳細は、ルートCAにとって特に重要ではありません。
# First create the key (use 4096-bits if that's what floats your boat)
openssl genrsa -aes256 -out root.key 2048
# Then use that key to generate a self-signed cert
openssl req -new -x509 -key root.key -out root.cer -days 3652 -sha256
最初のステップでキーを暗号化した場合、2番目のステップでそれを使用するにはパスワードを入力する必要があります。生成された証明書をチェックして、「基本制約」の下に「CA：TRUE」が表示されていることを確認します。それが本当にあなたが心配しなければならない唯一の重要なビットです：
openssl x509 -text < root.cer
涼しい。では、証明書に署名しましょう。別のキーと今度はリクエストが必要です。名前と住所をもう一度尋ねられます。どのフィールドに入力し、何を提供するかはユーザーとアプリケーション次第ですが、最も重要なフィールドは「共通名」です。ここで、ホスト名やログイン名など、この証明書が証明するものを指定します。
# Create new key
openssl genrsa -aes256 -out client1.key 2048
# Use that key to generate a request
openssl req -new -key client1.key -out client1.req
# Sign that request to generate a new cert
openssl x509 -req -in client1.req -out client1.cer -CA root.cer -CAkey root.key -sha256 -CAcreateserial
これにより、シリアル番号を正確に保つためにroot.srlというファイルが作成されることに注意してください。 -CAcreateserialフラグは、opensslにこのファイルを作成するように指示するので、署名する最初のリクエストにそれを提供し、その後は二度とそれを行いません。もう一度、-sha256引数を追加する場所を確認できます。
このアプローチ-すべてを手動で行う-は私の考えでは最良のアイデアではありません。大規模な操作を実行している場合は、すべての証明書を追跡できるツールが必要になるでしょう。
代わりに、ここでの私のポイントは、必要な出力（必要な方法で署名された証明書）は、使用するツールに依存するのではなく、それらのツールに提供するオプションに依存することを示すことです。ほとんどのツールは、強いものと弱いものの両方を含むさまざまな構成を出力できます。適切と思われる数を提供するのは、あなた次第です。古いデフォルトはコースに並ぶ。
これを簡単に行う方法はありません。簡単に始めるのに役立つツールがいくつかあります。
お気に入り：
eJBCA以外は完全なPKIではありませんが、セットアップは簡単ではありません。
- XCAは、証明書を生成、署名、および取り消すためのグラフィカルインターフェイスを取得するための小さなフロントエンドツールです。
- EJBCAまたはエンタープライズJava Beans Certificate Authorityは、エンタープライズの完全なPKIインフラストラクチャを実行できるJBOSS/Jetty Webアプリケーションです。
- opensslは、基本的なコマンドラインツールです。 CAのすべてのオフラインビットを実行できますが、（箱から出して）検証は実行できません。それを使用して独自のOCSP検証を作成できますが、そのための「オンライン」コードを自分で作成する必要があります。
あなたが求めるすべてが適切なopenssl configである場合。 XCAはそれらを生成するのに役立ちます。 （openssl設定エクスポート機能があります
本当にCAになりたい場合は、そうすることによるセキュリティへの影響に注意してください。
- イントラネットのルートCAの生成に使用される秘密キーは、文字どおり金庫にロックする必要があります。そして、金庫へのアクセスは物理的に監視されるべきです。
- 自己署名ルートCAを使用すると、ユーザーはキーの安全な保護を備えたデューデリジェンスを実行していることを信頼するだけでなく、最初は信頼されていないルートカンを証明書チェーンに挿入することも強制されます。
- これにより、証明書チェーンの外部検証に関するOSCPステープリング機能も無効になります。これが、アイデンティティ管理サービスがそもそも存在する理由です。
次のような独自のCAの管理の背後にある理由を主張する人はかなりいます。デスクトップビルドの一部にルートCAが含まれる企業イントラネット用、または少数のユーザー用です。
これを行うことは必ずしも間違っているわけではなく、いくつかの利点をもたらす可能性がありますが、証明書ベースのID管理が構築された検証チェーンを無効にします。
独自のルートCAを実装する場合は、他のルートCAが使用するのと同じセキュリティ慣行に従ってください。会社としてあなたが最後に起こしたいのは、誰かがルートCAに使用されている秘密鍵を危険にさらし、クライアントに対するフィッシングキャンペーンの証明書への署名を開始することです。
このために利用できるベストプラクティスガイドはたくさんあります。NIST（標準と技術のための国立研究所）は、コンピューターセキュリティトピックのさまざまな標準を支援する共同グループです。
推奨読書：
監査（PDF）
災害復旧（PDF）
公開鍵システム（PDF）
小規模なPKI展開に関するSans研究所
わかりました。質問をより具体的に更新しました。
CA固有のopenssl.cnfファイルを構成するための2つのドキュメント：
https://www.openssl.org/docs/apps/ca.html
https://www.openssl.org/docs/apps/config.html
これはあなたが望む答えではないかもしれませんが、すべての環境と要件は異なるため、適切なサンプル構成のCA実装のスコープを定義する必要があります。
良い背景については、私のプレゼンテーションを参照してください平凡な独自の証明書管理センターを構築および運用する方法。プレゼンテーションの要点は、最も必要なのは実行するコマンドのリストではなく、商用CAの操作に使用されるさまざまなコントロール、それらがどのように相互作用するか、削除の正確な影響を深く理解することです。それらのいずれか、それらのいくつかを削除することによる累積的な影響、およびセキュリティの低下を補うために必要な緩和策。
これが、「単純なCAの設定に関する正規の回答」がない理由です。鍵署名者、エアギャップされ保管された複製のルート証明書、複数の中間署名者、失効サーバーなどから始めて、ISOルート全体に進むか、独自のコスト/メリットに基づいて妥協案を作成する必要があります。ビジネスが受け入れることをいとわないリスクプロファイル。定義でその評価を行うのに十分なスキルと経験を持つ人は、チートシートを必要としません。彼らは、達成されるビジネス機能とその要件を実装するために使用されるセキュリティプリミティブの深い理解に基づいて、正しいコマンド構文を解析できます。
プレゼンテーションには、この道を進み、ひどく間違ったお店の実際の取り組みからの物語があります。場合によっては、私の評価で、ミドルウェアのセキュリティで私ができることはまったくなく、内部CAの固有の弱点を克服できるとはまったく報告されていませんでした。米国の誰もが、プレゼンテーションが参照しているベンダーの少なくとも1つからサービスを購入していることを理解する必要があります。これらは銀行、信用組合、健康保険会社、小売業者などです。
推奨事項を「正しく」するためには、回答者が許容可能なリスクプロファイルについて主要な仮定を行う必要があり、リスクの考えと自分の考えが一致し、同期している度合いについて主要な仮定を行う必要があるため、まさにその提案はその顔に危険。ほとんどの場合、提供されたチュートリアルの適合性の評価は、手順に従うことから生じる効果的なセキュリティレベルよりもプレゼンテーションに関係しています。それがうまく整理され、明確に表現されている場合、これは効果的であるかどうかよりもはるかに重要です。 見た目が良い標準的なチートシートを選びます。
これらの理由により、信頼できる専門家が「正確で最新のopenssl.cnfファイル」ではありませんが、要件と許容可能なリスクをより完全に評価するための評価プロセスを提供するのが最善です。結果にビジネスを賭けているため、信頼できる専門家が契約の保護以外にこれを行うことはありません。推奨事項あなたが得ることは、ほぼ定義により、in信頼できる専門家からである必要があります。
以下の手順に従って WindowsベースのCA を構成します。クライアント証明書を発行しているので、SHA2ハッシュはXPではサポートされていないことに注意してください。
簡単な答えは次のとおりです。
- ADをインストールする
- ドメインコントローラにエンタープライズCAをインストールする
- 証明書テンプレートを編集してエンドユーザー証明書を発行します（ユーザーが自己登録するためのアクセス許可を設定するか、Webページに移動します）
- ユーザーを検証するすべてのサーバーにルート証明書の公開鍵をデプロイする
- ユーザーがADを使用している場合は、GPOを使用して自動登録を有効にします