【SharePoint】証明書を更新した後に共有権限で別アカウントに切り替わる時の証明書ストアと失効情報の確認

証明書を更新したタイミングで、SharePointの共有権限設定画面に表示されるアカウントが別のユーザーやアプリケーションに変わってしまうことがあります。この現象は、クライアント証明書やアプリケーション証明書のストア内の構成、あるいは証明書失効情報の取得状態が原因で発生します。本記事では、問題を切り分けるための具体的な確認手順と管理者へ伝えるべき情報をまとめました。

現象の概要と想定される原因

証明書更新後に「共有権限で別アカウントに切り替わる」という症状は、主に以下の2つのシナリオで報告されます。

• シナリオ1:クライアント証明書を使ったユーザー認証 ユーザーがクライアント証明書を使ってSharePointにサインインする環境で、証明書更新後に共有リンクの作成や権限設定画面に表示されるユーザー名が、実際のユーザーとは異なる名前になる。
• シナリオ2:アプリケーション証明書を使ったサービスプリンシパル認証 Azure ADに登録したアプリケーションが証明書を使ってSharePointサイトにアクセスする構成で、証明書更新後にそのアプリケーションの共有権限が別のサービスプリンシパル(テスト用など)に変わって表示される。

いずれのケースも、原因は証明書ストア内に新旧2つの証明書が混在していることや、証明書失効情報が正しく取得できずに古い証明書が利用され続けることにあります。また、証明書のサブジェクトやサブジェクト代替名(SAN)が複数のアカウントを参照している場合も、切り替わりが発生します。

確認すべきポイント

問題を切り分けるためには、以下の3つの軸で確認します。

1. 証明書ストアの状態

端末またはサービスアカウントの証明書ストアに、更新後の証明書が正しくインストールされているかを確認します。特に、複数の証明書が同じサブジェクトで存在する場合は競合が起きやすくなります。

2. 証明書失効情報の取得

証明書に含まれるCRL配布点(CDP)やOCSP応答者情報にアクセスできているかどうか。ネットワーク制限により失効情報が取得できないと、Windowsが証明書を失効済みと判断し、別の証明書へフォールバックする可能性があります。

3. Azure AD / SharePoint Online側の設定

Azure ADアプリケーションの証明書マッピングや、SharePointの信頼できるアイデンティティプロバイダー設定が正しいかを確認します。証明書の拇印が更新前後で変わっている場合、古い拇印を参照しているエントリがあると問題になります。

証明書ストアの確認手順

Windows端末上でMMC(Microsoft Management Console)を使って証明書ストアを確認する手順を説明します。

1. [ファイル名を指定して実行](Win+R)で「mmc」と入力し、MMCを起動します。
2. [ファイル]メニューから[スナップインの追加と削除]を選択し、[証明書]スナップインを追加します。
3. スナップインの追加時に、管理対象として[コンピュータアカウント]または[ユーザーアカウント]を選択します。 問題が発生しているアカウント(自分のユーザーアカウントか、サービスアカウント)に合わせてください。
4. 追加後、左ペインで[証明書]→[個人]→[証明書]フォルダを展開し、目的の証明書をダブルクリックしてプロパティを確認します。 特に「発効日」「有効期限」「サブジェクト」「拇印」をメモしてください。
5. 同じサブジェクトの証明書が複数存在しないかを確認し、古い証明書が残っている場合は削除を検討します。 ただし、削除は管理者と相談してから実行してください。

証明書失効情報の確認方法

証明書が失効していないかを確認するには、以下の方法があります。

• 証明書プロパティの「CRL配布点」タブ 証明書の詳細タブ内に表示されるURLをブラウザで開き、CRLファイル(.crl)がダウンロードできるかを確認します。
• コマンドプロンプトでcertutilコマンド 「certutil -urlfetch -verify 証明書ファイル.cer」を実行すると、失効情報の取得状態が詳細に表示されます。
• イベントビューアーの確認 アプリケーションとサービスログ→Microsoft→Windows→CAPI2→Operationalに失効チェックの失敗ログがないか調べます。

トラブルシューティングと失敗パターン

よくある失敗パターンとその対処法を紹介します。

• 古い証明書を削除せずに更新した
  新しい証明書をインストールする際、Windowsは同じサブジェクトの証明書が複数あると優先順位が不明確になり、意図しない証明書が選択されることがあります。必ず古い証明書を削除するか、失効処理をしてください。
• CRL配布点に社内ファイアウォールでアクセスできない
  証明書の検証時、WindowsはCRL配布点に接続できないと証明書を信頼しない場合があります。その結果、代替の証明書が使われることがあります。ネットワークチームに確認し、必要なURLを通すよう依頼してください。
• Azure ADアプリケーションに複数の証明書が登録されている
  Azure ADポータルでアプリケーションの「証明書とシークレット」を確認し、更新後の証明書の拇印だけがアクティブになっていることを確認します。古い証明書が有効のまま残っていると、認証時に古い証明書が使われることがあります。

管理者に伝えるべき情報

問題の報告や調査依頼をする際は、以下の情報を整理して伝えてください。

• 現象が発生した日時と、「共有権限で別アカウントに切り替わる」具体的な画面のスクリーンショット
• 証明書更新作業の実施日時と、更新対象となった証明書のサブジェクト名
• 端末の種類(社用PC、VDI、サーバーなど)と、使用しているWebブラウザ(Edge、Chromeなど)
• 上記手順で確認した、証明書ストア内の証明書一覧(有効期限、拇印、発行先)
• CRL配布点への接続可否の確認結果(成功/失敗とエラーコード)

よくある質問(FAQ)

Q1. 証明書を更新しても、共有権限画面のアカウントが変わらないようにするにはどうすればいいですか?

更新前の古い証明書を必ず削除し、新しい証明書だけがストアに存在する状態にしてください。また、Azure ADアプリケーションを使っている場合は、古い証明書を無効または削除してから新しい証明書を追加してください。

Q2. 証明書失効情報が取得できない環境でも対処できますか?

CRL配布点へのアクセスが制限されている場合は、インターネットベースのCRL配布点か社内のCRL配布点を経由するようネットワーク設定を見直すか、グループポリシーで証明書失効チェックを無効にすることが考えられます。ただし、セキュリティが低下するため管理者の判断が必要です。

Q3. 今回の現象はSharePoint Onlineだけですか?オンプレミスでも起きますか?

SharePoint Server(オンプレミス)でも同様の現象は発生します。特にクレームベース認証でクライアント証明書を使っている場合に、証明書更新後にユーザー識別が変わることが報告されています。手順の基本は同じですが、サーバー側の証明書マッピング設定も確認する必要があります。

まとめ

証明書更新後の共有権限の切り替わりは、証明書ストア内の競合や失効情報の取得失敗が主な原因です。最初に、MMCでストア内の証明書を確認し、古い証明書が残っていないか、失効情報が正しく取得できているかをチェックしてください。次に、Azure ADやSharePoint Online側の証明書マッピングが更新後の証明書を指しているか確認します。これらの確認で原因の多くは特定できますので、適切な情報を管理者に伝えて早期に解決を図りましょう。