証明書の要件と列挙

• 適用対象:

  ✅ Windows 11, ✅ Windows 10, ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

IT プロフェッショナルおよびスマート カード開発者向けのこのトピックでは、スマート カードのサインインに証明書を管理して使用する方法について説明します。

スマート カードを挿入すると、次の手順が実行されます。

注

特に説明がない限り、すべての操作はサイレントで実行されます (CRYPT_SILENTは CryptAcquireContext に渡されます)。

1. スマート カード リソース マネージャー データベースは、スマート カードの暗号化サービス プロバイダー (CSP) を検索します。

2. 修飾されたコンテナー名は、スマート カード リーダー名を使用して構築され、CSP に渡されます。 形式は \\.<Reader name>\

3. 既定のコンテナーにコンテキストを取得するために、CryptAcquireContext が呼び出されます。 エラーが発生した場合、スマート カードのサインインではスマート カードを使用できません。

4. コンテナーの名前は、CryptGetProvParam で PP_CONTAINER パラメーターを使用して取得されます。

5. 手順 3 で取得したコンテキストを使用して、CSP は PP_USER_CERTSTORE パラメーターに対してクエリを実行します。 詳細については、「 スマート カードアーキテクチャ」を参照してください。 操作が成功すると、証明書ストアの名前が返され、プログラム フローは手順 8 にスキップされます。

6. 手順 5 の操作が失敗した場合、手順 3 の既定のコンテナー コンテキストがAT_KEYEXCHANGE キーに対してクエリされます。

7. その後、証明書は、KP_CERTIFICATEを使用してキー コンテキストから照会されます。 証明書は、メモリ内の証明書ストアに追加されます。

8. 手順 5 または手順 7 の証明書ストア内の証明書ごとに、次のチェックが実行されます。

   1. 証明書は、コンピューター のシステム クロックに基づいて有効である必要があります (有効期限が切れていないか、将来の日付で有効)。
   2. 証明書がコンテナーのAT_SIGNATURE部分に含まれていない
   3. 証明書には有効なユーザー プリンシパル名 (UPN) が必要です
   4. 証明書にはデジタル署名キーの使用法が必要です
   5. 証明書にはスマート カード ログオン EKU が必要です

   これらの要件を満たす証明書は、証明書の UPN (または証明書拡張機能の存在に応じて電子メール アドレスまたは件名) を持つユーザーに表示されます。

9. その後、プロセスによって証明書が選択され、PIN が入力されます

10. LogonUI.exe 情報をパッケージ化し、Lsass.exe に送信してサインイン試行を処理します

11. 成功した場合、 LogonUI.exe は閉じます。 これにより、手順 3 で取得したコンテキストが解放されます

Windows でのスマート カード サインイン フロー

認証中のほとんどの問題は、セッションの動作の変更が原因で発生します。 変更が発生した場合、ローカル セキュリティ機関 (LSA) はセッション コンテキストを再取得しません。これは、代わりに暗号化サービス プロバイダーに依存してセッションの変更を処理します。

証明書の subjectAltName (SAN) フィールドに UPN が含まれていないクライアント証明書は、さまざまな証明書をサポートし、同じカードで複数のサインイン証明書をサポートするサインインに対して有効にすることができます。

同じカード上の複数の証明書のサポートは、既定で有効になっています。 新しい証明書の種類は、グループ ポリシーを使用して有効にする必要があります。

[ログオン資格情報プロバイダーの 有効な署名キーを許可する ] ポリシーを有効にした場合、署名専用キーを持つスマート カードで使用できる証明書がサインイン画面に一覧表示されます。 これにより、ユーザーはサインイン エクスペリエンスを選択できます。 ポリシーが無効になっているか、構成されていない場合、スマート カード署名キーベースの証明書はサインイン画面に一覧表示されません。

次の図は、サポートされているバージョンの Windows でのスマート カード サインインのしくみを示しています。

スマート カードサインインフロー

スマート カードのサインイン中に実行される手順を次に示します。

1. Winlogon がサインイン UI 資格情報を要求する

