はじめに

本記事では、Microsoft Entra Certificate-Based Authentication ( CBA ) を利用し、Azure Portal での証明書認証を構成します。 従来のパスワード認証に加えて、クライアント証明書を利用した認証環境の構築を目的としています。 具体的には、認証局 ( CA ) の設定と Entra ID P1 ライセンスを活用し、Azure 上で証明書認証を設定します。
Entra ID P1 ライセンスは、Azure への認証局の登録や、クライアント証明書を利用した条件付きアクセスの適用に必要です。 これまで証明書認証の動作は ADFS 環境で検証していましたが、Azure のみで構成する CBA ではどのように動作するのかを確認したいと考えました。 特に、クライアント証明書の持ち主が正しく識別されるかどうかや、条件付きアクセスの適用を確認しました。

検証目的

• 認証局 ( 今回は OpenSSL を使用 ) と Entra ID P1 ライセンスを準備し、Azure に証明書認証の環境を構築すること
• クライアント証明書を用いた Microsoft クラウドポータルへのアクセス制御を実施すること
• 有効期限切れや、証明書と異なるアカウントが使用された場合の認証動作を確認すること

1. 検証環境説明

以下に、検証環境の構成および実際に確認した内容を記載します。

1-1. 環境構成

• OpenSSL による CA、中間 CA の設定、クライアント証明書の発行
• Entra ID P1 ライセンスを持つ Azure 環境で CA を登録
• 条件付きアクセスを利用した証明書認証の構成

検証環境 略図

1-2. 検証ポイント

• クライアント証明書の有無によるアクセス可否の確認
• クライアント証明書の有効期限切れ時の影響
• サインインするアカウントと異なるクライアント証明書を提示した場合の挙動

異なるクライアント証明書によるアクセス例

2. 構築手順

構築および検証の手順は以下の通りです。

• OpenSSL による認証局および証明書の作成
• Azure への認証局の登録および認証設定
• 端末へのクライアント証明書のインポート
• 動作確認

ただし、本環境は検証目的であるため、OpenSSL を使用しています。実運用環境では信頼された CA による証明書を使用することを推奨します。 さらに、自己署名証明書はブラウザやシステムで信頼されない可能性があるためご注意ください。

2-1. OpenSSL による認証局、クライアント証明書の作成

OpenSSL について

本記事では、証明書の作成に Windows OS 環境用の OpenSSL ( バージョン 3.4.1 ) を使用し、PowerShell で実行しています。 OpenSSL はオープンソースの暗号ライブラリであり、バージョン 1.1.1 以降は Apache License 2.0 のもとで提供されています。 詳細なライセンス情報については、 OpenSSL 公式サイト をご確認ください。
※ 本記事で使用する OpenSSL のコマンドは、一般的な証明書作成の手順に基づいています。

2-1-1. ルート CA の作成

1. ルート CA の秘密鍵 [ rootCA.key ] を作成

openssl genrsa -out rootCA.key 4096

2. ルート CA の自己署名証明書 [ rootCA.cer ] を作成

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 -out rootCA.cer -subj "/C=JP/ST=Tokyo/O=Sbcs/CN=SbcsRootCA"

2-1-2. 中間 CA の作成

1. 中間 CA の秘密鍵 [ intermediateCA.key ] を作成

openssl genrsa -out intermediateCA.key 4096

2. 中間 CA の CSR ( 証明書署名リクエスト ) [ intermediateCA.csr ] を作成

openssl req -new -key intermediateCA.key -out intermediateCA.csr -subj "/C=JP/ST=Tokyo/O=Sbcs/CN=SbcsIntermediateCA"

3. 中間 CA の拡張設定ファイル [ intermediateCA_ext.cnf ] を作成

@"
basicConstraints=CA:TRUE
keyUsage=critical, digitalSignature, keyCertSign, cRLSign
"@ | Out-File -Encoding ascii intermediateCA_ext.cnf

4. 中間 CA [ intermediateCA.csr ] をルート CA [ rootCA.key ] で署名

openssl x509 -req -in intermediateCA.csr -CA rootCA.cer -CAkey rootCA.key -CAcreateserial -out intermediateCA.cer -days 1825 -sha256 -extfile intermediateCA_ext.cnf

2-1-3. クライアント証明書の作成

