Microsoft クラウド PKIは、IT 担当者がクラウドで公開キー インフラストラクチャ (PKI) を管理できるようにするIntune Suite 機能です。 オンプレミス インフラストラクチャをインストールして保守することなく、独自の証明機関 (CA) と証明書を作成、構成、管理できます。 Microsoft クラウド PKI サービスは、Microsoft Entra IDとMicrosoft Intuneと統合され、クラウドベースのデバイスとアプリの ID とデバイス管理を提供します。
この記事では、Microsoft クラウド PKIを構成するときに知っておくべき PKI の基礎と概念について説明します。 Intune テナントでMicrosoft クラウド PKI サービスを構成する前に、すべての情報を確認することをお勧めします。
証明機関の種類
証明機関は、次のタスクを実行します。
- 証明書リクエスタの ID を確認します
- 要求者に証明書を発行する
- 証明書失効を管理する
Microsoft クラウド PKIでは、次の種類の証明機関がサポートされています。
- ルート CA
- CA の発行
ルート証明機関
ルート証明機関 (CA) は、CA 階層内の最上位の CA です。 PKI では、ルート CA は階層内の CA によって発行された証明書の信頼ポイントとして機能します。 証明書は、CA 階層を介して、ユーザー、コンピューター、ネットワーク デバイス、またはサービスによって信頼されているルート CA にトレース できる場合、 信頼されていると見なされます。
ルート CA は、証明書が 自己発行されていること、つまり、証明書の発行者名とサブジェクト名に同じ識別名が含まれているという点で一意です。 ルート証明書が有効かどうかを確認する唯一の方法は、ルート CA 証明書を信頼されたルート ストアに含める方法です。 信頼されたルート ストアには、証明書が信頼されていることを示す実際のルート CA 証明書が含まれています。
ルート CA は、他の CA、またはネットワーク上のユーザー、コンピューター、ネットワーク デバイス、またはサービスに証明書を発行できます。 ルート CA が別のエンティティに証明書を発行すると、ルート CA 証明書は秘密キーを使用して証明書に署名します。 署名はコンテンツの変更から保護され、ルート CA が証明書を発行したことを示します。
重要
Microsoft クラウド PKIは、MDM に登録されているネットワーク デバイスにのみ証明書を発行します。
証明機関の発行
注:
中間、発行、および下位という用語は、CA 構造内で同じロールを参照するために使用されるすべての交換可能なラベルです。 Microsoft クラウド PKIは、発行元という用語を使用して、この種類の CA を記述します。
発行元 CA は、別の CA に従属する CA であり、次のいずれかを実行できます。
- CA 階層内の他の CA に証明書を発行します。
- サーバー、サービス、クライアント、デバイスなどのエンド エンティティにリーフ証明書を発行します。
発行元 CA は、ルート CA レベルを除き、CA 階層内の任意のレベルに存在できます。
チェーン
チェーン は、検証と信頼が必要な特定の証明書に対して最適な信頼パスが何であるかを確認するプロセスです。 各オペレーティング システムまたはサービスは、一般に 証明書チェーン エンジンと呼ばれるこの計算プロセスを実行します。
チェーン構築プロセスは、次で構成されます。
- 証明書の検出: エンド エンティティ リーフ証明書の発行元 CA 証明書を、信頼しているルート CA 証明書まで検索します。
- 証明書の検証: 考えられるすべての証明書チェーンを作成します。 名前、時刻、署名、失効、その他の定義された制約など、さまざまなパラメーターに関してチェーン内のすべての証明書を検証します。
- 最高品質のチェーンを返します。
証明書が検証用に提示されると、証明書チェーン エンジンは証明書ストアを調べ、中間証明書とルート証明書の候補を選択します。 完全なチェーンを形成するには、複数の中間証明書が必要になる場合があります。
証明書チェーン エンジンは、サブジェクト キー識別子 (SKI) と機関キー識別子 (AKI) を使用して証明書の選択を試みます。 Microsoft CA によって発行されたエンド エンティティ証明書には AKI が含まれているため、証明書チェーン エンジンは、一致する SKI を持つ中間証明書を選択する必要があります。 このプロセスは、自己署名証明書が列挙されるまで繰り返されます。
チェーン検証プロセス
注:
証明書チェーンの検証方法のサポートは、OS プラットフォームによって異なります。 このセクションでは、Windows 10 以降を実行しているデバイスでサポートされる方法について説明します。
Windows では、完全一致、キー一致、名前一致の 3 つのチェーン検証プロセスがあります。
完全一致: AKI 拡張機能に発行者のサブジェクト、発行者シリアル番号、および KeyID が含まれている場合、チェーン構築プロセスでは、サブジェクト、シリアル番号、および KeyID と一致する親証明書のみが選択されます。
キーの一致: AKI 拡張機能に KeyID のみが含まれている場合、サブジェクト キー識別子 (SKI) 拡張機能に一致する KeyID を含む証明書のみが有効な発行者として選択されます。
名前の一致: 名前の一致は、AKI に情報が存在しない場合、または AKI 拡張機能が証明書に存在しない場合に発生します。 この場合、発行者証明書のサブジェクト名は、現在の証明書の発行者属性と一致している必要があります。
SKI フィールドと AKI フィールドを含まない証明書の場合、チェーン エンジンは名前照合を使用してチェーンを構築しようとします。 同じ名前の証明書が 2 つある場合は、新しい証明書が選択されます。
証明書の検出 は、直接の親がコンピューター上でローカルでない場合に開始されます。 クライアントはこのプロセスを使用して、不足している親証明書を取得します。 証明書の機関情報アクセス フィールドに表示される URL が解析され、親 CA 証明書を取得するために使用されます。 このプロセスは CRL のダウンロードに似ています。
チェーンが構築されると、チェーン内の各証明書に対して次のチェックが実行されます。
- 正しく書式設定され、署名されていることを確認します。 証明書のハッシュ チェックを実行します。
- 証明書の from フィールドと to フィールドを確認して、有効期限が切れていないことを確認します。
- 証明書が失効しているかどうかを確認します。
- 信頼されたルート ストア内の証明書でチェーンが終了することを確認します。
証明書とそのチェーンは、すべてのチェックが完了した後に有効と見なされ、正常に戻ります。
証明書の順序付きリストを含む証明書チェーンを使用すると、証明書利用者は送信者が信頼できる状態であることを確認できます。 これは、クライアントからサーバー、サーバーからクライアントの両方の方法で機能します。
次の図は、チェーンの検証フローに 一致する名前 を示しています。
信頼のチェーンを確保する
証明書を使用して証明書ベースの認証を実行する場合は、両方の証明書利用者が CA 証明書 (公開キー) 信頼チェーンを持っていることを確認する必要があります。 この場合、証明書利用者は、Intuneマネージド デバイスと、Wi-Fi、VPN、Web サービスなどの認証アクセス ポイントです。
ルート CA が存在する必要があります。 発行元の CA 証明書が存在しない場合は、証明書利用者が、目的の OS プラットフォーム用のネイティブ証明書チェーン エンジンを使用して要求できます。 証明書利用者は、リーフ証明書の 機関情報アクセス プロパティを使用して、発行元 CA 証明書を要求できます。
証明書ベースの認証
このセクションでは、クライアントまたはデバイスが証明書ベースの認証を実行するときに使用されるさまざまな証明書の基本的な理解について説明します。
次の手順では、証明書ベースの認証中にクライアントと証明書利用者サービスの間で行われるハンドシェイクについて説明します。
- クライアントは、証明書利用者に何らかの形式の hello パケットを発行します。
- 証明書利用者は応答し、セキュリティで保護された TLS/SSL 経由で通信することを望むというメッセージが表示されます。 クライアントと証明書利用者が SSL ハンドシェイクを実行し、セキュリティで保護されたチャネルが確立されます。
- 証明書利用者は、クライアント認証に使用する証明書を要求します。
- クライアントは、認証を行うために証明書利用者にクライアント認証証明書を提示します。
Microsoft クラウド PKIのない環境では、プライベート CA は、証明書利用者が使用する TLS/SSL 証明書とデバイス クライアント認証証明書の両方を発行する役割を担います。 Microsoft クラウド PKIを使用してデバイス クライアント認証証明書を発行し、この特定のタスクのプライベート CA を効果的に置き換えることができます。