2. スマート カード リソース マネージャーが非同期的に起動し、スマート カード資格情報プロバイダーによって次の処理が行われます。

   1. 資格情報 (既知の資格情報の一覧、または資格情報が存在しない場合は、Windows によって検出されたスマート カード リーダー情報) を取得します。
   2. (WinSCard API を使用して) スマート カード リーダーの一覧と、各カードに挿入されたスマート カードの一覧を取得します
   3. 各カードを列挙して、グループ ポリシーによって制御されるサインイン証明書が存在することを確認します。 証明書が存在する場合、スマート カード資格情報プロバイダーは、コンピューターまたはターミナル上の一時的なセキュリティで保護されたキャッシュにコピーします

   注

   スマートカード キャッシュ エントリは、サブジェクト名またはサブジェクト キー識別子を持つ証明書に対して作成されます。 証明書にサブジェクト名がある場合は、サブジェクト名と証明書発行者に基づくインデックスが格納されます。 同じサブジェクト名と証明書発行者を持つ別の証明書を使用すると、既存のキャッシュされたエントリが置き換えられます。 この動作の変更により、証明書にサブジェクト名がない場合の条件が許可され、サブジェクト キー識別子と証明書発行者に基づくインデックスを使用してキャッシュが作成されます。 別の証明書にサブジェクト キー識別子と証明書発行者が同じ場合、キャッシュ エントリが置き換えられます。 証明書にサブジェクト名とサブジェクト キー識別子がない場合、キャッシュされたエントリは作成されません。

   1. サインイン UI に新しい資格情報があることを通知します

3. サインイン UI は、スマート カード資格情報プロバイダーに新しい資格情報を要求します。 応答として、スマート カード資格情報プロバイダーはサインイン UI に各サインイン証明書を提供し、対応するサインイン タイルが表示されます。 ユーザーがスマート カードベースのサインイン証明書タイルを選択すると、Windows に [PIN] ダイアログ ボックスが表示されます

4. ユーザーが PIN を入力し、Enter キーを押します。 スマート カード資格情報プロバイダーが PIN を暗号化する

5. LogonUI システムに存在する資格情報プロバイダーは、PIN を収集します。 スマート カード資格情報プロバイダーでの資格情報のパッケージ化の一環として、データはKERB_CERTIFICATE_LOGON構造でパッケージ化されます。 KERB_CERTIFICATE_LOGON構造の主な内容は、スマート カード PIN、CSP データ (リーダー名やコンテナー名など)、ユーザー名、ドメイン名です。 サインイン ドメインが同じフォレスト内にない場合は、証明書を複数のユーザー アカウントにマップできるため、ユーザー名が必要です

6. 資格情報プロバイダーは、データ (暗号化された PIN、コンテナー名、リーダー名、カード キーの仕様など) をラップし、LogonUI に送信します

7. Winlogon は、LSALogonUser のユーザー情報を使用して LogonUI から LSA にデータを表示します

8. LSA は Kerberos 認証パッケージ (Kerberos SSP) を呼び出して、(RFC 4556 で指定されている) 事前認証子を含む Kerberos 認証サービス要求 (KRB_AS_REQ) を作成します (RFC 4556: Kerberos での初期認証の公開キー暗号化 (PKINIT))。

   デジタル署名を使用する証明書を使用して認証を実行する場合、事前認証データは、ユーザーの公開証明書と、対応する秘密キーでデジタル署名された証明書で構成されます。

   キー暗号化を使用する証明書を使用して認証を実行する場合、事前認証データは、ユーザーの公開証明書と、対応する秘密キーで暗号化された証明書で構成されます。

9. (RFC 4556 に従って) 要求にデジタル署名するには、秘密キー操作の対応する CSP に対して呼び出しが行われます。 この場合の秘密キーはスマート カードに格納されるため、スマート カード サブシステムが呼び出され、必要な操作が完了します。 結果は Kerberos セキュリティ サポート プロバイダー (SSP) に返送されます。

10. Kerberos SSP は、チケット許可チケット (TGT) (RFC 4556 ごと) の認証要求を、ドメイン コントローラーで実行されるキー配布センター (KDC) サービスに送信します。

11. KDC は、「 クライアント証明書の要件とマッピング」で詳しく説明されているように、Active Directory Domain Services (AD DS) でユーザーのアカウント オブジェクトを検索し、ユーザーの証明書を使用して署名を確認します。

12. KDC は、ユーザーの証明書 (時間、パス、失効状態) を検証して、証明書が信頼できるソースからのものであることを確認します。 KDC は CryptoAPI を使用して、ユーザーの証明書から、ドメイン コントローラーのルート ストアに存在するルート証明機関 (CA) 証明書への認定パスを構築します。 次に、KDC は CryptoAPI を使用して、事前認証データ フィールドに含まれていた署名付き認証子のデジタル署名を検証します。 ドメイン コントローラーは署名を検証し、ユーザーの証明書の公開キーを使用して、要求が公開キーに対応する秘密キーの所有者から送信されたことを証明します。 KDC は、発行者が信頼されていることも確認し、NTAUTH 証明書ストアに表示されます。

