SAML証明書・SSO証明書の期限切れ対応 ─ ログイン停止を避ける更新手順

冒頭要約

SAML証明書・SSO証明書は、IdPとSaaSの間で「このSAML応答は正しい発行元から来た」と確認するための重要な信頼材料です。証明書が期限切れになったり、IdP側だけを更新してSaaS側の設定が古いままだったりすると、利用者が正しいIDとMFAで認証していてもSSOログインに失敗します。

まず確認するのは、対象SaaS、証明書の役割、有効期限、metadata URLの有無、手動アップロードの必要性、切替日時、テストユーザー、緊急時の代替ログインです。証明書更新は暗号設定だけの話ではなく、SaaS停止を避ける変更管理タスクとして扱います。

この記事では、情シス、SaaS管理者、IdP管理者、開発者向けに、SAML証明書更新の確認方法、初動対応、判断基準、よくある誤解を整理します。攻撃手順、認証回避、侵入再現、悪用コードは扱いません。

• 作成・対象特定

  新しい公開証明書と識別子を確認。共有する全アプリと代替管理経路を把握する。

• SPで信頼・切替

  複数証明書対応なら事前登録。単一対応なら影響時間を調整して双方を切り替える。

• 新しい認証で検証

  既存セッションに頼らずログを照合。旧鍵の整理と残作業の担当・期限を記録する。

更新順序：SPが新旧証明書を同時に信頼できるかで分ける

以下は漏えいや秘密鍵の侵害がない通常更新の考え方です。署名用の秘密鍵が侵害された疑いがある場合は、停止回避のために旧鍵を維持せず、CSIRT・IdP・SaaS所有者が緊急の鍵交換・アクセス制限を判断します。公開証明書の共有と秘密鍵の共有は別で、秘密鍵をSPの設定欄へ渡す手順ではありません。

IdPごとに違う有効期限・反映条件

2026年10月20日に確認した公式資料では、次の差があります。製品全体や他の証明書種別へ一般化しないでください。

• Microsoft EntraのSAML署名証明書：アプリ追加時の自動生成証明書は3年。期限通知は60・30・7日前ですが、通知先と登録状態も管理画面で確認します。期限切れ証明書と有効な非アクティブ証明書が併存する場合、有効な証明書が自動使用され、SPが追従せず障害になる可能性があります。「非アクティブだから影響しない」とは決めつけません。公式の証明書管理を参照してください。
• Google WorkspaceをIdPとするSAMLアプリ：証明書は5年で、新旧2枚による移行が案内されています。SP側も更新が必要で、交換後に利用可能になるまで最大24時間かかる場合があります。24時間待てば必ず復旧するという意味ではなく、変更枠・監視・ベンダー連絡の計画へ織り込みます。公式のSAML証明書管理で確認できます。
• Okta Classic Engine：アクティブ証明書はアプリ統合単位、非アクティブは組織単位というスコープ差があります。生成とActivateを区別し、表示されるSAML設定手順に沿ってSPへ渡す値を確認します。公式の署名証明書管理の対象はClassic Engineです。

---

読者別の影響：誰が何を見るべきか

SAML証明書の期限切れは、IdP担当だけの問題ではありません。対象SaaSの管理者、ヘルプデスク、開発者、監査担当が同じ変更計画を見ておく必要があります。

読者・担当者	まず見るもの	見落としたときの問題
情シス・IdP管理者	SAMLアプリ一覧、証明書の有効期限、通知先、metadata URL、切替日時	IdP側で証明書を変えた直後に複数SaaSのログインが失敗する
SaaS管理者	SP側の証明書登録、署名方式、SAML設定、代替管理者、監査ログ	SaaS側が古い証明書を信頼し続け、認証エラーになる
開発者・SaaS提供者	metadata取得、複数証明書対応、キャッシュ、署名検証、テスト環境	証明書ロールオーバー時に顧客テナントのSSOが止まる
ヘルプデスク	影響ユーザー、ログイン失敗時刻、問い合わせテンプレート	「パスワードが違う」と誤案内し、初動が遅れる
CSIRT・監査担当	変更チケット、ログ、例外、失敗時の判断、復旧証跡	設定ミスと不審ログインの切り分けができない

用語を先に整理したい場合は、SAML、SSO、IdP、デジタル署名を確認してください。ログインできることと操作権限は別なので、認証と認可の違いも合わせて見ると判断がぶれにくくなります。

