先月まで普通に開けていた Service Fabric Explorer（SFX）が、今月から突然「403: Client certificate required」で弾かれる――本番クラスターでこれが起きると非常に焦ります。本記事では、なぜ「設定を変えていない」のに 403 が出るのか、その裏で何が起きているのかを整理しつつ、原因の切り分けから一時復旧、正式対応、再発防止までを具体的な手順付きで解説します。
Service Fabric Explorer に「403: Client certificate required」が出るとき何が起きているか
まずは現象の意味を整理します。
ブラウザーで SFX の URL（例：https://<clusterFQDN>:19080/Explorer）にアクセスしたとき、以下のような画面・エラーが表示されるケースです。
- ブラウザーのタブに 403: Client certificate required と表示される
- 証明書選択ダイアログが表示されたが、選んでも 403 のまま
- 以前は普通に開けていたのに、ある日から突然 403 になった
HTTP 403 は「認証はされたが、アクセスは拒否された」という意味ですが、ここでのポイントは以下の 2 点です。
- SFX 側（クラスター管理エンドポイント）が「クライアント証明書（mTLS）必須」になっている
- もしくは、許可リストに登録されているクライアント証明書とブラウザーが提示する証明書が一致していない／期限切れ
特に Azure Service Fabric Managed Cluster（SFMC、管理クラスター）では、プラットフォーム側の更新やセキュリティ既定の強化に伴い、「以前は緩かった設定」がより厳格になることがあります。この結果、次のようなシナリオが発生しがちです。
- OS／Service Fabric ランタイムの更新で TLS 設定が強化された
- サーバー証明書のローテーションに伴い、クライアント証明書の検証条件も更新された
- アプリケーションゲートウェイやフロントエンドの構成変更で、mTLS が必須になった
つまり、「誰も故意に設定を変えていない」つもりでも、プラットフォーム更新や証明書ローテーションにより、結果としてクライアント証明書が必須化される／以前の証明書では通らなくなる、ということが十分あり得ます。
原因パターンをざっくり整理
よくある原因パターンを表で整理すると、次のようになります。
| 状況 | 典型的な原因 | よくあるきっかけ |
|---|---|---|
| SFX が急に 403 になる | クラスター側で「クライアント証明書必須」設定が有効化／強化された | プラットフォーム更新、セキュリティ既定の変更、フロントエンド（AppGW 等）の mTLS 有効化 |
| 一部の端末だけ 403 | その端末にインポートされているクライアント証明書が期限切れ、不足、拇印不一致 | 端末の更新、再イメージ、ユーザープロファイルの初期化、証明書の有効期限切れ |
| PowerShell からも接続できない | 許可リストに登録された証明書がすべて期限切れ／削除されている | 証明書ローテーション時に古い証明書を削除、Key Vault 側のみ更新しクライアント側を忘れる |
| 一部の経路だけ 403 | アプリケーションゲートウェイや WAF 経由の経路でのみ mTLS が必須になっている | トラフィック分割、ステージング→本番切替、WAF ポリシーの更新 |
| 特定の URL だけ 403 | パスごとに異なる認証ポリシーが設定されている | 管理 API と SFX のエンドポイントを分ける際にルール設定を誤った |
まずやるべき現状確認チェックリスト
焦って設定をいじる前に、次の 4 点を順番に確認することで、無駄な変更を避けつつ原因をかなり絞り込めます。
クラスターのクライアント証明書設定を確認
Azure Service Fabric Managed Cluster（SFMC）の場合は、Azure ポータルから以下を確認します。
- Service Fabric（管理クラスター） → セキュリティ → クライアント証明書
| 項目 | 確認内容 |
|---|---|
| 許可されている証明書の拇印 | 自分が持っているクライアント証明書の拇印と一致しているか |
| 有効期限 | 期限切れになっていないか、まもなく切れそうになっていないか |
| 権限（管理者／閲覧） | 自分が必要とする操作（システム操作 or 読み取りのみ）に対応した権限が付与されているか |
| 証明書の種別 | サブジェクト名／発行元（CA）が想定どおりか、誤った証明書を登録していないか |
クラシック クラスター（自己管理型）であれば、ARM テンプレートやクラスターマニフェストの以下の設定を確認します。
AdminClientCertThumbprintsClientCertThumbprints
ここに登録されている拇印と、手元の証明書が一致しているかを確認します。
端末（クライアント側）の証明書状態を確認
次に、ブラウザーを動かしている端末側の証明書をチェックします。Windows の場合：
certmgr.mscを実行し、「証明書 – 現在のユーザー」を開く- 個人 → 証明書 ストアに対象のクライアント証明書が存在するか確認
- 証明書をダブルクリックし、有効期間 と サムプリント（拇印） を確認
- Azure ポータル／クラスターマニフェストに登録されている拇印と一致するか確認
ブラウザー側で複数の類似証明書を保持していると、「別の証明書を選んでしまっている」ということもよく起こります。特に組織 CA から大量に証明書が配布されている環境では、証明書の サブジェクト名 や フレンドリ名 を工夫すると運用上のミスが減らせます。
ネットワークフロントエンド（AppGW / Front Door / Nginx 等）の mTLS 設定を確認
SFX に直接アクセスしているのではなく、Application Gateway や Azure Front Door、Nginx リバースプロキシなどを経由している場合、そこで mTLS が必須化されている可能性があります。
- App Gateway の「HTTP 設定」や「リスナー」で「クライアント証明書」が必須になっていないか
- 特定のパス（例：
/Explorer）に対してのみクライアント証明書を要求するルールが追加されていないか - 新しいフロントエンド経由の URL に切り替えてから 403 が出ていないか
この場合、クラスター自体の設定は変わっておらず、手前のゲートウェイで 403 が返されているだけというケースがあります。ブラウザーの開発者ツールでレスポンスヘッダーの Server や X-Azure-Ref などを確認すると、どこで 403 が発生しているかのヒントになります。
サーバー証明書のローテーションやプラットフォーム更新の影響
最後に、以下のようなイベントが最近なかったかを確認します。
- クラスターのサーバー証明書（Key Vault 参照）の更新
- Service Fabric バージョンアップ／OS の更新
- Key Vault のアクセス ポリシー／マネージド ID 設定の変更
サーバー証明書の更新時に、管理者が「ついでに」クライアント証明書ポリシーを触ってしまったり、テンプレートを再適用した結果、古いクライアント証明書が許可リストから落ちてしまう、といった事故も現場ではよく起きます。
とりあえずクラスターに入るための一時復旧パス
本番障害対応の現場では、まず「管理者がクラスターにアクセスできること」が最優先です。以下のいずれかの方法で、一時的にでも SFX または管理エンドポイントにアクセスできる状態を確保しましょう。
有効なクライアント証明書を端末にインポートして SFX にアクセス
すでに有効なクライアント証明書が存在し、それがクラスター側の許可リストにも登録されている場合は、端末側にインポートしてブラウザーで提示すれば SFX に入れる可能性があります。
- PFX ファイルを入手（管理者から受領、または自分で作成）
- Windows の場合はダブルクリックし、現在のユーザー → 個人ストアにインポート
- ブラウザーを一度終了して再起動
- 再度 SFX にアクセスし、証明書選択ダイアログで対象の証明書を選択
このとき、証明書のチェーンが正しく信頼されていないと、選んでも 403 になったり、ブラウザーが証明書を提示してくれない場合があります。特に中間 CA 証明書がクライアント側にインポートされているかどうかは重要なチェックポイントです。
PowerShell から管理接続して状態を確認
SFX に入れない場合でも、PowerShell から Connect-ServiceFabricCluster を使って管理接続できるケースがあります。
# クライアント証明書拇印とクラスター FQDN を指定して接続
$thumb = "<クライアント証明書の拇印>"
$serverCN = "<クラスターの FQDN（サーバー証明書の CN）>"
Connect-ServiceFabricCluster -ConnectionEndpoint "<FQDN>:19000" `
-X509Credential -FindType FindByThumbprint -FindValue $thumb `
-ServerCommonName $serverCN
:19000は Service Fabric 管理エンドポイントの既定ポートです- ここで接続できる場合は「クラスター側は証明書を受け付けているが、フロントエンド経由の SFX に問題がある」可能性があります
- 逆にここでも接続できない場合は、クライアント証明書自体の問題か、クラスターのクライアント証明書設定に問題があると考えられます
可能なら Azure AD 認証を有効化して SFX へサインイン
組織で Azure AD（Entra ID）を利用している場合、SFX に対して AAD 認証を有効にすることで、証明書なしでブラウザーからサインインできるようにすることも可能です。
操作の概要は次のようになります（詳細手順は環境により異なります）。
- Azure AD にアプリ登録を作成し、Service Fabric クラスターに紐づける
- クラスター側で AAD 認証を有効化（ARM テンプレート／Bicep で設定）
- 必要なユーザー／グループに対して Service Fabric 管理者／閲覧者ロールを割り当てる
ただし、本記事の主題は「403: Client certificate required」からの復旧なので、AAD 認証は恒久対策として位置づけ、まずは証明書ベースで一時的にでもアクセスを回復させるのがおすすめです。
クライアント証明書を新規発行して正式に復旧する手順
「証明書が期限切れだった」「誰も有効なクライアント証明書を持っていない」といった場合は、新たにクライアント証明書を発行し、クラスターの許可リストに登録する必要があります。
ステップ 1：クライアント証明書の新規発行
検証目的であれば、自己署名証明書でも十分です。本番環境では、できる限り組織の内部 CA（企業 PKI）から発行することを推奨します。
ここでは、テスト用途として自己署名クライアント証明書を PowerShell で作成する例を示します。
# 自己署名のクライアント証明書を作成（テスト用途）
$cert = New-SelfSignedCertificate `
-DnsName "sfx-client" `
-CertStoreLocation "cert:\CurrentUser\My" `
-KeyExportPolicy Exportable `
-NotAfter (Get-Date).AddYears(1)
# PFX にエクスポート（必要なら）
$pwd = ConvertTo-SecureString 'StrongPassword!' -AsPlainText -Force
Export-PfxCertificate -Cert $cert.PSPath -FilePath "$env:USERPROFILE\Downloads\sfx-client.pfx" -Password $pwd
作成した証明書の拇印は、以下のように取得できます。
$cert.Thumbprint
この拇印を後のステップでクラスターに登録します。
ステップ 2：クラスターへクライアント証明書を登録
Azure Managed Cluster の場合
Azure ポータルから次の順に操作します。
- Service Fabric（管理クラスター） を開く
- セキュリティ → クライアント証明書 を選択
- 追加 ボタンから新しいクライアント証明書を登録
このとき入力する内容の例：
| 項目 | 設定例 |
|---|---|
| 拇印 | <前ステップで取得した thumbprint> |
| 権限 | 管理者 または 読み取り専用（用途に応じて） |
| 説明 | 「SFX 管理者用」「運用チーム A」など意味がわかる説明 |
変更を保存すると、クラスター構成が更新され、数分後に新しいクライアント証明書でのアクセスが許可されます。
クラシック クラスター（自己管理）環境の場合
クラスターマニフェストや ARM テンプレートに、クライアント証明書の拇印を追記します。例として、クラスターマニフェストの一部は次のようになります。
<ClusterManifest>
<Security>
<ClientCertificateThumbprints>
<ClientCertificateThumbprint x509FindType="FindByThumbprint"
thumbprint="<新しい拇印>"
isAdmin="true" />
<!-- 既存の証明書設定があれば併記 -->
</ClientCertificateThumbprints>
</Security>
</ClusterManifest>
テンプレートを更新後、クラスター構成を再適用することで、新しいクライアント証明書での接続が可能になります。
ステップ 3：端末への配布とインポート
クライアント証明書（PFX）は、以下の観点で安全に配布します。
- PFX ファイルには強力なパスワードを設定する
- 配布は 暗号化されたチャネル（例：S/MIME メール、セキュアなファイル共有等）で行う
- パスワードは PFX 本体とは別チャネルで伝達する
- 配布先を最小限にし、誰にどの証明書を配ったかを記録する
インポート手順（Windows の例）：
- PFX ファイルをダブルクリック
- 証明書のインポートウィザードで、「現在のユーザー」を選択
- パスワードを入力し、「キーをエクスポート可能にする」は必要に応じて選択
- 「証明書をすべて次のストアに配置する」で「個人」を選択
ステップ 4：SFX へのアクセスを確認
証明書登録・配布が完了したら、ブラウザーから再度 SFX にアクセスし、以下を確認します。
- 証明書選択ダイアログに、配布した証明書が表示されるか
- 証明書を選択すると、403 ではなく SFX の画面が表示されるか
- クラスターノードやアプリケーションの状態が閲覧できるか
これでまずは「SFX に入れない」という致命的な状態からは脱出できます。
再発防止に向けた設計と運用のポイント
一度 403 で詰まると「次は絶対に起こしたくない」と思うはずです。ここでは、再発防止のために押さえておきたい運用設計のポイントを整理します。
証明書の有効期限を監視し、アラートを出す
サーバー証明書だけでなく、クライアント証明書も含めて期限切れ前に気付ける仕組みが重要です。
- Key Vault に保管しているサーバー証明書には、有効期限アラートを設定
- クライアント証明書は台帳（スプレッドシートや CMDB）に有効期限を記録し、期限前にリマインド
- スクリプトで証明書ストアを定期スキャンし、期限が近いものをメール通知する仕組みを作る
Azure AD 認証の導入で「人」に紐づくアクセス制御へ
証明書ベースの認証は強力ですが、「誰の証明書か」「紛失時の対応」など運用負荷が高くなりがちです。可能であれば、SFX へのアクセスを Azure AD（Entra ID）で統合し、以下のような運用に寄せると楽になります。
- Azure AD グループ単位で管理者／閲覧者を割り当てる
- 人事異動や退職に伴う権限の付け替えを AAD 側で一元管理
- MFA（多要素認証）や条件付きアクセスと組み合わせてセキュリティを向上
証明書は「緊急用」「自動化ツール用」に限定し、日常の運用は AAD に寄せる構成が現実的です。
IaC（Infrastructure as Code）でクラスター構成をコード化
クライアント証明書の許可リストや AAD 設定を、Bicep／Terraform／ARM テンプレートでコード化しておくと、次のメリットがあります。
- 誰がいつ設定を変えたかを Git の履歴で追跡できる
- プラットフォーム更新時に、意図せぬ設定リセットを防ぎやすい
- ステージング環境と本番環境の設定差分を把握しやすい
特に、クライアント証明書の拇印をテンプレートにハードコードするのではなく、パラメーター化しておくと、証明書ローテーション時にテンプレートの変更を最小限にできます。
変更監査（Change Monitoring）を仕組みとして持つ
「誰も設定を変えていないはずなのに…」という事故の多くは、実際には次のような変更がどこかで行われています。
- App Gateway の HTTP 設定でクライアント証明書必須にチェックが入った
- 別チームが WAF のポリシーを強化した
- テンプレートの修正でクラスター構成が上書きされた
これを防ぐには、以下のような監査・レビューフローを取り入れると効果的です。
- Azure Activity Log で構成変更を定期的にレビュー
- 重要なリソース（Service Fabric クラスター、App Gateway 等）は、変更管理プロセスを通さないと更新できないように制御
- IaC のプルリクレビューで、「セキュリティ関連設定の変更」を必ずチェックする観点を設ける
証明書配布プロセスの標準化
最後に、証明書の配布・管理プロセスを標準化しておくと、運用負荷とヒューマンエラーを大幅に減らせます。
| 項目 | 標準化のポイント |
|---|---|
| 発行元 | 本番は企業内 CA、検証環境は自己署名などルールを決める |
| 証明書名 | サブジェクトやフレンドリ名に「用途」「環境」「有効期限」を含める |
| PFX の保護 | パスワードポリシー、保管場所、バックアップ方法を決める |
| 配布方法 | Intune などのデバイス管理ツール／スクリプトでの一括配布を検討 |
| 失効／回収 | 紛失・退職時の失効手順を明文化し、運用フローに組み込む |
実務でよくあるつまずきポイント（チェックリスト付き）
現場で本当によく見かける「ハマりどころ」をまとめます。当てはまるものがないかチェックしてみてください。
- 拇印のコピペミス：半角スペースや見えない文字が混入している
- 大文字／小文字の違い：多くの場合は無視されますが、ツールによっては影響することも
- 類似した証明書が複数存在：ブラウザーが別の証明書を自動選択している
- 中間 CA 証明書が信頼ストアにない：クライアント証明書チェーンの検証に失敗している
- ポート違い：SFX は既定で
19080、管理エンドポイントは19000。別の経路では mTLS 必須になっている - サーバー証明書ローテーション後の不整合：
-ServerCommonNameなど接続側の設定と CN が食い違っている
特に「似たような証明書が複数ある」問題は、テストを繰り返したクライアント端末で頻発します。不要になった古い証明書は、定期的に整理しておくとトラブルを減らせます。
「設定を変えていないのに」なぜ急に 403 になるのか
最後に、よくある疑問に答えておきます。「クラスターの設定なんて何ヶ月も触っていないのに、なぜ突然 403 になるのか？」という点です。
典型的なトリガーは次のとおりです。
| トリガー | 裏で起きていること |
|---|---|
| OS／ランタイムの自動更新 | TLS 設定や既定のセキュリティポリシーが強化され、証明書のチェックが厳格になる |
| サーバー証明書のローテーション | テンプレート再適用により、クライアント証明書設定が上書きされることがある |
| ネットワーク構成変更 | ルーティングやフロントエンドの変更で、mTLS 必須の経路を経由するようになる |
| セキュリティ監査対応 | 別チームが「証明書必須」設定を有効化したが、影響範囲の周知が十分でない |
| 証明書の静かな期限切れ | ユーザー証明書が有効期限を迎えていたが、誰も気づいていなかった |
このように、「自分がクラスターの設定を触っていない」＝「何も変わっていない」ではありません。むしろ、自動更新や別チームの変更が原因であることの方が多いと言っても過言ではありません。
用語整理（日本語寄りの理解）
最後に、本記事で登場した用語を簡単にまとめておきます。
| 用語 | 意味 |
|---|---|
| SFX（Service Fabric Explorer） | Service Fabric クラスターの管理・監視を行う Web ベースの UI |
| クライアント証明書 | ユーザーや端末がサーバーに対して自分を証明するために提示する証明書 |
| サーバー証明書 | サーバー側がクライアントに提示する証明書。通常は Key Vault などで管理 |
| 相互 TLS（mTLS） | サーバーだけでなくクライアントも証明書を提示し、お互いを認証する TLS 通信方式 |
| 拇印（thumbprint） | 証明書の一意な識別子となるハッシュ値。許可リストへの登録に使用される |
| Service Fabric Managed Cluster（SFMC） | Azure が管理する Service Fabric クラスター。プラットフォーム更新などが自動化されている |
まとめ：403 の直接原因と対処方針
本記事で見てきたように、SFX に「403: Client certificate required」が出る直接の原因は、次のいずれかです。
- SFX／クラスターがクライアント証明書を必須にしているが、クライアントが提示していない
- 提示しているクライアント証明書が、クラスターの許可リストに登録されていない／期限切れである
そのうえで、対処方針は以下の流れで進めると安全かつ確実です。
- 現状把握：クラスターのクライアント証明書設定、端末の証明書、フロントエンドの mTLS 設定を確認
- 一時復旧：有効なクライアント証明書を使うか、PowerShell や AAD 認証で管理接続を確保
- 正式復旧：新規クライアント証明書の発行・登録・配布を行い、SFX へのアクセスを安定化
- 再発防止：証明書期限の監視、AAD 統合、IaC 化、変更監査、配布プロセスの標準化を実施
「設定を変えたつもりはないのに 403 になった」という状況でも、上記の切り分けと手順で落ち着いて対応すれば、原因を特定しつつ、より安全で運用しやすいクラスターに改善していくことができます。
コメント