13. KDC サービスは、AD DS からユーザー アカウント情報を取得します。 KDC は、AD DS から取得するユーザー アカウント情報に基づいて TGT を構築します。 TGT の承認データ フィールドには、ユーザーのセキュリティ識別子 (SID)、ユーザーが属するユニバーサル ドメイン グループとグローバル ドメイン グループの SID、および (マルチドメイン環境では) ユーザーがメンバーであるユニバーサル グループの SID が含まれます。

14. ドメイン コントローラーは、KRB_AS_REP応答の一部として TGT をクライアントに返します。

    注

    KRB_AS_REP パケットは次で構成されます。

    • 特権属性証明書 (PAC)
    • ユーザーの SID
    • ユーザーがメンバーである任意のグループの SID
    • チケット付与サービス (TGS) の要求
    • 事前認証データ

    TGT は KDC のマスター キーで暗号化され、セッション キーは一時キーで暗号化されます。 この一時キーは RFC 4556 に基づいて派生します。 CryptoAPI を使用すると、一時キーが復号化されます。 暗号化解除プロセスの一環として、秘密キーがスマート カード上にある場合は、指定した CSP を使用してスマート カード サブシステムに対して呼び出しを行い、ユーザーの公開キーに対応する証明書を抽出します。 (証明書のプログラムによる呼び出しには、CryptAcquireContext、PIN を使用した CryptSetProvParam、CryptgetUserKey、CryptGetKeyParam が含まれます)。一時キーが取得されると、Kerberos SSP によってセッション キーが復号化されます。

15. クライアントは、KDC からの応答 (時刻、パス、失効状態) を検証します。 最初に KDC の証明書から信頼されたルート CA への認定パスを構築することによって KDC の署名を検証し、次に KDC の公開キーを使用して応答署名を確認します。

16. TGT が取得されたので、クライアントは、ローカル コンピューターへのサインインに使用されるサービス チケットを取得します。

17. 成功すると、LSA はチケットを格納し、LSALogonUser に成功メッセージを返します。 この成功メッセージが発行されると、デバイスのユーザー プロファイルが選択されて設定され、グループ ポリシーの更新がインスタンス化され、その他のアクションが実行されます。

18. ユーザー プロファイルが読み込まれた後、Certification Propagation Service (CertPropSvc) によってこのイベントが検出され、スマート カード (ルート証明書を含む) から証明書が読み取られ、ユーザーの証明書ストア (MYSTORE) に設定されます。

19. CSP からスマート カード リソース マネージャーへの通信は、LRPC チャネルで行われます。

20. 認証が成功すると、証明書は証明書伝達サービス (CertPropSvc) によって非同期的にユーザーのストアに伝達されます。

21. カードが削除されると、一時的なセキュリティで保護されたキャッシュ ストア内の証明書が削除されます。 [証明書] はサインインに使用できなくなりましたが、ユーザーの証明書ストアに残ります。

注

SID は、ユーザー アカウントまたはグループ アカウントがローカル セキュリティ アカウント データベース内または AD DS 内で作成された時点で、ユーザーまたはグループごとに作成されます。 ユーザーまたはグループ アカウントの名前が変更されても、SID は変更されません。

Kerberos プロトコルの詳細については、「 Microsoft Kerberos」を参照してください。

既定では、KDC は、クライアントの証明書にスマート カード クライアント認証 EKU szOID_KP_SMARTCARD_LOGONが含まれていることを確認します。 ただし、有効にした場合、[ 拡張キー使用法証明書属性のない証明書を許可する] グループ ポリシー設定では、KDC で SC-LOGON EKU を必要としません。 SC-LOGON EKU は、公開キーに基づくアカウント マッピングには必要ありません。

KDC 証明書

Active Directory 証明書サービスには、次の 3 種類の証明書テンプレートが用意されています。

• ドメイン コントローラー
• ドメイン コントローラー認証
• Kerberos 認証

ドメイン コントローラーの構成に応じて、これらの種類の証明書のいずれかがAS_REP パケットの一部として送信されます。

クライアント証明書の要件とマッピング

証明書の要件は、Windows オペレーティング システムのバージョン別に一覧表示されます。 証明書マッピングは、証明書の情報がユーザー アカウントにどのようにマップされるかを示します。

証明書の要件