---

SAML証明書とは：IdP証明書とSP証明書の違い

SAMLでは、IdPがユーザーを認証し、SaaSなどのSP（Service Provider）へSAML assertionやSAML responseを送ります。SPは、登録済みの公開証明書を使って署名を検証し、「信頼してよいIdPから来た応答か」を判断します。

実務で混乱しやすいのは、証明書の名前が製品ごとに違うことです。

表記例	主な意味	確認ポイント
SAML Signing Certificate	IdPがSAML assertionやresponseへ署名するための証明書	有効期限、thumbprint、署名アルゴリズム、アクティブ状態
IdP certificate / Public Certificate	SP側に登録し、IdPからのSAML応答を検証する公開証明書	SP側に新旧どちらが登録されているか
Federation metadata / SAML metadata	entity ID、SSO URL、endpoint、証明書などをまとめたXML	SaaSが自動取得するか、キャッシュ更新が必要か
SP certificate	SPがSAML request署名や暗号化で使う証明書	IdP側に登録が必要か、用途が署名か暗号化か

Microsoft Entra IDの公式情報では、SAML証明書のロールオーバーには顧客とSaaS側の調整が必要だと説明されています。Google Workspaceの公式情報も、証明書を切り替えた場合はSP側のSSO設定にも新証明書を反映する必要があるとしています。TLS証明書の有効期間を、そのままSAML署名証明書へ当てはめません。

---

まず確認すること：SSO証明書更新チェックリスト

期限切れや更新通知を受け取ったら、いきなり証明書を切り替えず、次の項目を台帳化します。

確認項目	見るポイント	記録すること
1. 対象SaaS	どのSAMLアプリが対象か。部門契約SaaSや本番・検証環境も含める	SaaS名、環境、オーナー、利用部門
2. 証明書の役割	IdP署名用か、SP request署名用か、暗号化用か	証明書名、thumbprint、用途
3. 有効期限	期限切れまでの日数、通知先、過去の更新履歴	有効期限、通知メール、変更チケット
4. 更新方式	metadata URL、自動ロールオーバー、手動アップロード、API更新のどれか	更新方法、担当者、必要な権限
5. 複数証明書対応	新旧証明書を同時登録できるか	secondary証明書、activate手順、削除タイミング
6. 署名方式	assertion署名、response署名、両方、署名アルゴリズム	設定値、SaaS側要件、変更有無
7. テスト手順	SP-initiated / IdP-initiatedログイン、テストユーザー、検証SaaS	成功条件、失敗時ログ、確認者
8. 代替ログイン	break glass管理者、ローカル管理者、サポート連絡先	利用条件、保管先、監査方法
9. 周知と窓口	影響時間、対象ユーザー、ヘルプデスク案内、問い合わせ文面	周知日時、FAQ、障害時の連絡先
10. ロールバック	旧証明書へ戻せるか、キャッシュをどう扱うか	戻し条件、判断者、期限

証明書更新の対象は、SaaS管理画面に表示される1アプリだけとは限りません。同じIdP証明書を複数アプリで使っている場合、複数SaaSに同時影響が出ることがあります。Oktaの公式情報では、SAML Signing Certificatesのアクティブ証明書やアプリごとの証明書スコープを確認できます。Google Workspaceでは証明書変更イベントが管理監査ログに残るため、切替記録としても確認できます。

---

初動対応：やること、やらないこと、記録すること

やること

• 期限切れ通知を受けたSaaSだけでなく、同じIdP証明書を使うアプリ一覧を確認する。
• 期限切れまでの日数で作業優先度を分け、業務停止影響が大きいSaaSから切替計画を作る。
• metadata URLをSaaSが自動取得するか、手動で公開証明書を貼り替える必要があるか確認する。
• 新旧証明書を同時登録できる場合は、旧証明書をすぐ削除せず、テストログイン成功後に削除時期を決める。
• 対象製品が対応し自社で利用するSP-initiated / IdP-initiatedの各経路をテストし、SaaS監査ログとIdPサインインログを照合する。非対応の起点を必須にしない。
• 失敗時に備えて、break glass管理者やローカル管理者でSaaS管理画面へ戻れることを確認する。

やらないこと

