「Microsoft Entra ID（旧Azure AD）のユーザーに証明書ベース認証を有効にしたのに、ユーザー詳細の『認証方法の追加』から証明書が登録できない…証明書はどこにアップロードするの？」という疑問は、CBAを初めて触るときに多くの管理者がぶつかるポイントです。本記事では、結論である「ユーザー証明書はポータルにアップロードしない」という設計思想から、Entra CBAの仕組み、正しい構成手順、そしてトラブルシューティングの勘所まで、実運用レベルで詳しく解説します。
Entra CBAではユーザー証明書の「アップロード」は存在しない
まず最初に結論です。
Microsoft Entra IDの証明書ベース認証（CBA）では、「ユーザー証明書そのものをポータルにアップロードして登録する」操作は存在しません。
Entra ID（旧Azure AD）は、クラウドベースのID／アクセス管理サービスで、パスワード、多要素認証（MFA）、スマートカード、証明書ベース認証など複数の認証方式を提供しています。
そのうち証明書ベース認証（CBA）は、ユーザーがサインイン時にブラウザーやクライアントアプリから提示する X.509 クライアント証明書 を、Entra ID がその場で検証し、ユーザーオブジェクトに動的に照合（バインド）する方式です。
したがって、パスワードレス電話サインインやFIDO2キーのように「ユーザーがポータルで事前登録する」タイプの認証方法とは異なり、事前に“ユーザー証明書をEntraに登録する”ステップがないのが仕様です。
「認証方法の追加」に証明書が表示されないのは仕様
Microsoft Q&Aでも、まさに本記事と同じ質問が寄せられています。
- グループに対してCBAを有効化済み
- ユーザー詳細の「認証方法の追加」を開いても「証明書」が表示されない
これに対するMicrosoft側の回答は要約すると次のとおりです。
- 「認証方法の追加」メニューには、ポータルから手動登録できる認証方法だけが表示される。
- CBAはその対象ではない（設計上の仕様）。
- 代わりに、サインイン時に提示された証明書を、Entra ID が設定済みのバインディングルールにもとづいて検証・照合する。
つまり、「証明書が出てこない＝構成ミス」ではなく「仕様どおり」です。
| ポータルから登録する認証方法 | ポータルからは登録しない認証方法 |
|---|---|
| メール、電話番号、Microsoft Authenticator、FIDO2 セキュリティキー、TAP（Temporary Access Pass）など | 証明書ベース認証（CBA）、Windows Hello for Business、ID プロバイダー連携など |
| ユーザーが「認証方法の追加」から自分で登録 | テナント／ポリシー側で構成され、サインイン時に自動的に利用 |
では、CBAを使うために何を「アップロード」するのかというと、ユーザー証明書ではなく「証明機関（CA）証明書」です。ここをしっかり理解すると、CBA構成の全体像がスッキリ整理できます。
Microsoft Entra CBAのざっくりした仕組み
Microsoft公式ドキュメントでは、Entra CBAを次のような位置づけで説明しています。
- 組織のPKIが発行した X.509 クライアント証明書 を使って、Entra ID に直接サインインできる。
- 従来のAD FSベースのフェデレーションCBAを置き換え、構成をシンプルにできる。
- フィッシング耐性を持つモダン認証・パスワードレス認証の一形態として利用できる。
サインインフローの要点を、極力シンプルに書くと次のようになります。
- ユーザーが MyApps ポータルや Office アプリなどからアクセス。
- Entra サインインページで UPN（ユーザー名） を入力。
- テナントにCBAが構成されていれば、「証明書またはスマートカードでサインイン」リンクが表示される。
- ユーザーが証明書サインインを選択すると、ブラウザーやOSがローカルの証明書ストア／スマートカードから証明書を提示。
- Entra IDは、事前に登録されたCAチェーンで証明書を検証し、バインディングルールにもとづいてユーザーオブジェクトを検索。
- 一致が取れ、有効な証明書であればサインインが成功。認証強度（シングル／マルチファクタ）もここで判定される。
この流れからもわかるとおり、証明書は常に“クライアント側に存在”し、Entra側は「どのCAを信頼するか」「どのようにユーザーと紐づけるか」を定義するだけです。
CBA構成の3つの責務
Entra CBAを設計するときは、次の3つの責務に分けて整理すると理解しやすくなります。
| 担当 | 責務 | 代表的な設定内容 |
|---|---|---|
| Entra テナント管理者 | どのCAを信頼するか / どのユーザーをCBA対象にするか | CAチェーンの登録、CBAポリシー（対象グループ・認証強度・バインディング） |
| PKI 管理者 | どんな証明書をユーザーに発行するか | 証明書テンプレート、EKU（Client Authentication）、Subject/SANに入れるUPN/メール など |
| デバイス／クライアント管理者 | 証明書をどの端末に、どのストアに配布するか | Intune等のMDMでPFX/SCEP配布、スマートカード/YubiKeyへの格納、失効時の回収 |
以下では、この3つの観点に沿って、実際の構成手順を詳しく見ていきます。
テナント側の構成ステップ：Entra 管理センターで行うこと
ステップ1：CBAを有効化し、対象ユーザー／グループを決める
まずはテナントでCBA機能自体をオンにします。公式ドキュメントでは次のような手順が案内されています。
- 少なくとも Authentication Policy Administrator 以上のロールを持つアカウントで Entra 管理センターにサインイン。
- Entra ID > Authentication methods > Certificate-based authentication を開く。
- Enable and Target で CBA を 有効化（Enable）。
- 対象として All users ではなく、必ず CBA 用のセキュリティグループを選択。
Microsoftは「CBAを使えるユーザーには、既に有効な証明書があることを確認した上で範囲指定を行うこと」を強く推奨しており、誤って全ユーザーにCBAを必須化すると、証明書を持たないユーザーがMFA登録すらできなくなると警告しています。
ステップ2：信頼する証明機関（CAチェーン）の登録
次に、どのCAが発行したユーザー証明書を信頼するかをEntra側に教えます。ここで初めて「証明書のアップロード」という操作が登場しますが、アップロードするのはユーザー証明書ではなく、ルート／中間CA証明書です。
現在のEntraでは、PKIベースのCAトラストストアが提供されており、テナントごとにPKIコンテナーを作成して、その中にCA証明書をまとめて管理できます。
- Entra ID > Identity Secure Score > Certificate authorities を開く。
- 必要に応じてPKIコンテナーを作成。
- Upload または Add certificate authority を選択し、CAの公開証明書（.cerや.p7bなど）をアップロード。
- そのCAがルートか中間かを指定し、インターネットから到達可能な CRL（証明書失効リスト）のURL を入力。
- 必要に応じてDelta CRLのURLも設定し、保存。
重要なポイントは次の2つです。
- Entra CBAはHTTPのCRL Distribution Pointのみをサポートし、OCSPやLDAPベースの失効確認はサポートしない。
- 失効情報のURLを設定しない場合、失効した証明書でも認証がブロックされないため、セキュリティリスクとなる。
本番環境で使う場合は、PKI側でCRLをインターネット経由で参照できるよう公開し、URLをEntra側に正しく登録することが必須です。
ステップ3：ユーザー照合（バインディング）ルールの設定
続いて、提示された証明書のどのフィールドを、Entraユーザーのどの属性にマッピングするかを定義します。これがいわゆる「Username binding policy」です。
既定では、証明書の Subject Alternative Name(SAN) 内の Principal Name を、ユーザーオブジェクトの userPrincipalName と照合します。
しかし、ハイブリッド環境や複雑なUPN設計ではこれだけでは足りないため、CBAでは次のような複数のバインディングがサポートされています。
| 証明書フィールド | 対応するユーザー属性 | よく使われる用途 |
|---|---|---|
| SAN.PrincipalName / SAN.RFC822Name | userPrincipalName / onPremisesUserPrincipalName | 一般的なUPNやメールアドレスバインディング |
| IssuerAndSubject / IssuerAndSerialNumber | certificateUserIds | 異なる名前空間・複数UPNを扱う複雑な環境 |
| Subject、SubjectKeyIdentifier など | certificateUserIds | 政府系・高セキュリティ環境でのカスタムマッピング |
クラウド専用ユーザーの場合は Entra 管理センターやGraph APIから certificateUserIds 属性を直接更新し、オンプレミス連携ユーザーの場合は Entra Connect の同期ルールを使って on-prem から値を同期する設計が推奨されています。
ステップ4：認証強度（シングル／マルチファクタ）の定義
CBAでは、「どの証明書ならシングルファクタ認証として扱い、どの証明書なら多要素認証（MFA）を満たす強度とみなすか」を、証明書のIssuerやPolicy OIDなどに基づいて柔軟に定義できます。
- Issuer Subject や Policy OID をキーにルールを作成
- Protection Level を Single-factor / Multi-factor から選択
- Conditional Access の 認証強度 と組み合わせて、「Office 365 にはCBAによるMFAのみ許可」といったポリシーを構成
例えば、「社内の高セキュリティCAが発行した証明書のみMFAとして扱い、それ以外のCA発行証明書はシングルファクタ扱い」というポリシーも実現可能です。
クライアント／ユーザー側の準備：証明書をどこに置くのか
ユーザー証明書の発行と要件
CBA用ユーザー証明書自体は、組織のPKIや公開CAで発行します。Microsoft自身はPKI自体の提供は行っておらず、CBAの公式ドキュメントでも「PKIは自前で用意し、ユーザー／デバイスに証明書を配布する必要がある」と明記されています。
典型的な要件の例は次のとおりです。
- EKU（拡張キー使用目的）：Client Authentication（OID: 1.3.6.1.5.5.7.3.2）
- Key Usage：Digital Signature（署名）を含む
- Subject / SAN：EntraユーザーのUPNまたはメールアドレスを格納
- 秘密鍵付きかつエクスポート不可（必要に応じて）
証明書テンプレートで上記を満たすよう設計しておけば、CBA側のバインディングと素直にマッチさせやすくなります。
証明書の配布と保存場所
配布方式としては、次のパターンがよく使われます。
- Windows / macOS / iOS / Android にユーザー個人証明書としてインストール
- スマートカードやYubiKeyのような外部トークンに格納し、PCに挿して使用
- 企業環境では Intune などのMDMでPFX配布やSCEP/PKCSプロファイルを使い、自動配布・ローテーション
ここでの注意点は、ユーザー証明書が「ユーザー個人ストア」に、秘密鍵付きで存在することです。マシンストアに入っていたり、秘密鍵なし（公開鍵のみ）で配布していると、証明書選択画面に出てこなかったり、サインインに失敗したりします。
サインイン時のユーザー体験
CBAがテナントに有効化されていると、ユーザーのサインイン画面には次のような流れが追加されます。
- ユーザーが UPN（例：[email protected]） を入力して「次へ」。
- パスワード入力画面に 「証明書またはスマートカードでサインイン」 リンクが表示される。
- リンクを選択すると、ブラウザー／OSの証明書選択UIが表示され、対象のユーザー証明書を選ぶ。
- 選択した証明書が有効で、CAチェーンおよびバインディング条件を満たしていればサインイン成功。
公式ドキュメントによると、CBAがテナントで有効化されている場合、リンク自体は全ユーザーに表示されるが、実際に認証に成功するのはCBAポリシーの対象ユーザーだけとされています。
繰り返しになりますが、ここでもユーザーが事前にポータルで証明書を登録するステップは存在しません。
「認証方法の追加」に証明書が出てこない理由を整理する
ここまでを踏まえて、改めて「認証方法の追加」に証明書が出てこない理由をまとめておきます。
- 「認証方法の追加」画面は、ユーザー自身がポータル上で登録／管理する認証手段のみを扱う。
- CBAは、サインイン時に提示されたクライアント証明書を基にEntraが自動判定する仕組みであり、「ユーザーによる事前登録」という概念がない。
- そのため、証明書は最初から候補に出てこないのが正しい動作である。
もし社内で「証明書の登録画面が出ないからCBAが壊れているのでは？」という声が出てきたら、本記事のポイントを共有しておくと理解が進みます。
よくあるハマりどころとチェックリスト
症状別のありがちな原因
| 症状 | よくある原因 | 確認ポイント |
|---|---|---|
| サインイン画面に「証明書でサインイン」が表示されない | CBA自体がテナントで無効、または対象グループにユーザーが含まれていない | CBAポリシーの「Enable and Target」とグループ構成を再確認 |
| 証明書選択は出るが、認証が失敗する | CAチェーン未登録／不完全、証明書のSAN/UPN不一致、証明書の失効・期限切れなど | ユーザー証明書の「証明のパス」で全てのCAがEntraに登録済みか、SANの値がUPNと一致しているか |
| 特定の端末だけCBAが使えない | 証明書がマシンストアにある、秘密鍵なし、ブラウザーの制限、MDMプロファイルの配布漏れ | ユーザー個人ストアの内容、証明書のキー情報、MDMポリシー、ブラウザーのTLSクライアント証明書設定 |
| 一部ユーザーの証明書だけMFA扱いにならない | Authentication bindingルールと証明書のIssuer/Policy OIDの値が一致していない | 証明書の詳細タブでIssuer/Policy OIDを確認し、CBA設定画面のルールと突き合わせる |
| CAアップロードがエラーになる | 既存のCAに期限切れが含まれている、CRL URLが無効、PKIファイルサイズ超過など | 古いCAの期限を確認し削除、CRL URLへHTTPアクセスできるか確認、PKIファイルのサイズとCA数を確認 |
Entra公式ドキュメントには、CBAのサインインログに「PKIベースストアを使ったか／従来ストアを使ったか」を示すフラグが記録されることも説明されています。トラストストア周りのトラブルシュートではサインインログの Additional Details を確認すると原因特定に役立ちます。
最低限のチェックリスト
- [ ] CBAを対象グループに有効化しているか（All users は避ける）
- [ ] ルート／中間CAをすべてEntraのトラストストアに登録したか
- [ ] CRLのHTTP URLが正しく登録され、インターネットから到達可能か
- [ ] バインディング条件（UPN／メール／IssuerAndSerialNumber 等）が証明書の内容と一致しているか
- [ ] ユーザー証明書に Client Authentication EKU と適切なKey Usageが含まれているか
- [ ] 証明書がユーザー個人ストアに秘密鍵付きで格納されているか
- [ ] サインインログに Certificate-based Authentication として記録されているか
ロールと権限：誰が何を触るべきか
CBA関連の設定は、誤ると広範囲に影響するため、ロールと権限を最小限に絞ることが重要です。Microsoftは公式ドキュメントで、Global Administrator の常用を避け、専用ロールを使うことを推奨しています。
| ロール | 主な用途 | 備考 |
|---|---|---|
| Global Administrator | 初期構成、CAトラストストアの準備など | 常用は避け、緊急時や設計初期に限定することが推奨 |
| Privileged Authentication Administrator | PKIベーストラストストアの詳細操作 | PKIコンテナーの作成・編集、CAアップロードなどを担当 |
| Authentication Policy Administrator | CBAポリシー（対象ユーザー／認証強度／バインディング）の設定 | ユーザー関連の認証ポリシーを管理するロール |
| Security Administrator / Security Reader | サインインログや監査ログの確認 | 運用監視やセキュリティレビューで利用 |
これらのロールを組み合わせて、「PKI管理チーム」「ID管理チーム」「セキュリティ監視チーム」といった役割に割り当てると、ガバナンスの効いたCBA運用がしやすくなります。
証明書の種類・発行元の選び方
先ほどのMicrosoft Q&Aでも触れられているように、ユーザー証明書の発行元としては次のような選択肢があります。
- 公開CA：DigiCert、Entrust、GlobalSign、Sectigo、GoDaddy など
- 社内CA：Windows Server AD CS などで自前のPKIを構築
- 自己署名証明書：検証・小規模用途なら可だが、本番環境では非推奨
公開CAを使う場合、証明書コストはかかりますが、CRL公開や信頼の連鎖などをCA側に任せられるメリットがあります。一方、社内CA（AD CS）は柔軟なテンプレート設計や自動発行が可能で、ハイブリッド環境との親和性も高いです。
自己署名証明書は、検証環境やPoCで「ひとまずCBAを試してみる」用途であれば便利ですが、以下の点をクリアできないなら本番での利用は避けるべきです。
- CA証明書チェーンをEntraに全て登録できること
- CRLをインターネット経由で参照できるよう公開できること
- 鍵保護や運用プロセスを含めて、インシデント発生時に迅速に失効・再発行できる体制があること
ケーススタディ：VPNとEntra CBAを同じ証明書で統合する
最後に、運用でよくあるシナリオを一つ紹介します。
シナリオ：「既存で社内VPNにクライアント証明書を使っている。これをそのままEntra CBAでも使い、VPNとMicrosoft 365のサインインを同じ証明書で統合したい。」
この場合、次の観点を押さえておくとスムーズです。
- 既存証明書テンプレートに Client Authentication EKU が含まれているか確認。
- SANの Principal Name / RFC822Name に、EntraユーザーのUPNまたはメールアドレスを入れるようテンプレートを拡張。
- VPN側は引き続きSubject CNや別フィールドでユーザー識別してもよいが、Entra CBA側のバインディングポリシーと矛盾しないように注意。
- CAチェーンをEntraに登録し、CRL URLも設定。
- テストユーザーでVPN＋Entra双方のサインインフローを検証し、サインインログでCBAとして認識されているか確認。
うまく設計すれば、ユーザーは1枚のスマートカード（または1つの証明書）でVPNとMicrosoft 365の両方にアクセスでき、パスワードレスでの業務が実現できます。
まとめ：ユーザー証明書を「アップロードしたくなったら」思い出す3ポイント
ここまでの内容を、最後に3つのポイントに凝縮します。
- ユーザー証明書はEntraポータルにアップロードしない。
CBAはサインイン時にクライアントが提示する証明書をその場で検証・照合する仕組みであり、「認証方法の追加」に証明書が出てこないのは仕様です。 - ポータルでアップロードするのは、あくまでCA証明書。
Entra側では、どのCAチェーンを信頼し、どの証明書をシングル／マルチファクタとして扱うかを定義します。ユーザー証明書を直接管理するのではなく、PKIとバインディングルールを通じて間接的に管理します。 - ユーザー証明書は端末またはスマートカードに存在し、そこで守る。
証明書の発行・保管・失効はPKIと端末管理の領域です。Intune等のMDMやスマートカード管理と組み合わせて「誰がどのデバイスでどの証明書を使うか」をコントロールし、Entra CBAはその上に乗る認証レイヤーと捉えると全体像が掴みやすくなります。
この3つを押さえておけば、「どこに証明書をアップロードするのか？」というモヤモヤから解放され、Entra CBAを自信を持って設計・運用できるはずです。社内のゼロトラストやパスワードレス推進の一手として、証明書ベース認証をぜひ有効活用していきましょう。
コメント