コンポーネント	要件
CRL 配布ポイントの場所	任意
主な使用法	デジタル署名
基本的な制約	任意
拡張キー使用法 (EKU)	スマート カード サインイン オブジェクト識別子は必要ありません。 手記 EKU が存在する場合は、スマート カード サインイン EKU が含まれている必要があります。 EKU のない証明書は、サインインに使用できます。
サブジェクトの別名	スマート カードのサインインには電子メール ID は必要ありません。
サブジェクト	任意
キー交換 (AT_KEYEXCHANGE フィールド)	グループ ポリシー設定が有効になっている場合、スマート カードサインイン証明書には必要ありません。 (既定では、グループ ポリシー設定は有効になっていません)。
CRL	任意
UPN	任意
注	スマート カード資格情報プロバイダーに対して任意の証明書を表示できるように設定できます。

クライアント証明書のマッピング

証明書マッピングは、証明書の subjectAltName (SAN) フィールドに含まれる UPN に基づいています。 SAN フィールドに情報が含まれていないクライアント証明書もサポートされています。

SSL/TLS は SAN を持たない証明書をマップでき、マッピングはクライアント アカウントで AltSecID 属性を使用して行われます。 SSL/TLS クライアント認証で使用される X509 AltSecID は、"X509: <Issuer Name><Subject Name" 形式です。 <Issuer Name>と<Subject Name>はクライアント証明書から取得され、'\r' と '\n' は ',' に置き換えられます。

証明書失効リスト配布ポイント

[サブジェクトの別名] フィールドの UPN

[件名] フィールドと [発行者] フィールド

このアカウント マッピングは、他の 6 つのマッピング メソッドに加えて、KDC でサポートされています。 次の図は、KDC によって使用されるユーザー アカウント マッピング ロジックのフローを示しています。

サインインの証明書処理の概要フロー

証明書オブジェクトが解析され、ユーザー アカウント マッピングを実行するコンテンツが検索されます。

• ユーザー名に証明書を指定すると、アカウント オブジェクトの検索にユーザー名が使用されます。 文字列の一致が発生するため、この操作は最も高速です
• 証明書オブジェクトのみを指定すると、ユーザー名をアカウント オブジェクトにマップするユーザー名を特定するための複数の操作が実行されます。
• 認証に使用できるドメイン情報がない場合、ローカル ドメインは既定で使用されます。 他のドメインを参照に使用する場合は、マッピングとバインドを実行するためにドメイン名ヒントを指定する必要があります

証明書から属性を取得する汎用 API がないため、ジェネリック属性に基づくマッピングは不可能です。 現在、アカウントを検索する最初のメソッドは、検索を正常に停止します。 ただし、クライアントがマッピング ヒントを介してクライアント名を指定しない場合、2 つの方法で同じ証明書を別のユーザー アカウントにマップすると、構成エラーが発生します。

次の図は、証明書内のさまざまなエントリを表示して、ディレクトリにサインインするためのユーザー アカウントをマッピングするプロセスを示しています。

証明書処理ロジック

NT_AUTHポリシーは、CertVerifyCertificateChainPolicy 関数の CERT_CHAIN_POLICY_NT_AUTH パラメーター セクションで最もよく説明されています。 詳細については、「 CertVerifyCertificateChainPolicy」を参照してください。

1 つの証明書を持つ 1 人のユーザーが複数のアカウントにスマート カードでサインインする

1 つのユーザー証明書を複数のアカウントにマップできます。 たとえば、ユーザーがユーザー アカウントにサインインしたり、ドメイン管理者としてサインインしたりできる場合があります。 マッピングは、クライアント アカウントの属性に基づいて構築された AltSecID を使用して実行されます。 このマッピングの評価方法については、「 クライアント証明書の要件とマッピング」を参照してください。

注

各アカウントには異なるユーザー名があるため、[ ユーザー名のヒントを許可する ] グループ ポリシー設定 (X509HintsNeeded レジストリ キー) を有効にして、ユーザーがサインインするユーザー名とドメイン情報を入力できる省略可能なフィールドを指定することをお勧めします。

証明書で使用できる情報に基づいて、サインイン条件は次のとおりです。

1. 証明書に UPN が存在しない場合:
   1. 1 つの証明書を持つ 1 人のユーザーが別のアカウントにサインインする必要がある場合、サインインはローカル フォレストまたは別のフォレストで発生する可能性があります
   2. マッピングが一意でない場合は、ヒントを指定する必要があります (たとえば、複数のユーザーが同じ証明書にマップされている場合)
2. 証明書に UPN が存在する場合:
   1. 証明書を同じフォレスト内の複数のユーザーにマップすることはできません
   2. 証明書は、異なるフォレスト内の複数のユーザーにマップできます。 ユーザーが他のフォレストにサインインするには、X509 ヒントをユーザーに提供する必要があります