• 通知メールの期限だけを見て、対象SaaSと証明書用途を確認せずに新証明書を有効化しない。
• 本番SaaSで、テストユーザーやロールバック手順なしに切替しない。
• 「metadata URLがあるから自動で追従する」と決めつけない。
• 証明書期限切れを、証明書漏えいや侵害の証拠として短絡的に扱わない。
• ヘルプデスクへ「パスワードリセットで対応」とだけ案内しない。

記録すること

記録項目	例
対象	SaaS名、環境、本番/検証、アプリID、entity ID
証明書	thumbprint、有効期限、旧証明書、新証明書、用途
変更	作業者、承認者、切替時刻、metadata更新、手動アップロード
テスト	テストユーザー、ログイン方式、成功/失敗、ログの時刻
影響	失敗ユーザー数、問い合わせ件数、業務影響、代替手段
判断	継続、ロールバック、追加調査、SaaSベンダー連絡

ログの読み方に不安がある場合は、セキュリティログの読み方を合わせて確認してください。退職者や委託先を含むSaaS全体の権限確認へ広げる場合は、SaaS権限棚卸しチェックリストを使うと作業化しやすくなります。

切替完了を判断する確認表

更新対象や方式が曖昧なら、SAMLとOIDCの選び方・署名鍵と証明書の違いで、接続先と鍵の用途・確認単位を整理できます。下表はSAMLの切替確認に使い、OIDCの更新へそのまま流用しません。

既存のSaaSセッションで画面が開くことは、新証明書によるSAML認証の成功を示しません。承認済みのテストユーザーで新しい認証を発生させ、次の記録をアプリ・環境ごとに残します。SAML応答全文には個人情報や認証情報が含まれ得るため、公開デコーダーへ貼り付けず、必要最小限の識別情報とログ参照先を保管します。

記録欄	完了の根拠	不足時の扱い
対象・役割	SaaS、環境、entity ID、証明書の用途が一致	対象を再確認。TLSや暗号化用の更新と混ぜない
信頼・署名	SPに新証明書、IdPに意図した署名設定。識別子を照合	metadata取得・キャッシュ・手動反映を担当へ確認
新規認証	利用する各起点で成功し、双方の時刻・ログが対応	既存セッションの成功で代用しない
運用復帰	業務確認、エラー監視、旧証明書整理、承認者と残作業	未確認アプリの担当・期限・制限を残す

通常更新で旧証明書へ戻す場合も、期限内・侵害なし・双方で再設定可能という条件を確認します。署名検証や期限検証の無効化を復旧手段にしません。

---

判断基準：優先度とエスカレーション条件

SAML証明書更新は、期限までの日数だけでなく、対象SaaSの重要度と代替手段で優先度を決めます。

以下の7日・60日は編集部の計画例で、製品の標準作業期限ではありません。影響の大きいサービスや確認不能な代替経路は、残日数が長くても早く着手します。

優先度	状況	初動判断
高	期限切れまで7日以内、またはすでに期限切れ	変更枠を確保し、SaaS管理者・ヘルプデスク・業務オーナーを同じチケットに入れる
高	人事、経理、顧客管理、GitHub、クラウド管理など業務停止影響が大きい	テスト環境、代替ログイン、ロールバックを確認してから切替する
高	SaaS側が単一証明書のみ対応、手動アップロードのみ、または夜間サポート不可	切替時刻を明示し、失敗時の判断者とSaaSベンダー連絡先を決める
高	管理者もSSO依存で、break glass管理者が未確認	先に緊急用管理者アカウントを確認し、ロックアウトリスクを下げる
中	metadata URL対応だが、取得頻度やキャッシュ更新が不明	新証明書の事前取り込み、取得時刻、SaaS側表示を確認する
低	期限まで60日以上あり、検証環境と複数証明書対応がある	通常変更として計画し、棚卸し台帳へ期限を登録する

GitHub Enterprise CloudのEnterprise Managed Users向け公式ドキュメントでは、IdP証明書の有効期限は強制しない一方、IdPで再生成してGitHub側を更新しなければ不一致で認証が失敗すると説明されています。この製品条件を他のSaaSへ広げず、期限切れでも使い続けてよいという推奨とも扱いません。

---

よくある誤解

「IdPで新証明書を作ったので完了」

IdP側で新証明書を作成しても、SP側がその証明書を信頼していなければログインは失敗します。SaaSがmetadataを自動取得するのか、手動で証明書を更新するのかを確認します。

