SAMLの証明書とTLS証明書の違い

こんにちは、サイオステクノロジーの有村です。

WebサイトをHTTPS化する際は、「SSL証明書」、「TLS証明書」あるいは「サーバー証明書」と呼ばれる証明書を使用します。

一方、SAMLによるシングルサインオンを構築する際の IdP（Identity Provider）やSP（Service Provider）の設定でも「証明書」が登場します。
どちらもX.509証明書であるため、

• SAMLでもWebサーバーと同じ、なんらかの機関から発行された公的な証明書を用意すべきなのでは？
• 自己署名証明書は通常ブラウザで警告が出るのだから、SAMLでも使ってはいけないのでは？
• 証明書の有効期限が近づいたら、Webサーバーと同じようにすぐ更新しなければいけないのでは？

と考えてしまうと思われます。

しかし、WebサイトのHTTPS通信で使用する証明書と、SAMLで署名や暗号化に使用する証明書では、同じX.509証明書でも役割と信頼の確認方法が大きく異なります。

特に最近では、Webで利用される公的なTLSサーバー証明書の有効期間がさらに短縮されることが決まっています。

これはWeb PKIの安全性という観点では重要な変化ですが、同じ証明書なのでSAMLの署名証明書まで短期間で更新する運用にする必要があるのでしょうか。
この記事では下記について説明します。

• WebのTLS証明書では何を信頼しているのか
• SAMLの署名証明書では何を信頼しているのか
• 公的証明書の有効期間短縮に対してSAMLではどう考えるべきか
• 認証フェデレーションで利用するときの注意点

そもそも「証明書」とは

最初に、今回扱う証明書について簡単に整理します。
一般的なX.509証明書には、公開鍵のほか、

• 対象(Subject)
• 発行者(Issuer)
• Serial Number
• 有効期間
• 公開鍵
• 署名アルゴリズム
• 各種Extension

などの情報が含まれます。

秘密鍵と公開鍵はペアになっており、秘密鍵は所有者のみが保持します。
HTTPSでもSAMLでも、この公開鍵暗号の仕組みを利用しているという点では共通しています。
しかし 「その証明書を、誰が、どのような理由で信頼するのか」 が異なります。

WebのTLS証明書では何を確認しているのか

ブラウザで次のURLへアクセスするとします。

https://www.example.com/

WebサーバーはHTTPS通信によりTLSプロトコルを開始する際、自身のサーバー証明書をブラウザへ提示します。
しかし、ブラウザは受け取った証明書を無条件に信用するわけではありません。
簡略化すると、次の図のような関係になっています。

ブラウザやOSには、あらかじめ信頼するルートCA（認証局）の証明書、つまりルート証明書が登録されています。
ルート証明書のリストは、OSやブラウザのベンダー等が定める厳格な基準や審査に基づき、信頼の起点として登録され、OS等の仕組みにより定期的に更新されます。

Webサーバーから提示された証明書について、下記のように証明書チェーンをたどり、最終的にブラウザが信頼している認証局へ到達できるかを確認します。

それだけではありません。

例えば、

• 証明書の期間は有効か
• アクセスしているホスト名と証明書のSANが一致するか
• 証明書チェーンを正しく検証できるか

なども確認します。
これによって利用者はブラウザにより間接的に、自分がアクセスしているドメインは、第三者である認証局によって現在も確認されているドメインであると判断できます。

つまり、公開Webサイトの場合、 ブラウザとWebサーバーは事前に直接の信頼関係を持っていない状況で、世界中の不特定多数の利用者が、初めてアクセスしてもWebサーバーを検証できるようにするため、両者の間に認証局という第三者が必要になるのです。

これが一般的なWeb PKIの考え方です。

SAMLの署名証明書では何を確認しているのか

ではSAMLではどうでしょうか。
SAMLによるシングルサインオンでは、例えばIdPで利用者を認証した後、IdPからSPへSAML Responseが送信されます。

非常に単純化すると、次の図の流れになります。

IdPは自身が保持する秘密鍵を使用してSAML ResponseやAssertionへ署名します。
SPは対応する公開鍵を利用して、その署名が正しいことを検証します。

SAMLでは、IdPとSPの情報をSAMLメタデータによってあらかじめ共有できます。
IdPのメタデータには、たとえば署名検証に使用する証明書が登録されています。

概念としては次のようになります。

つまりSPは、この証明書が公的認証局から発行されているから信頼するのではなく、信頼するメタデータにすでに登録されているIdPの鍵だから、この鍵を署名検証に使用するという形で信頼関係を構築します。

ここがTLSとSAMLの非常に大きな違いです。

公的なTLS証明書の有効期間は短くなっている

この違いが今後さらに重要になる理由があります。
前述した通り、Webで使用される公的TLS証明書の有効期間は、長期的に短縮されていきます。
CA/Browser ForumのBaseline Requirementsでは次のスケジュールになっています。

2026年8月時点ですでに最大200日の期間に入っています。
2029年以降は47日となります。
このように証明書の有効期間が短くなれば、Webサーバーの証明書を人間が毎回手作業で取得し、設定ファイルを書き換えてサービスを再起動するという運用は現実的ではなくなっていきます。
そのため、WebサーバーについてはACMEなどを利用した証明書更新の自動化が重要になります。

一方でこれと同じ公的証明書をSAMLメタデータ用の証明書として利用するとどうなるでしょうか。

多くのSPでは認証フェデレーションが関連し、最終的に数十日ごとに下記の運用が必要になります。

