1層から2層のMicrosoft認証局階層への移行
現在、単一のMicrosoftエンタープライズルートCAがあり、2要素認証のためにVPNユーザーに証明書を発行しています。 CAの使用を拡張して、RDPおよびDell Open Manage（システム管理アプリケーション）の証明書を発行する予定です。
これまでに読んだほとんどの読書は、現在のアーキテクチャが理想的ではないことを示唆しています-理解しているように、強化されたエンタープライズルートCAが必要で（おそらく電源がオフになっているかもしれません）、発行CAを使用して実際に発行します証明書。理想的には、信頼性の理由から、発行CAもクラスター化されます。
私の質問は：
1）上記のように、単一層アプローチから2層アプローチに移行するにはどうすればよいですか。
2）これは、既存のVPN証明書を壊さずに再発行する必要なく可能ですか？
3）このプロセスをより詳細な手順で説明している本/ブログ/ウェブサイトを知っている人はいますか？
私がこのトピックで見つけることができる資料の多くは、Microsofts TechnetのWebサイトにありますが、有用であるとは限りません。
ありがとう
ブラッド
理論的には、証明書を再発行することなく「2層」アプローチに移行することは可能ですが、これが良いアイデアかどうかは明確ではありません。
いくつかのシステムが証明書を検証するとき、それはチェーンを構築します検証する証明書（「エンドエンティティ」として「EE」と呼ばれます）へのアンカー（「システムでハードコードされた「ルート証明書」）を信頼します。基本的な考え方は、チェーン内の各証明書には、次の証明書の署名を検証するために使用される公開鍵が含まれているということです。証明書の形式には署名用のフィールドが含まれており、そのフィールドはオプションではないため、ルート証明書も署名されます。ただし、誰もその署名を検証せず（トラストアンカーは署名されているためではなく、「定義上」信頼されています）、ルート証明書が自己署名されるのは伝統的です。
署名が暗号的に正しい場合、および証明書が X.509 に詳述されている一連のプロパティを満たす場合、検証者はチェーンを受け入れます。簡単にするために、各証明書にはサブジェクト名と発行者名;発行者名は、それを発行した証明書のサブジェクト名（つまり、チェーン内の前の証明書）と同じである必要があります。この場合も、ルート証明書には発行者がないため、ルート自体が発行者である（発行者とサブジェクトの名前が等しい）のが伝統的です（ただし必須ではありません）。
したがって、新しいルートと、新しいルートによって発行された中間CAの組み合わせでルートを置き換える必要があります。中間CA証明書に古いルートと同じサブジェクト名と同じ公開鍵（および同じ「キー識別子」と他のX.509拡張）が含まれている場合、以前に発行されたEE証明書は古いルート（両方）に対して検証可能です。現在のように）および新しいルートに対して、新しいルートで始まり、中間CAを通過して終了するチェーンの一部としてEE。
MicrosoftエンタープライズルートCAが、古いルートの特性（名前、公開キー...）を再利用する中間CAを作成するための便利なインターフェイスを提供するかどうかはわかりません。ただし、そうした場合、そのような中間CAを作成すると、既存のVPN証明書をすぐに置き換える必要がなく、移行作業の半分が実行されます。
しかし、あなたはまだ終わっていません。新しいルートはdeployedである必要があります。つまり、検証者は新しいルートを認識している必要があり、古いルートも忘れる必要があります（後者はわずかに遅延）。これは高価な部分であり、トラストアンカーは信頼システムの基盤であるため、注意が必要です。管理者のように見える電子メールから指示されたからといって、トラストアンカーをいじるようにユーザーを「教育」したくありません。
今、よく理解されなければならない構造的な専門性があります。クライアント証明書を使用するVPNでは、クライアント証明書の検証者はサーバーです。ただし、このようなVPNはおそらくクライアント証明書によって検証されるサーバー証明書も使用します。 client証明書の検証に使用されるルートCAを変更する場合、その検証を行うシステムに新しいルートを挿入する必要があります。これがサーバーです（したがって、おそらくこれは簡単です）。 server証明書を発行するPKIで新しいルート証明書に切り替える場合にのみ、クライアントのトラストアンカーを変更する必要があります。おそらく、両方に同じルートを使用しましたが、これは絶対的な要件ではありません。
中間CAが必要になる主な理由は、損傷の封じ込めのためです。中間CAは、新しい証明書に毎日署名するCAです。したがって、おそらくオンラインであり、重複している可能性があり、攻撃に対して脆弱です。危険にさらされた場合は、ルートに権限を与えて（新しいキーで）新しい中間CAを作成し、以前の中間CAを取り消すことができます。したがって、verifiersの信頼設定を変更せずに、侵害から回復できます。新しい証明書を発行して、セキュリティが侵害されたCAによって発行された証明書を置き換える必要があります。
あなたのVPNシステムには、直接制御しているサーバーが1つあるか、場合によってはいくつかのサーバーがあると想定しています。その（これらの）サーバーのトラストアンカーを変更することは、簡単で安価なはずです。同様に、サーバーに新しい証明書を発行するのも簡単です。また、これを頻繁に行うことはないため、サーバー証明書のルートはオフラインにすることができ、スケーリングする必要はありません。これは、年に1〜2回実行され、それ以上は実行されません。ルートで行うのと同じ方法で中間CAを管理できるため、サーバー証明書に2層のアプローチをとる必要はほとんどありません。オフラインで、ほとんどの場合、安全に保管されます。クライアント証明書については、多くの証明書を発行するため、それらのCAは稼働しており、ネットワーク化されており、スケーラブルであり、したがって脆弱です。ただし、セキュリティが侵害された場合でも、クライアント証明書のトラストアンカーを変更することは難しくありません。そのトラストアンカーは単一のVPNサーバーにあります。そこで、2層のアプローチを使用することはできますが、その追加のレベルではあまり効果がありません。ダースのサーバーでトラストアンカーを変更するコストを節約するだけです。クライアント証明書を発行したCAの妥協の実際のコストは、新しいクライアント証明書を発行する必要があり、すぐに、2層のCAを変更することです。それに何も。
中間CA証明書を使用した「2層」PKIは、証明書の所有者と検証者の両方が、PKIを管理する誰もが簡単に制御できないシステムがある場合に適しています。 VPN/RDP設定では、これは、サーバーの数が数百である場合に適用され、サーバー証明書、またはサーバー、無視できない。
今、私は過度に冗長になっています。総括する：
- 以前に発行された証明書に影響を与えずにルートCAを中間CAに変換することは、理論的には可能です。
- 特定のPKIシステムの実装が、そのための使いやすいインターフェースを提供するかどうかは、別の問題です。
- 「2層」は状況の状況では良い考えですが、他の状況（一般的なVPNインストールについて私が想定していることを含む）の場合は、購入しません多くの、そしてそれはいくつかの複雑さを追加するので、それが努力の価値があるかどうかは不明です。
- PKIについて考えるには、誰がどの証明書を検証するかを特定する必要があります。特に、サーバーPKI（クライアントが検証するサーバーの証明書を発行するPKI）とクライアントPKI（サーバーが検証するクライアントの証明書を発行するPKI）は同じである必要はなく、おそらく異なるものを要求する管理プロセス。