ここでは、user1@sbcs70.onmicrosoft.com アカウント用のクライアント証明書を作成しています。

1. クライアント証明書用の秘密鍵 [ client_user1.key ] を作成

openssl genrsa -out client_user1.key 2048

2. クライアント証明書の CSR ( 証明書署名リクエスト ) [ client_user1.csr ] を作成

openssl req -new -key client_user1.key -out client_user1.csr -subj "/C=JP/ST=Tokyo/O=Sbcs/CN=user1@sbcs70.onmicrosoft.com"

3. クライアント証明書の拡張設定ファイル [ clientuser1ext.cnf ] を作成

@"
subjectAltName=email:user1@sbcs70.onmicrosoft.com
extendedKeyUsage=clientAuth
"@ | Out-File -Encoding ascii client_user1_ext.cnf

4. クライアント証明書を中間 CA で署名

openssl x509 -req -in client_user1.csr -CA intermediateCA.cer -CAkey intermediateCA.key -CAcreateserial -out client_user1.crt -days 365 -sha256 -extfile client_user1_ext.cnf

5. クライアント証明書を PFX 形式に変換し、パスワード設定 ( インポート作業で用います )

# 証明書チェーン ( 中間 CA + ルート CA )  [ cert_chain.pem ] を作成 (Windows PowerShell)
Get-Content intermediateCA.cer, rootCA.cer | Set-Content cert_chain.pem
# インポート用のPFX を作成 (クライアント証明書 + 中間 CA + ルート CA を含む)
openssl pkcs12 -export -out client_user1.pfx -inkey client_user1.key -in client_user1.crt -certfile cert_chain.pem -password pass:xxxxxxxx

2-2. Azure に CA を登録と証明書認証設定

まずは、2-1 の手順で作成した CA を Azure Portal に登録します。続けて、証明書認証の設定を行います。 これにより、Azure Portal へのアクセスに証明書認証が追加されます。
さらに、条件付きアクセスの設定を追加します。 ここでは、他のMicrosoft のクラウドポータルへのアクセスにはクライアント証明書が必要となるように設定しました。

2-2-1. CA の登録

Azure Portal のメニューより
Microsoft Entra ID ＞ 管理 ＞ セキュリティ を選択し
セキュリティ ＞ 管理 の画面から、 [ 認証局 (クラシック) ] をクリック

1. [アップロード] をクリック

2. 「証明書ファイルのアップロード」で中間 CAファイルをアップロードし、[追加] をクリック

番号 項目 値 ① ルートCA証明書である いいえ ② 証明書失効リストのURL 空白 ③ デルタ証明書失効リストのURL 空白

2-2-2. 証明書認証の設定

Azure Portal のメニューより
Microsoft Entra ID ＞ 管理 ＞ セキュリティ を選択し
セキュリティ＞ 管理 の画面で、[ 認証方法 ] をクリック

1. [ 証明書ベースの認証 ] をクリック

2. [ 有効にする ] をオン 対象にするグループを選択し、[ 確認しました ]をクリック

番号 項目 値 ① 有効にする オン ② ターゲット グループの選択 ③ グループの追加 ( 対象グループ )

3. [ 構成 ] をクリック 各項目の設定後、[ 規則の追加 ] をクリック

番号 項目 値 ① CRL 検証を必須にする ( 推奨 ) チェックなし ② 発行者ヒント チェックあり ③ 保護レベル 多要素認証 ④ 必須のアフィニティバインド 低

4. 認証バインドポリシー規則の追加

番号 項目 値 ① 証明書の発行者 オン ② ポリシーOID オフ ③ PKI で CA をフィルター処理します 空白 ④ 証明書の発行者 ( クラシック ) 中間 CA を選択 ⑤ 認証強度 多要素認証 ⑥ アフィニティ バインド 低

2-2-3. 条件付きアクセスの構成

証明書認証のための条件付きアクセスの設定手順は、以下となります。
Azure Portal のメニューより
Microsoft Entra ID ＞ 管理 ＞ セキュリティ を選択し、
セキュリティ ＞ 保護 ＞ 条件付きアクセス の概要より

1. [ 新しいポリシーの作成 ] をクリック

最初に、ポリシー名を入力します。
この記事では 「 証明書認証ポリシー 」としています。

