イントラネット用に独自のCAを作成する必要がありますが、残念ながら、セキュリティに関してこれについて良い答えはないようです。 SE。
これについてはオンラインで多くのリソースがありますが、それらはすべて異なり、信頼できないと思われる古いデフォルト（MD5 / SHA1など）を使用しているものもあります。 openssl.cnfには、10行のファイルから、ディストリビューションにデフォルトで付属している巨大なファイルまで、何百ものバリエーションがあります。
サーバー証明書とクライアント証明書を発行するための単純な CAの設定に関する標準的な回答。
どうやら、私が大企業ではないことをまだ理解していない人もいるようです。 CAの侵害は数十億の損失を引き起こし、簡単に軽減することはできないため、CAが必要な理由をもう少し詳しく説明します：
-
安全でないリンク（インターネット）を介して接続された複数のサーバー）安全に通信する必要があります。
-
10秒ごとにパスワードマネージャーに行き来することなく、管理タスクを実行するために、これらのサーバーに対して自分自身を識別する方法が必要です。
あります。私自身のPKIと各マシンにインストールされた証明書は、ニーズに完全に適合しているようです。私が使用しているソフトウェアの1つでもPKIを使用する必要があるため、自己署名証明書を使用することはできません。
PKIを侵害するには、誰かが私の作業マシンを侵害する必要があります。 「これが完了すると、攻撃者はPKIに触れることなく、すでにかなりの損害を与える可能性があります（とにかく、このマシンからサーバーにSSH経由でログインするため）。これは私が受け入れることを受け入れているリスクであり、このPKIは、既存のリスクよりも多くのリスクを追加することはありません。
コメント
回答
インフラストラクチャが小さい場合、CAの実行に関する詳細の多く（CRLなど）はおそらく無視できます。代わりに、本当に心配する必要があるのは、証明書に署名することだけです。
このプロセスを管理するツールはたくさんあります。私は何年も前に書いたものです。しかし、私がお勧めするのは本当にシンプルなものが必要なのは、OpenVPNプロジェクトの easy-rsa です。これはOpenSSLコマンドラインツールの非常に薄いラッパーです。大量の証明書を管理し、実際に失効などを処理する場合は、はるかに複雑で機能が充実したユーティリティが必要になります。すでに十分な数の提案が提供されているので、代わりに「あなたが達成しようとしていることの基本に固執します。
しかし、ここに基本的な手順があります。OpenSSLで説明します」 、ただし、どのシステムでもかまいません。
「ルート」CAを作成することから始めます。これは自己署名証明書になります。これを行うにはいくつかの方法があります。これは1つです。 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引数を追加します。
このアプローチ（すべてを手動で行う）は、最善のアイデアではないと思います。かなりの操作を実行している場合、次に、「すべての証明書を追跡できるツールが必要になる可能性があります。
代わりに、ここでの私のポイントは、必要な出力、つまり証明書が必要な方法で署名されていることを示すことでした。それら-使用するツールに依存するのではなく、それらのツールに提供するオプションに依存します。ほとんどのツールは、強弱の両方のさまざまな構成を出力できます。必要な数を指定するのはあなた次第です。 m適切。古くなったデフォルトはコースと同等です。
コメント
- ‘次の点に注意することが重要です。クライアント証明書に署名すると、それは public 部分のみになります。 CAによって秘密鍵が送信または生成されないようにする必要があります。
- 中間CA証明書の作成に関する回答を拡大していただけますか？ありがとう。
- @Andr é中間証明書は、拡張属性に
basicConstraints = CA:TRUEが設定された通常の証明書です。魔法はありません。別の証明書だけです。 - @tylerlおい、あなたは素晴らしいです。
- この回答は素晴らしいもので、非常に役に立ちましたが、2017年のアップデートを追加する必要があります。 Chromeなどでは、x509v3
subjectAlternativeName拡張機能が必要になりました。そうしないと、CAルート証明書がシステムに正しくインストールされていても、証明書は無効であると見なされます。私はしばらくの間、正しい解決策を考え出すのに苦労しました。このページは私にとって非常に貴重であり、パズルの最後のピースである cmrg.fifthhorseman.net/wiki/SubjectAltName を解決しました。 IMOは、要求時ではなく署名時にSANを追加する方が簡単であり、公開CAが実際に行うことと似ています。
回答
本当にCAになりたい場合は、そうすることによるセキュリティへの影響に注意してください。
- イントラネットのルートCAを生成するために使用される秘密鍵は文字通り必要です。金庫に閉じ込められます。また、上記の金庫へのアクセスは物理的に監視する必要があります。
- 自己署名ルートCAを使用すると、ユーザーは、キーの安全な保護でデューデリジェンスを実行していることを信頼するだけでなく、最初は信頼できないルートを挿入する必要があります。
- これにより、証明書チェーンの外部検証に関するOSCPステープリング機能も機能しなくなります。これがID管理サービスが最初に存在する理由です。
かなりの数の人が、次のような独自のCAの管理の背後にある理由について議論します。これは、デスクトップビルドの一部にルートCAが含まれている、または少数のユーザー向けである企業イントラネット用です。
必ずしも間違っているわけではなく、いくつかのメリットがあります。証明書ベースのID管理が構築された検証チェーンを無効にします。
独自のルートCAを実装する場合は、他のルートCAが使用するのと同じセキュリティ慣行に従うようにしてください。最後に、誰かがルートCAに使用されている秘密鍵を侵害し、クライアントに対するフィッシングキャンペーンの証明書に署名し始めることをお勧めします。
これに利用できるベストプラクティスガイドはたくさんあります、NIST（ National Institute for Standards and Technology）は、コンピュータセキュリティトピックのさまざまな標準を支援する共同グループです。
推奨読書：
監査（PDF）
災害復旧（PDF）
公開鍵システム（PDF）
サンズインスティテュート小規模なPKI展開
質問をより具体的に更新したようです。
CA固有のopenssl.cnfファイルを構成するための2つのドキュメント：
https://www.openssl.org/docs/apps/ca.html
https://www.openssl.org/docs/apps/config.html
これはあなたが望む答えではないかもしれませんが、すべての人の環境と要件が異なるため、あなたは良い例の設定のために、CA実装のスコープを定義する必要があります。
コメント
- そこに’独自のCAがOCSPを実行できない理由はありません。 OpenSSLコマンドラインでも実行できます。’ s可能な限り低いバーについて。
- opensslリンクは404になりました
回答
ありますこれを簡単に行う方法はありません。簡単に始めるのに役立つツールがいくつかあります。
like：
いずれもおそらくEJBCAを除いて、完全なPKIですが、セットアップは簡単ではありません。
- XCAは、証明書を生成、署名、および取り消すためのグラフィカルインターフェイスを取得するための小さなフロントエンドツールです。
- EJBCAまたはEnterpriseJava Beans認証局は、企業向けに完全なPKIインフラストラクチャを実行できるJBOSS / JettyWebappです。
- opensslは基本的なコマンドラインツールです。 CAのすべてのオフラインビットを実行できますが、検証は実行できません（すぐに使用できます）。それを使用して独自のOCSPベリファイアを作成できますが、そのための「オンライン」コードを自分で作成する必要があります。
必要なのが適切なopenssl構成だけである場合。 XCAは、それらの生成を支援します。 （openssl構成エクスポート機能があります
コメント
- EJBCAに使用できるVMイメージがあります。それ以外の場合は”セットアップは簡単ではありません”は控えめな表現と見なすことができます。これは基本的に、（を構成しようとする巨大な
antスクリプトです。 JBoss）故障する可能性のある（そして私の場合は ）アプリケーションサーバー。 - VMイメージは評価目的であるため、本番サーバーにはお勧めしません。
- XCAを調べるかもしれません。EJBCAは間違いなく’オプションではありません。Webインターフェイスは不要な攻撃面を追加し、セットアップが困難です。ただし、opensslです。
- @Andr é EJBCAに関しては、コマンドラインからも使用できるため、’ Webインターフェイスを公開する必要はありませんが、’はエンタープライズレベルのものであり、おそらくあなたの目的にはやり過ぎです。 es（そして私はこれを使って生計を立てている人として言います）
回答
一部の人にとって良い背景があります。私のプレゼンテーション 独自の平凡な証明書管理センターを構築および運用する方法 をご覧ください。プレゼンテーションの要点は、実行するコマンドのリストではなく、商用CAの運用に使用されるすべてのさまざまなコントロール、それらがどのように相互作用するか、削除することの正確な影響を深く理解することです。そのうちの1つ、それらのいくつかを削除することによる累積的な影響、およびセキュリティの低下を補うために必要な緩和制御。
これが、「単純なCAの設定に関する標準的な答え」がない理由です。主要な署名者、エアギャップおよびボールト化された重複ルート証明書、複数の中間署名者、失効サーバーなどから始めて、ISOルート全体を実行するか、固有のコスト/メリットとリスクに基づいて妥協案を考案する必要があります。ビジネスが喜んで受け入れるプロファイル。定義上、その評価を行うのに十分なスキルと経験を持っている人は誰でも、チートシートを必要としません。彼らは、達成すべきビジネス機能とその要件を実装するために使用されるセキュリティプリミティブの深い理解に基づいて、正しいコマンド構文を解析できます。
プレゼンテーションには、この道を進んでひどく間違った店の実際の関与からの話があります。場合によっては、私の評価では、ミドルウェアのセキュリティで私ができることは、内部CAの固有の弱点を克服できる可能性があると報告されています。米国の誰もが、おそらくプレゼンテーションが参照しているベンダーの少なくとも1つからサービスを購入していることを理解する必要があります。これらは、銀行、信用組合、健康保険会社、小売業者などです。
推奨事項が「正しい」ためには、回答者が許容可能なリスクプロファイルについて主要な仮定を立てる必要があり、あなたと彼らのリスクの考え方がどの程度一致しているかについて主要な仮定を立てる必要があります。同期して、提案そのものはその面で危険です。ほとんどの場合、提供されるチュートリアルの適合性の評価は、手順に従うことで得られる効果的なセキュリティレベルよりも、プレゼンテーションに関係しています。それがうまく組織化され、明確に表現されている場合、これはそれが効果的であるかどうかよりもはるかに重要です。 私たちに最もよく見える標準的なチートシートを選択します。
これらの理由から、信頼できる専門家が「正確で最新のファイル」ではなく、要件と許容可能なリスクをより完全に評価するための評価プロセスを提供するだけかもしれません。結果にビジネスを賭けているため、信頼できる専門家は、契約。あなたが得るどんな推薦も、ほとんど定義上、信頼できる専門家からのものでなければなりません。頑張ってください。
コメント
- 内部リソース用のイントラネットの場合でも、プレゼンテーションが自分のものであることを示すこともできます。
- “内部リソース用のイントラネット？” 特に それ以降のイントラネット用’ほとんどのデータ侵害が発生する場所。”また、プレゼンテーションはあなた自身のものであると。”評価を行った経験を説明するときに持っていたと思いましたが、要点を説明しました。 ‘更新しました。
回答
フォローしてください WindowsベースのCA を構成する手順。クライアント証明書を発行しているため、XPではSHA2ハッシュがサポートされていないことに注意してください。
簡単な答えは次のとおりです。
- ADをインストールする
- ドメインコントローラーにエンタープライズCAをインストールする
- 証明書テンプレートを編集してエンドユーザー証明書を発行します（ユーザーが自己登録するか、Webページにアクセスするためのアクセス許可を設定します）
- ユーザーを検証するすべてのサーバーにルート証明書の公開鍵を展開します
- ユーザーがADを使用している場合は、GPOを使用して自動登録を有効にします
echo "Abandon all hope, ye who enter here."個人証明書には
isCA=Noフラグとパス長がゼロである必要があります。”残念ながら、失効、名前空間の衛生状態、ルートセキュリティなど、システムへの信頼のほとんどが基づいているポリシーは、openssl.cnfdivで扱われていません’ >。