「SAML証明書の期限切れは必ず侵害を意味する」

期限切れは主に運用上の問題です。もちろん不審なログイン失敗や設定変更が同時にある場合は調査対象ですが、期限切れだけで侵害を断定しません。変更履歴、管理者操作、監査ログを確認します。

「SSOが失敗したらパスワードリセットで直る」

SAML証明書不一致では、ユーザーのパスワードやMFAが正しくてもログインできません。利用者へ不要なパスワード変更を案内する前に、IdPとSaaSのSAML設定、証明書、サインインログを確認します。

「SAMLとOIDCは同じ手順で更新できる」

SAMLはXML metadataや証明書の取り扱いが中心で、OIDCはJWKSやissuer、client設定など確認点が異なります。方式が混在している環境では、SAMLとOIDCの違いを確認し、同じチェックシートで扱わないようにします。

「旧証明書はすぐ消したほうが安全」

不要な証明書を残し続けるのはよくありませんが、切替直後に旧証明書を即削除すると、キャッシュや未更新SaaSがある場合に復旧経路を失います。削除時期、影響確認、ロールバック期限を決めてから整理します。

---

関連用語・関連ページ

目的	ページ
SSOと認証の基礎を確認する	SAML、SSO、IdP、認証
証明書と署名の意味を確認する	デジタル署名、PKI、TLS
方式の違いを整理する	SAMLとOIDCの違い、SSOとMFAの違い、認証と認可の違い
SaaS運用へ落とす	SaaS権限棚卸しチェックリスト、退職者アカウント確認チェックリスト
Webサーバー証明書の漏えいに対応する	TLS証明書の秘密鍵漏えい時の初動対応
関連記事を読む	SCIM連携・自動プロビジョニングの確認方法、SaaS権限棚卸しの進め方、条件付きアクセス例外の棚卸し、緊急用管理者アカウントの棚卸し
演習で確認する	認証と認可のミニCTF、ログイン失敗ログの読み方ミニCTF、クイズで用語を復習する

---

公式情報・参考情報

公開資料の照合・本文更新日：2026年10月20日。実テナントでの切替・復旧検証は行っていません。比較表と完了確認表は編集部の実務整理です。

• Microsoft Learn: Manage federation certificates in Microsoft Entra ID — Entra IDのSAML証明書の有効期限、更新、metadata endpointを使うロールオーバー、SaaS側更新の必要性を確認できる。
• Microsoft Learn: Certificate signing options in a SAML token — SAML assertion、SAML response、または両方へ署名する設定と、署名アルゴリズムの考え方を確認できる。
• Okta Documentation: Manage signing certificates — OktaのSAML Signing Certificatesで、新規証明書生成、アクティブ化、アプリごとの証明書スコープを確認できる。
• Google Workspace Help: Maintain SAML certificates — Google WorkspaceのSAML証明書管理、アプリへの証明書割り当て、SP側設定更新、監査ログ記録を確認できる。
• GitHub Docs: Configuring SAML single sign-on for Enterprise Managed Users — GitHub Enterprise CloudのSAML SSOでPublic Certificateを設定し、証明書不一致時の認証エラーを確認できる。
• OASIS: Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0 — SAML metadataが識別子、endpoint、証明書、鍵などを記述する仕様であることを確認できる。

---

まとめ

SAML証明書・SSO証明書の更新は、IdP管理画面で新証明書を作るだけでは完了しません。対象SaaS、証明書用途、有効期限、metadata URL、手動アップロード、複数証明書対応、テストユーザー、代替管理者、ログ、ロールバックをセットで確認する必要があります。

特に、期限切れまで7日以内、業務停止影響が大きいSaaS、単一証明書のみ対応、手動更新のみ、break glass管理者未確認の環境は優先度を上げます。更新後は、SaaS監査ログ、IdPサインインログ、ヘルプデスク問い合わせを同じ時間軸で見て、設定ミスと不審な認証イベントを切り分けます。

まず切替完了の確認表を社内の変更記録へ転記し、SSO対象の所有者・管理権限はSaaS権限棚卸しチェックリストで確認してください。次回の更新に備える場合は「あとで読む」に保存し、進捗ページから開き直せます。証明書や社内台帳そのものをサイトへ入力する必要はありません。