IdP/ SP証明書の基礎
SAMLでは署名や暗号化にX.509証明書を使います。役割と運用ポイントを押さえて、切替えや失効でトラブルにならないようにしましょう。
🔑 証明書の役割
署名用と暗号化用で役割が分かれます。メタデータのKeyDescriptorで用途を示します。
用途
| 項目 | 説明 |
|---|---|
| 署名 | SAML Response/Assertion の改ざん検知と発行元確認に利用。IdP署名証明書でSPが検証。 |
| 暗号化 | Encrypted Assertion などで属性を秘匿。SP公開鍵で暗号化し、SP秘密鍵で復号。 |
| 掲載先 | IdP証明書はIdPが提供しメタデータに署名用途で掲載。SP証明書はSPが用意し署名/暗号化用途で掲載。 |
IdP証明書の主な使われ方
- 🧭 IdPが発行する署名付きResponse/Assertionを、SPが公開鍵で検証する
- 🧭 IdP側では主に署名用途。暗号化は通常SPの公開鍵を使う
- 🧭 メタデータの use="signing" に登録し、ローテーション時は新旧を並行掲載する
SP証明書の主な使われ方
- 🧭 IdPがEncrypted Assertionを発行する際に、SP公開鍵で暗号化する
- 🧭 SP発行のLogoutRequestなどに署名する場合、SP秘密鍵で署名しIdPが検証する
- 🧭 メタデータにSP公開鍵を載せ、use="signing" / use="encryption" を明示する
🧭 運用のポイント
切り替え手順と失効確認の運用を決めておくと、証明書が原因の障害を防ぎやすくなります。
ローテーション
- 有効期限前に新旧を並行掲載し、猶予期間を取って切り替える
- メタデータを先に更新し、IdP/SP双方で同期する
- 公開鍵ピン留めをしている場合、デプロイ順序に注意
失効確認
- CRL/OCSPの適用は信頼モデルによる。メタデータの鍵を直接信頼する運用とPKIによる証明書検証を混同しない
- 時刻同期を維持し、Assertionの期限とメタデータの期限を確認する
- テスト/本番で証明書を取り違えないよう分離管理する
📑 メタデータでの扱い
メタデータはIdP/SP双方の真実のソース。用途と有効期限が正しく載っているかを定期的に確認します。
チェックポイント
- KeyDescriptorのuseが用途と一致するか。省略時は署名・暗号化の両用途を表す
- 証明書の有効期限とSubject/Issuerが期待通りか
- ds:X509Certificateには証明書のBase64表現を入れ、PEMのBEGIN/END行を入れない
署名付きメタデータの扱い
メタデータ自体の署名を検証し、信頼できる経路で配布することが推奨されます（OASIS Metadata仕様より）。
- 署名付きメタデータは事前に信頼した鍵で検証する。未署名を受け入れる場合も、合意した安全な配布経路で真正性を確認する
- 配布URLを固定し、改ざん検知のため定期的に署名検証を行う
- entityID の一意性を担保し、意図しないエンティティと混在させない
🧾 必須運用と任意運用の整理
どこまで必須にするかは要件次第。最低限の検証は必須、そのほかは環境に合わせて決めます。
必須（実質必須）
- IdP→SPのResponse/Assertion署名検証（IdP署名証明書で必ず検証）
- 署名検証鍵を安全に共有する。メタデータ配布か製品の手動登録かは構成による
要件次第（任意/推奨）
- Assertionの暗号化はブラウザ等から属性を隠す要件や連携ポリシーで決める。TLSの代わりにはならない
- SP発行メッセージの署名（AuthnRequest/LogoutRequestなど）。セキュリティ要件で必須化するケースも
- 証明書の有効期限・失効判定は採用する信頼モデルと製品の仕様に合わせる
仕様と関連する解説
OASIS SAML metadata / OASIS Metadata Interoperability Profile。Metadata Interoperability Profileでは、信頼済みメタデータ内の鍵に追加の証明書期限・CRL/OCSP検証を課しません。侵害鍵はメタデータから除去し、更新を行き渡らせます。TLSサーバー証明書の検証とは区別してください。
関連するSAML解説