Microsoft ドキュメントに登場する「root certification of the domain controller」は、スマートカード ログオンの構成で誤解されやすい表現です。この記事では“結局どの証明書（CA）を指すのか”を整理し、AD CS 環境で対象を特定して安全にエクスポートし、ドメイン非参加（ワークグループ）端末でもつまずかない配布・検証まで具体的に解説します。
「root certification of the domain controller」とは何か（結論）
結論から言うと、多くの環境で Microsoft ドキュメントの root certification of the domain controller は、表現の揺れ（言い回しの曖昧さ）であり、実体としては次を指すのが自然です。
- ドメイン コントローラー（KDC）が使用する Kerberos / PKINIT 用の証明書を信頼するための、発行元 CA の「ルート CA 証明書」（必要に応じて中間 CA 証明書も含む）
ポイントは「DC 自身の“ルート証明書”」ではなく、DC が提示する認証用証明書の“発行元（CA）のルート”だという捉え方です。テスト環境が「DC 1台＋別途 エンタープライズ CA（AD CS）」であれば、たいていこの“社内 CA のルート（＋中間）”が該当します。
なぜドメイン非参加端末で問題になりやすいのか
ドメイン参加端末であれば、社内 CA（AD CS）のルート証明書は GPO や AD 連携で自動的に信頼ストアへ配布されることが多く、意識しなくても証明書チェーンの検証が通ります。
一方、ドメイン非参加（ワークグループ）端末は、通常次の状態です。
- 社内 CA の ルート CA 証明書／中間 CA 証明書を信頼ストアに持っていない
- そのため、DC とクライアント間で必要になる 証明書の検証（チェーン検証）が成立しない
結果として、スマートカードを使ったサインイン（特に Kerberos の PKINIT を使うパターン）で、「DC が提示した証明書を信頼できない」という理由で失敗します。そこで、信頼の起点（ルート CA）を“端末側に持たせる”必要が出てきます。
最初に整理したい「2つの証明書チェーン」
スマートカード ログオンの構成で混乱しがちなのは、「どの証明書の“ルート”が必要なのか」が状況で変わることです。実務上は、次の2系統を切り分けると判断が一気に楽になります。
| チェーン | 誰が検証するか | 何のために必要か | 非ドメイン参加端末で起きやすい問題 |
|---|---|---|---|
| ユーザー証明書（スマートカード上）のチェーン （ユーザー証明書 → 中間 CA → ルート CA） | 主に ドメイン コントローラー（KDC） | ユーザーが提示する証明書が「正当な CA によって発行された本人の証明書」か確認する | 端末側よりも DC 側の設定（NTAuth など）で詰まることがある |
| DC（KDC）が使う証明書のチェーン （DC 証明書 → 中間 CA → ルート CA） | 主に クライアント（ログオンする端末） | クライアントが「接続先の DC が本物か」や、PKINIT の相互認証で必要な検証を行う | クライアントが社内 CA を信頼しておらず検証に失敗しやすい（今回の主題） |
今回の「root certification of the domain controller」は、文脈的にほぼ確実に 下段（DC/KDC 証明書のチェーンのルート）を指します。ただし環境によっては、スマートカード上のユーザー証明書チェーンも同時に問題になることがあるため、後述の方法で “実際に使われている証明書”からルートを特定するのが確実です。
「どの CA が正しいか」を迷わず特定する方法
結局のところ、必要なものは「DC が実際に使っている認証用証明書の発行元 CA（ルート/中間）」です。最短で確実なのは、DC にある該当証明書の“証明のパス”を見て、ルート/中間 CA を特定する方法です。
チェック対象：DC（KDC）側の証明書
DC 上には、Kerberos（PKINIT）や DC 認証に使われる証明書が入ります。テンプレート名は環境で異なりますが、概ね次のような名前・用途が目印です。
- Kerberos Authentication
- Domain Controller Authentication
- （環境によって）Domain Controller
より確実なのは、証明書の「拡張キー使用法（EKU）」に KDC Authentication（Kerberos 用）などが含まれるものを確認することです。
証明のパスから“ルート/中間 CA”を拾う
DC の該当証明書を開いて ［証明のパス］タブを見ると、
- 最上段：ルート CA
- 途中：中間 CA（存在する場合）
- 最下段：DC（KDC）が使う証明書
の順で表示されます。ここに出てきた ルート CA（＋中間 CA）こそが、エクスポートして配布すべき対象です。
エクスポート前に理解しておくべき注意点
- 秘密鍵は絶対にエクスポートしません。必要なのは CA の公開証明書（.cer）です。
- 中間 CA がある場合、ルート CA だけではチェーン構築ができず失敗することがあるため、中間 CA 証明書もセットで用意します。
- 「社内 CA が複数ある」「更新（ロールオーバー）した」環境では、似た名前の CA が並ぶことがあります。必ず“証明のパス”で一致を取ってください。
エクスポート手順（代表例）：DC から certlm.msc で取り出す
ユーザーのテスト環境（DC 1台＋別途 Enterprise CA）でも、まずは DC から取り出す手順が一番シンプルです。
手順
- DC にドメイン管理者でログオン
- certlm.msc（ローカル コンピューターの証明書）を開く
- まず DC が使う証明書を確認
- ［個人］→［証明書］ を開く
- 「用途」や「発行先」「拡張キー使用法（EKU）」から、Kerberos/Domain Controller 系の証明書を特定
- 証明書を開き、［証明のパス］でルート/中間 CA を確認
- ルート CA 証明書をエクスポート
- ［信頼されたルート証明機関］→［証明書］ を開く
- 証明のパスで特定した ルート CA を探す
- 右クリック → ［すべてのタスク］→［エクスポート］
- 秘密鍵はエクスポートしない を選択
- 形式は基本 X.509 (.CER)（Base-64 か DER は運用ツールに合わせる）
- 中間 CA がある場合は 中間 CA 証明書もエクスポート
- ［中間証明機関］→［証明書］ を開く
- 証明のパスで特定した中間 CA を同様にエクスポート
エクスポートする対象の早見表
| 何をエクスポート？ | DC 上の場所 | 出力形式 | 重要ポイント |
|---|---|---|---|
| ルート CA 証明書 | 信頼されたルート証明機関 → 証明書 | .cer（公開鍵のみ） | 秘密鍵は不要・危険。公開証明書のみでOK |
| 中間 CA 証明書（ある場合） | 中間証明機関 → 証明書 | .cer（公開鍵のみ） | 中間が欠けるとチェーン構築に失敗しがち |
別解：AD CS（CA サーバー）から取り出す方法
DC から取り出すのが簡単ですが、運用面では「CA サーバーから正規の CA 証明書を取り出して配布する」方が管理しやすい場合もあります。
GUI（certsrv.msc）で CA 証明書をエクスポート
- CA サーバーにログオンし、Certification Authority（certsrv.msc）を開く
- CA 名を右クリック → ［プロパティ］
- ［全般］タブから CA 証明書を表示し、［詳細］（または「証明書の表示」）からエクスポート
コマンド（certutil）で CA 証明書を出力
環境によりコマンドは多少差がありますが、代表的には次のような形で CA 証明書をファイル化できます。
certutil -ca.cert RootCA.cer中間 CA（発行 CA）が別にある構成では、各 CA で同様に出力し、最終的にクライアント側に ルート＋中間を揃えるのが基本です。
入れる先はどこ？「スマートカード」vs「非ドメイン参加 PC」
ここが実務で最も分岐します。Microsoft ドキュメントが「スマートカードに root certification が必要」と書いていても、現場では次の2パターンがあり得ます。
| やり方 | 具体的な入れ先 | メリット | 注意点 |
|---|---|---|---|
| A：PC に CA ルート（＋中間）を入れる | 非ドメイン参加 PC の ローカル コンピューター → 信頼されたルート証明機関 / 中間証明機関 | Windows の証明書検証が最も素直に通る。 トラブルシュートが簡単。 | 端末側の管理が必要（配布方法・ポリシーに左右される） |
| B：スマートカード側に CA 証明書を持たせる | スマートカードの管理ツールで ルート/CA 証明書（＋中間）を登録 | 「端末に何も入れたくない」運用と相性が良い。 カードを差し替えれば持ち運べる。 | カード/ミドルウェアの仕様に依存。 端末の信頼ストアに反映されないと意味がないケースがある。 |
実務的に安定するのは A（PC に入れる）です。B は「カード挿入時に証明書を端末へ展開する仕組みがある」「特定ミドルウェアがログオン前の検証で参照してくれる」などの条件が揃うと便利ですが、環境差が大きいのが難点です。
ただし、ユーザーの質問は「何をエクスポートすればよいか」なので、ここでは核心を明確にします。
- エクスポートすべきなのは DC（KDC）が使う証明書を発行した CA のルート証明書（＋必要なら中間）
- それを「PC に入れるか」「スマートカード側で担保するか」は運用判断（ただし A が堅い）
（推奨）非ドメイン参加 PC へインポートする手順
ドメイン非参加端末での成功率を上げたいなら、まずは 非ドメイン参加 PC のローカル コンピューター証明書ストアに入れて検証するのが近道です。
手順（GUI）
- 非ドメイン参加 PC に管理者でログオン
- certlm.msc を起動（ローカル コンピューター）
- 信頼されたルート証明機関 → 証明書 を右クリック → すべてのタスク → インポート
- DC からエクスポートした RootCA.cer をインポート
- 中間 CA がある場合は、中間証明機関 → 証明書 に IntermediateCA.cer をインポート
補足：どのストアに入れるべきか
| 証明書 | 入れるストア | 理由 |
|---|---|---|
| ルート CA | ローカル コンピューター → 信頼されたルート証明機関 | 信頼の起点にするため（ここにないと“未信頼ルート”になりやすい） |
| 中間 CA | ローカル コンピューター → 中間証明機関 | チェーン構築に必要（ルートだけでは途中が欠ける場合がある） |
（必要なら）スマートカードへインポートする考え方と手順
「端末に CA を入れられない」「持ち込み端末が多い」といった運用上の事情がある場合、スマートカード側に CA 証明書を格納して “信頼情報を携帯する” 設計が検討されます。
ただし、スマートカードの種類（PIV / CSP / minidriver）や管理ツールにより格納先・扱いが異なるため、ここでは 変わらない考え方と、一般的な操作の流れを示します。
- スマートカードに入れるのは ルート CA（＋中間 CA）証明書（公開鍵のみ）
- 目的は「ログオン時の証明書チェーン構築と検証を成立させる」こと
- ミドルウェアが カード内 CA 証明書を OS の検証で参照できる形にしているかが重要
一般的な流れ
- スマートカード管理ツール（ベンダー提供）を起動
- 「証明書の追加」「CA 証明書の登録」などのメニューから、RootCA.cer（＋IntermediateCA.cer）を登録
- 端末でスマートカードを挿し直し、証明書一覧に CA 証明書が見えるか確認
もし「カードには入ったがログオンが失敗する」場合は、端末側の信頼ストアにも結局は必要な構成になっている可能性があります。その場合は、A（端末のローカル コンピューターの信頼されたルート証明機関へインポート）に切り替えると原因切り分けが早くなります。
確実に成功させるための確認ポイント（検証チェックリスト）
“ルート CA を入れたはずなのに失敗する”ときは、証明書そのもの以外の要因が潜んでいることが多いです。次のチェックを上から潰すと、原因が見えやすくなります。
| チェック項目 | 見る場所 | OK の目安 | NG のときに起きること |
|---|---|---|---|
| DC（KDC）証明書の発行元 CA が一致しているか | DC の証明書 → 証明のパス | エクスポートした CA が最上段（ルート）にいる | そもそも違う CA を配っていて検証不能 |
| 中間 CA を入れ忘れていないか | 端末の中間証明機関ストア | 証明のパスがルートまで途切れない | チェーン構築失敗（“途中が見つからない”系） |
| 失効確認（CRL）にアクセスできるか | 証明書の CDP/AIA | ログオン時に到達可能な URL/パスになっている | 失効チェック失敗で拒否される（環境/ポリシー次第） |
| 時刻同期（時計ズレ） | 端末・DC の時刻 | 数分以内に収まる | Kerberos/証明書の有効期間で弾かれる |
コマンドでの簡易確認（端末側）
インポートした CA 証明書が端末に入っているかは、次のコマンドで確認できます。
certutil -store -enterprise root
certutil -store root
certutil -store caドメイン非参加端末では “-enterprise” は意味が薄いことがあります。基本は certutil -store root（ルート）と certutil -store ca（中間）を確認してください。
よくある失敗パターンと対処法
「root certification of the domain controller を入れたのにダメ」という相談で多いのは、入れるべき対象がズレているか、失効確認やチェーン構築が阻害されているパターンです。
| 症状 | ありがちな原因 | 対処の方向性 |
|---|---|---|
| スマートカード ログオンが即失敗する（認証に進まない） | 端末が社内 CA を信頼していない / ルート CA を入れていない | 端末の「信頼されたルート証明機関」に ルート CA を入れる（最優先） |
| ルート CA は入れたが改善しない | 中間 CA が抜けていてチェーンが完成しない | 中間証明機関ストアへ 中間 CA もインポート |
| 環境によって成功したり失敗したりする | 失効確認（CRL）URL に端末が到達できない（ログオン前/VPN前など） | CRL 配布点を見直す、到達可能な経路を用意する、検証条件を整理する |
| テスト用 CA が複数あり、どれを入れたか分からない | CA 名が似ている / 更新で新旧 CA が混在 | DC の証明書で 証明のパスを見て、対象 CA を固定する |
| “DC の証明書”をエクスポートしてしまった | 「DC の証明書＝root certification」と誤解 | 必要なのは DC 証明書そのものではなく、それを発行した CA のルート（＋中間） |
「結局どれをエクスポート？」を一発で決める実務のコツ
最後に、現場で迷いを断ち切るためのコツをまとめます。
- “必要な CA”は、文章から推測しない：DC の該当証明書を開いて 証明のパスの最上段を見れば答えが出ます。
- ルート CA だけでなく、中間 CA の有無を必ず確認：中間がある構成（オフライン ルート＋発行 CA など）だと、ルートだけ配っても失敗しがちです。
- まずは端末のローカル コンピューターに入れて検証：成功したら“運用方針に合わせてスマートカード運用へ寄せる”のが安全です。
- 失効確認（CRL）まで含めて設計：証明書は「信頼」だけでなく「失効チェック」もセットです。特にログオン前のネットワーク到達性が盲点になります。
まとめ
「root certification of the domain controller」は、言葉としては分かりにくいものの、実務では次の一文に集約できます。
ドメイン非参加端末がスマートカードでドメインへサインインするには、DC（KDC）が提示する認証用証明書を“正しく信頼できる状態”にする必要があり、そのために発行元 CA のルート（＋必要なら中間）証明書をエクスポートして配布する。
テスト環境が「DC 1台＋別途 エンタープライズ CA（AD CS）」であれば、まずは DC 上で DC 証明書の 証明のパスを確認し、そこに出てくる ルート CA（＋中間）を 秘密鍵なしで .cer エクスポートして配布する、という流れが最短で確実です。
コメント