2. ポリシーの「 割り当て 」

番号 項目 値 ① 対象 ユーザーとグループの選択 ( 対象グループ ) ② ターゲットリソース すべてのリソース：( 以前の 'すべてのクラウド アプリ' )

3. ポリシーの「 アクセス制御 」の設定をし、[ 選択 ] をクリック

番号 項目 値 ① 許可 アクセス権の付与 ② 認証強度が必要 オン [ フィッシングに強いMFA ] を選択

4. [ ポリシーの有効化 ] を [ オン ] にして、 [ 作成 ] をクリック

2-3. 端末へクライアント証明書のインポート

2-1 で作成したクライアント証明書のインポートファイル ( PFX ) を、端末上でクリックします。
以下のような画面遷移で、ウィザードにしたがって進めて下さい。
なお、秘密キーのパスワードはクライアント証明書に設定したパスワードを入力して下さい。

1. 既定値のまま、[ 次へ ]

2. 既定値のまま、[ 次へ ]

3. パスワードを入力し、[ 次へ ]

4. 既定値のまま、[ 次へ ]

5. 画面を確認し、[ 次へ ]

6. 初回のインポート時に表示されます。 [ はい ] をクリック

7. インポートの最後に「 正しくインポートされました。 」と表示されますので、[ はい ] をクリックして下さい。
   

2-4. 認証動作の確認方法

端末から Microsoft 365 ポータル ( https://www.office.com ) にサインインを試み、正常にアクセスできるかを確認しました。

3. 動作検証 ( 検証パターン )

3-1. 正常系

• クライアント証明書を適切に登録した場合のサインイン画面遷移

1. サインイン画面

2. パスワード入力画面

3. 証明書の選択画面

4. サインイン成功 ポータル画面表示

3-2. 異常系

サインインとパスワード画面は、3-1. 正常系と同じなので略します。

3-2-1. クライアント証明書がない場合

1. パスワード入力後、 サインイン失敗した画面

2. 詳細の画面 [ Message : AADSTS50192 : invaild request. ]

3-2-2. 証明書の有効期限切れ時の場合

1. パスワード入力後、 サインインに失敗した画面

2. 詳細の画面 [ Message : AADSTS50192 : invaild request. ]

3-2-3. 異なるクライアント証明書の場合

1. パスワード入力後、 クライアント証明書の選択画面

2. サインインに失敗した画面

3. 詳細の画面 [ Message : AADSTS1001009 : No value in the certificate , as requested by tenant policy , is able to vaildate the user claim ]

4. 検証から気づき

今回の検証では、Microsoft Entra CBA を用いて、クライアント証明書を利用した認証の実現性を検証しました。 適切に条件付きアクセスを設定することで、証明書を持つ特定のユーザーのみにアクセスを制限できることも確認しています。 検証のほとんどは想定通りに進みましたが、いくつかの課題もありました。

• CA のみではなく中間 CA も必要

OpenSSL で作成した CA については、最初の設定では期待した動作をしませんでした。 当初は OpenSSL 自体の問題かと思いましたが、実際には中間 CA を設定することで解決しました。 この対応により、結果的に 記事的には OpenSSL のコマンドの紹介部分が長くなってしまいました。

• 証明書認証におけるサインインエラーの解決方法

条件付きアクセスの設定時には、「 認証強度が必要 - フィッシングに強い MFA: ユーザーは、1 つ以上の MFA チャレンジを完了することで、この認証強度を満たす可能性があります。 」というサインインログのメッセージが出て、サインインが失敗しました。 この問題は、[ 認証バインドポリシー規則 ] を追加し、登録したCAの認証強度を「 多要素認証 」に設定することで解決しました。

• その他の気づき

証明書がない場合や有効期限が切れた場合、同じ認証失敗画面が表示されるため、状況の判断が難しいと感じました。 その際、複数のクライアント証明書がインポートされている端末ではすぐにエラーが表示されず、使用する証明書を選択する画面が表示されたことも付け加えておきます。

5. まとめ

Microsoft Entra CBA を活用することで、クライアント証明書を利用した認証が可能になります。 中間認証局の設定や認証強度の適切な設定により、セキュアな認証環境を実現できました。 今回の検証記事が、同様の構成を検討する際の参考になれば幸いです。