Webサーバー内で完結する証明書更新と異なり、自組織だけで変更が完結しません。
そのため、Webサーバーと同じ感覚で証明書を選ぶことが、かえって運用上のリスクになる可能性があります。

フェデレーションもSAML Metadata用証明書では自己署名証明書への移行を案内

この問題は、フェデレーションを運営する組織からもすでに案内が始まっています。

例としてNIIはWebサーバー用証明書はブラウザで検証されるため有効期間短縮の影響を受け、ACMEによる自動更新が現実的である一方、SAMLメタデータ用証明書については、高頻度で証明書を発行して学認申請システムから変更申請することは非現実的であり、現状では自動化も難しく、失敗時のリスクが大きいと整理しています。

2025_UPKIキャラバン_サーバ証明書有効期間短縮とその対応
その対応として、自己署名証明書への移行を検討するよう案内されています。

これは今回説明してきたTLSとSAMLの信頼モデルの違いを考えると頷けるものと思います。
Web用証明書については下記の方向へ向かいます。

一方、SAML署名用証明書については下記の組み合わせになります。

同じサーバー上で利用する証明書であっても、用途に応じて異なる証明書を別々に管理するという考え方です。

自己署名証明書は「自分で自分を信用している」から使えるわけではない

ここで少し注意したいのが、「自己署名証明書」という言葉です。

自己署名証明書は、その名前のとおり自身の秘密鍵によって自身へ署名した証明書です。

そのため、発行者（Issuer）と対象（Subject）はイコールとなります。

しかし、SAMLで自己署名証明書を利用できる理由は、

「自己とはいえ署名してあるから信頼できる」わけではありません。

重要なのは、秘匿されている秘密鍵に紐づく公開鍵を、信頼できる経路で相手へ伝えることです。

認証フェデレーションを利用する場合、その役割を担うのがメタデータです。

つまり、下記に示す別の信頼関係があります。

証明書そのものを公的CAが保証するWeb PKIとは、信頼を確立する場所が違います。

したがって、SAMLで自己署名証明書を使用するときにも、どこから入手した鍵なのか分からない証明書を自由に登録してよいわけではありません。

メタデータそのものを安全に配布・管理する仕組みに、秘匿された秘密鍵に紐づく公開鍵を登録して初めて成立します。

自己署名証明書の作成方法は本ブログに限らず多数掲載されているメディアがございますので割愛しますが、無期限に近い証明書を作成していいわけではありません。

暗号アルゴリズムや鍵長に対する要求は将来変化しますし、秘密鍵が漏えいした場合には有効期間にかかわらず交換する必要があります。

「更新作業がほぼ不要になるほど長くする」のではなく、組織として管理可能な期間を定め、その期限が来る前に計画的にロールオーバーすることが重要です。

フェデレーションが推奨期間を提示している場合もございますので確認してください。

※NIIは3年を基準としています。

証明書を更新するときの注意

自己署名証明書を利用する場合でも、証明書の更新自体が不要になるわけではありません。

また、SAMLでは相手側が保持しているメタデータ内の公開鍵を使って署名を検証するため、IdP側の証明書だけを先に変更すると、相手側で署名を検証できなくなる可能性があります。

そのため、証明書を更新する際は下記のような形で、旧証明書から新証明書へ段階的に切り替える必要があります。

1. 新しい証明書を準備する
2. メタデータへ旧証明書と平行して新しい証明書を登録する
3. 連携先へ新しいメタデータが反映されたことを確認する（推奨された期間待機する）
4. IdP側で使用する証明書を新証明書のみに切り替える

このように、旧証明書から新証明書へ安全に切り替えることを、一般に証明書のロールオーバーと呼びます。

詳細な手順は利用するIdP製品やフェデレーションによって異なるため、本記事では割愛します。

重要なのは、自己署名証明書へ変更する目的が、「証明書更新という作業自体をなくすこと」ではないという点です。

Web PKIの証明書有効期間短縮とSAMLの運用を切り離し、SAMLの運用に適したタイミングで、計画的に証明書を更新できるようにすることが目的です。

また、実際に自己署名証明書を利用できるかどうかについては、接続する認証フェデレーションや個別のSPが定める要件も確認してください。

SAMLというプロトコル上利用可能であることと、特定サービスの運用ルール上許可されていることは別の問題です。

まとめ

今回は、Webで利用されるTLS証明書と、SAMLで使用する署名証明書の違いについて説明しました。

ポイントをまとめます。

• TLS証明書とSAML署名証明書は、どちらもX.509証明書を使用する
• Web（公開TLS証明書）では、不特定多数の利用者がサーバーを検証するために公的CAを利用する
• SAMLでは、メタデータなどによって連携相手の公開鍵をあらかじめ共有できる
• このためSAML署名証明書では、公的CAによる証明書が必須とは限らない
• 公開TLS証明書の最大有効期間は今後さらに短縮され、2029年には47日となる
• フェデレーション機関もSAML用証明書について自己署名証明書への移行を検討するよう案内を開始している
• 自己署名証明書にしても鍵更新は必要であり、メタデータを利用した適切なロールオーバーが重要

「証明書」という同じ種類のファイルを使っていると、つい同じルールで管理すべきものに見えてしまいます。

その証明書を何に使い、誰が、どのような仕組みで信頼するのかが特に重要です。

WebのTLSとSAMLではその仕組みが異なるため、証明書の選択や更新方法も、それぞれの用途に合わせて考える必要があります。

特に公開TLS証明書の有効期間短縮が進むこれからは、証明書を一律で運用するのではなく、それぞれの用途に適した証明書管理が重要になるでしょう。