SAML署名証明書の更新手順｜SSO停止を防ぐメタデータ切替と切り戻し
SAMLのシングルサインオン（SSO）で使う署名証明書は、利用者のパスワードとは別に、Identity Provider（IdP）が発行するSAML応答やアサーションが正規のものだとService Provider（SP）へ示すための信頼情報です。証明書が期限切れになったり、IdPだけで新しい証明書を有効化してSP側の登録が古いままになったりすると、正しい利用者でも複数のSaaSへ一斉にログインできなくなる可能性があります。
安全に更新するには、期限だけでなく、対象アプリ、現在の証明書フィンガープリント、IdPの署名開始時刻、SPが受け入れる証明書数、メタデータの自動更新可否、緊急ログイン経路を一つの変更台帳へまとめます。Google Workspaceの認証後に適用する端末・場所・IP条件はコンテキストアウェアアクセスの設計で確認し、この記事ではSAML署名証明書のローテーションに範囲を絞ります。
SAML署名証明書を止めずに更新する要点は、SPが複数証明書を受け入れるなら新しい公開証明書を先にSPへ追加し、旧証明書でのログインを保ったままIdPの署名を切り替え、実ログインとフィンガープリントを確認してから旧証明書を外すことです。1枚しか登録できないSPでは、IdPとSPを同じ保守時間帯で切り替え、SSOを経由しない管理者アカウントと旧設定を残しておきます。どちらの場合も、期限当日の作業にしないことが最も重要です。
本記事のポイント
- 証明書の期限監視は60日前までに始め、対象SaaS、管理者、SPの複数証明書対応、緊急ログイン経路を台帳化します。
- 複数証明書を使える場合は新証明書をSPへ先行登録し、IdP切替後の実ログインを確認してから旧証明書を外します。
- 1枚しか使えないSaaSは保守時間帯を固定し、旧メタデータ、旧フィンガープリント、切り戻し担当を事前に残します。
SAML署名証明書の役割と切替順を先に決める
SAML署名証明書は、WebサイトのHTTPS接続に使うTLS証明書と同じものではありません。一般的なIdP署名では、秘密鍵をIdP側に保持し、公開証明書をSP側へ登録します。SPは受け取ったSAML応答・アサーションの署名を公開鍵で検証します。更新時にSPへ渡すのは公開証明書またはフェデレーションメタデータであり、IdPの秘密鍵をSaaSへ配布しません。
OASISのSAML V2.0 Metadata仕様では、エンティティが署名や暗号化に使う鍵情報をKeyDescriptorで表し、同要素を複数持てる構造になっています。ただし、仕様上複数の鍵を書けることと、利用中のSaaS管理画面が複数証明書を受け入れ、自動でメタデータを更新できることは別です。各SPについて「複数登録」「メタデータ自動取得」「手動で1枚だけ」のどれかを確認してから順序を決めます。
| SP側の対応 | 安全な基本順序 | 確認すること | 主なリスク |
|---|---|---|---|
| 新旧証明書を複数登録できる | 新証明書をSPへ追加し、IdPを切替後、旧証明書を削除 | 新証明書が副証明書として保存され、旧証明書も有効なこと | SPへの先行登録漏れ、別環境への誤登録 |
| フェデレーションメタデータを定期取得できる | 新証明書をメタデータへ追加し、SPの取得を確認後にIdPを切替 | 取得間隔、キャッシュ、有効期限、複数鍵の扱い | 古いキャッシュ、取得失敗、URLの環境違い |
| 証明書を1枚だけ登録できる | 保守時間帯にSP登録とIdP有効化を連続実施 | 更新担当者、停止許容時間、緊急ログイン、旧値への復帰手順 | 切替の時間差による全利用者のログイン失敗 |
| 更新仕様が不明 | 本番を触らずベンダーへ確認し、テスト環境またはテストアプリで検証 | 署名対象、証明書形式、フィンガープリント、サポート窓口 | 推測による有効化、期限直前の手戻り |
Google WorkspaceをIdPとしてSAMLアプリへ接続する場合、管理コンソールでは有効なX.509証明書を最大2枚保持でき、2枚を使って一部アプリから新証明書へ移す方法が案内されています。Googleの公式資料は、管理コンソールでアプリへ新証明書を割り当てた後、SP側のSSO設定も更新しなければログインに失敗すると明記しています。また、新しい証明書がSAMLアプリで利用可能になるまで最大24時間かかる場合があるため、保存直後の一回の成功だけで全体切替を判断しません。
Microsoft Entra IDの公式手順では、自動生成されるSAML署名証明書は既定で3年間有効で、期限の60日、30日、7日前に通知します。新しい証明書をInactiveの状態で作成し、正しい形式でダウンロードしてアプリへ登録した後、Activeへ切り替える流れが示されています。Oktaでもアプリ統合ごとのSAML Signing Certificatesから新しい証明書を生成・有効化できます。製品名が違っても、旧証明書が使える間に新証明書の受け入れ準備を終える考え方は共通です。
期限監視から旧証明書削除までを7ステップで進める
更新作業は証明書ファイルの差し替えではなく、複数SaaSの認証経路を変える変更です。利用者グループの割り当てまで含めて確認する場合はGoogle Workspaceのグループ権限管理も併用し、証明書更新と対象者変更を同時に行わないようにします。
- 60日前までに対象を確定する。IdPが保持する証明書の有効期限、SHA-256フィンガープリント、証明書ID、利用中のSAMLアプリ、環境、所有部門、技術担当、ベンダー窓口を台帳へ記録します。通知先を個人1人だけにせず、複数担当者または管理用グループへ送ります。
- SPの受け入れ方式を分類する。複数証明書、メタデータ自動取得、1枚のみ、仕様不明のどれかをSaaSごとに記録します。ファイル形式はBase64のCER、PEM、メタデータXMLなど製品指定に合わせ、拡張子だけで判断しません。
- 緊急ログインと切り戻し材料を保全する。SSOを経由しない管理者アカウント、管理画面URL、旧証明書ファイル、旧メタデータ、旧フィンガープリント、設定画面の値、変更前のテスト結果を保存します。緊急アカウントは普段の共有IDにせず、強固な多要素認証、利用通知、保管責任者を設定します。
- 新しい証明書を生成してSPへ先行登録する。複数登録できるSPには新証明書を副証明書として追加し、旧証明書を残します。メタデータ取得型では、新旧の署名鍵が掲載されたこととSP側の取得時刻を確認します。1枚型ではまだ本番値を上書きせず、保守時間帯の手順に組み込みます。
- テストアプリまたは限定アプリでIdPの署名を切り替える。Google Workspaceのようにアプリ単位で証明書を割り当てられる場合は、影響の小さいアプリから新証明書へ移します。テスト利用者の通常ログイン、ログアウト後の再ログイン、IdP起点・SP起点、別ブラウザ、モバイルを確認します。
- SAML応答と実ログインを照合する。ブラウザの成功画面だけでなく、IdPログ、SPの監査ログ、SAML応答の署名証明書フィンガープリント、発行者、Audience、時刻条件を確認します。時刻ずれや別設定のエラーを証明書障害と混同しないよう、エラーコードと失敗時刻を残します。
- 全アプリを移行し、監視期間後に旧証明書を外す。全対象のログイン成功、新フィンガープリントの利用、旧フィンガープリントでしか成功しないアプリがゼロであることを確認します。業務上必要な監視期間を置き、旧証明書の割り当て解除、SP登録削除、変更記録の完了を同じチケットで閉じます。
SAML署名証明書の更新が完了するのは、新しい証明書を有効化した時ではなく、対象SaaSのログイン成功、署名フィンガープリント、旧証明書への切り戻し手順を同じ変更記録で確認できた時です。
| 変更台帳の区分 | 記録する内容 |
|---|---|
| 証明書 | 証明書ID、Subject、Issuer、有効開始・終了、SHA-256フィンガープリント、保存場所 |
| 対象 | IdP、SP、テナント、環境、アプリ所有者、利用者範囲、重要度 |
| 切替方式 | 複数登録、メタデータ取得、1枚のみ、IdP有効化予定時刻、SP変更時刻 |
| 検証 | IdP起点・SP起点、テスト利用者、署名フィンガープリント、監査ログ、結果 |
| 復旧 | 緊急ログインURL、旧設定、戻す条件、判断者、実施者、連絡手段 |
1枚しか使えないSaaSとSSO失敗時の切り戻しを管理する
SPが証明書を1枚しか登録できない場合は、完全な無停止を前提にしません。利用が少ない時間帯を選び、変更凍結、利用者通知、IdP担当とSP担当の同席、切り戻し判断時刻を決めます。Microsoftの公式資料も、アプリが1枚しか扱えない場合は作業停止時間を選ぶよう案内しています。SaaS側の設定反映が遅い場合に備え、ベンダー窓口と影響部門の連絡経路を開いたまま作業します。
更新順は「SPへ新証明書を登録し、直後にIdPを新証明書へ切り替える」か「IdPで新証明書を有効化し、直後にSPを更新する」かの二択に見えますが、1枚型ではどちらにも不一致時間が生まれます。製品の保存反映と署名開始の挙動をテスト環境で確認し、実作業では秒単位の順序より、担当者の同時実施、明確な停止判定、緊急ログインの確保を優先します。
切り戻し条件には、重要SaaSのログイン失敗、複数利用者・複数ブラウザで同じ署名エラー、SP監査ログで新フィンガープリントが未認識、管理者のSSOログイン不能など、観測できる事象を使います。条件に達したら追加設定を重ねず、IdPの署名を旧証明書へ戻し、SP登録も旧証明書へ戻します。旧証明書が期限切れまたは失効済みなら戻せないため、期限前に十分な重複期間を確保する必要があります。
切り戻した後は、通常利用者のログインだけでなく管理者アクセスも確認します。管理者パスワードや特権アカウントの異常を見落とさないため、Google Workspaceの管理者パスワードリセット通知も確認し、緊急アカウントの利用を監査ログへ残します。SAMLアプリの監査と証明書イベントを同じ変更番号に結び付けると、誰がいつ証明書を生成・割り当て・削除したかを追いやすくなります。
よくある質問
SAML署名証明書の有効期限をいつから監視しますか？
遅くとも60日前までに作業を開始できるよう監視します。Microsoft Entra IDは60日、30日、7日前の通知を案内していますが、通知は作業そのものではありません。SaaS所有者の確認、ベンダー問い合わせ、テスト、承認に時間がかかるため、台帳では90日前を予告、60日前を着手期限にすると余裕を持てます。
IdPとSPのどちらを先に更新しますか？
SPが複数証明書を受け入れるなら、公開情報である新証明書をSPへ先に追加し、旧証明書も残したままIdPを切り替えます。メタデータ自動取得型はSPの取得完了を確認してから切り替えます。1枚しか使えない場合は一律の正解がないため、保守時間帯に両側を連続変更し、緊急ログインと切り戻しを確保します。
新旧証明書を併用できないSaaSはどう切り替えますか？
利用が少ない保守時間帯を設け、IdP担当、SP担当、利用部門、ベンダー窓口をそろえます。旧設定とフィンガープリントを保存し、SP登録とIdP有効化を連続実施して、複数のテスト利用者で直ちに確認します。失敗を許容する時間と戻す時刻を作業前に決めます。
SSO失敗時に旧証明書へどう切り戻しますか？
SSOを経由しない管理者経路でIdPとSPへ入り、IdPの署名証明書とSPの検証証明書を旧値へ戻します。旧メタデータ、旧証明書ファイル、旧フィンガープリント、変更前画面を参照し、IdP起点・SP起点のログインを再テストします。期限切れの旧証明書には戻せないため、切替は期限前に行います。
メタデータURLがあれば手動更新は不要ですか？
不要とは限りません。SPがメタデータを取得する間隔、キャッシュの上限、複数のKeyDescriptorの扱い、新しい鍵を副証明書として保持するかを確認します。MicrosoftはISV向けに少なくとも24時間ごとのメタデータ監視を推奨していますが、利用中のSaaSが同じ実装とは限らないため、取得ログまたはベンダー回答で確認します。
証明書更新と利用者・権限変更を同時にしてよいですか？
同時に行わない方が安全です。ログイン失敗が証明書、ユーザー割り当て、グループ、属性、Audienceのどれによるものか切り分けにくくなるためです。認証連携サービスの審査・権限も見直す場合はGoogle Workspace連携サービスのOAuth審査とスコープ設計を別の変更として扱います。
製品仕様と標準を確認する
SAML署名証明書の更新は、証明書ファイルを入れ替えるだけの作業ではなく、利用者が業務SaaSへ入る信頼経路の変更です。期限、対象アプリ、SPの受け入れ方式、緊急ログイン、実ログイン結果、旧証明書削除までを一つの変更記録にまとめれば、期限切れによる一斉停止と、切替時の復旧不能を避けやすくなります。