複数のユーザーが 1 つのアカウントにスマート カードでサインインする

ユーザーのグループは、1 つのアカウント (管理者アカウントなど) にサインインできます。 そのアカウントでは、ユーザー証明書がマップされ、サインインが有効になります。

複数の個別の証明書を 1 つのアカウントにマップできます。 これを適切に機能させるには、証明書に UPN を含めることはできません。

たとえば、Certificate1 に CN=CNName1 があり、Certificate2 に CN=User1 があり、Certificate3 に CN=User2 がある場合、これらの証明書の AltSecID は Active Directory ユーザーとコンピューターの名前マッピングを使用して 1 つのアカウントにマップできます。

フォレスト間でのスマート カード サインイン

アカウント マッピングをフォレスト間で機能させるには、特に証明書に十分な情報がない場合、ユーザーは 、domain\user などのユーザー名、または user@contoso.com などの完全修飾 UPN の形式でヒントを入力する場合があります。

注

スマート カードのサインイン中にヒント フィールドを表示するには、クライアントで [ユーザー名ヒントの許可 ] グループ ポリシー設定 (X509HintsNeededed レジストリ キー) を有効にする必要があります。

PKINIT の OCSP サポート

RFC 2560 で定義されているオンライン証明書状態プロトコル (OCSP) を使用すると、アプリケーションは証明書の失効状態に関するタイムリーな情報を取得できます。 OCSP 応答は小さく、適切にバインドされているため、制約付きクライアントは OCSP を使用して KDC 上の Kerberos の証明書の有効性を確認し、大きな CRL の送信を回避し、制約付きネットワークの帯域幅を節約したい場合があります。 CRL レジストリ キーの詳細については、「 スマート カード グループ ポリシーとレジストリ設定」を参照してください。

Windows の KDC は、OCSP 応答を取得し、使用可能な場合はそれらを使用しようとします。 この動作を無効にすることはできません。 OCSP の CryptoAPI は、OCSP 応答と応答の状態をキャッシュします。 KDC では、署名者証明書の OCSP 応答のみがサポートされます。

Windows クライアント コンピューターは、OCSP 応答を要求し、使用可能なときに応答で使用しようとします。 この動作を無効にすることはできません。

ドメイン サインインで使用するスマート カード ルート証明書の要件

スマート カード ベースのドメインでサインインを機能させるには、スマート カード証明書が次の条件を満たしている必要があります。

• スマート カードの KDC ルート証明書には、証明書に HTTP CRL 配布ポイントが一覧表示されている必要があります
• スマート カードサインイン証明書には、証明書に HTTP CRL 配布ポイントが一覧表示されている必要があります
• CRL 配布ポイントが空の場合でも、CRL 配布ポイントには有効な CRL が発行され、該当する場合はデルタ CRL が必要です
• スマート カード証明書には、次のいずれかが含まれている必要があります。
  • 識別名に DNS ドメイン名を含むサブジェクト フィールド。 解決されない場合、適切なドメインへの解決が失敗するため、リモート デスクトップ サービスとスマート カードを使用したドメイン サインインは失敗します
  • ドメイン名が実際のドメインに解決される UPN。 たとえば、ドメイン名が Engineering.Corp.Contosoされている場合、UPN は username@engineering.corp.contoso.com。 ドメイン名の一部を省略すると、Kerberos クライアントは適切なドメインを見つけることができません

これらのバージョンのドメインへのスマート カード サインインを許可するには、次の操作を行います。

1. CA で HTTP CRL 配布ポイントを有効にする
2. CA を再起動する
3. KDC 証明書を再発行する
4. スマート カードサインイン証明書を発行または再発行する
5. 更新されたルート証明書を、ドメイン サインインに使用するスマート カードに反映する

回避策は、[ ユーザー名ヒントの許可 ] グループ ポリシー設定 (X509HintsNeeded レジストリ キー) を有効にすることです。これにより、ユーザーはドメイン サインイン用の資格情報ユーザー インターフェイスにヒントを指定できます。

クライアント コンピューターがドメインに参加していない場合、または別のドメインに参加している場合、クライアント コンピューターは、UPN ではなく証明書の識別名を調べることによってのみ、サーバー ドメインを解決できます。 このシナリオを機能させるには、ドメイン名解決のために、証明書に DC=<DomainControllerName>を含む完全なサブジェクトが必要です。

現在参加しているドメインのスマート カードにルート証明書を展開するには、次のコマンドを使用します。

certutil.exe -scroots update

コマンド ライン ツールのこのオプションの詳細については、「 -SCRoots」を参照してください。