TLS証明書チェーンは、何をつないでいる？
証明書の期限はまだ先なのに、ブラウザが警告を出す。別のPCでは開けるのに、ある端末だけ失敗する。証明書は期限だけで合否が決まるものではありません。一般的な公開HTTPSのCA署名付き証明書を例に、接続先の名前と信頼のつながりを分けて読んでいきます。
サーバー証明書から、信頼の起点へたどる
サーバー証明書には接続先の名前と公開鍵などが入り、発行CAが署名します。中間CAの証明書にも上位CAの署名があり、クライアントはそのつながりを検証して、あらかじめ信頼した起点へ到達できるか調べます。
3つの役割
ルート証明書が自己署名だから信用できる、という順序ではありません。信頼の起点は外から与える前提です。サーバーが知らないルート証明書を一緒に送っても、受信しただけで信用されません。RFC 5280 §6.1.1は、この起点を検証処理への入力として扱います。
| 役割 | 見るポイント |
|---|---|
| サーバー証明書（leaf） | 利用するホスト名、公開鍵、有効期間、TLSサーバー用途 |
| 中間CA証明書 | 次の署名を検証するための公開鍵と、CAとしての制約 |
| 信頼の起点（trust anchor） | OSやアプリの設定などで事前に信頼されている情報 |
SANと、実際に開く名前を比べる
現在のTLSサービス名照合はSAN（Subject Alternative Name）を使います。CNだけが合うからよい、とは扱いません。RFC 9525 §6はDNS名とIPアドレスの照合を定め、旧RFC 6125を置き換えています。
SANがDNS:*.example.comの場合
ワイルドカードは左端のラベル全体だけに使えます。名前が一致しても、ほかの検証条件まで通ったことにはなりません。
| 開く名前 | 名前の照合だけを見た結果 |
|---|---|
| www.example.com | ワイルドカードを扱うクライアントなら一致 |
| example.com | 一致しない。左端の1ラベルがない |
| a.b.example.com | 一致しない。ワイルドカードは2ラベルをまたがない |
| 192.0.2.10 | DNS名のSANでは一致しない。IPアドレスのSANとの照合が必要 |
期限、署名、用途はそれぞれ別の条件
notBeforeとnotAfterは証明書の有効期間です。端末の時計がずれていると、まだ開始前、または期限切れと判断されることがあります。さらに署名、CAとしての制約、鍵の用途、名前の制約なども検証に関わります。証明書を表示できたことと、これらを通過したことを分けて読むと原因を絞れます。
期限内でも起こるエラー
検証の土台はRFC 5280 §6.1.3です。証明書の検証成功は、サイトの商品・文章・リンク先が安全であるという審査結果ではありません。
| 状況 | 調べる方向 |
|---|---|
| 名前が一致しない | URLのホスト名とSAN、接続先サーバーの証明書選択 |
| 発行元をたどれない | サーバーが送る中間証明書と、端末が信頼する起点 |
| 用途が合わない | Key Usage、Extended Key Usageなどの制約 |
| 失効や状態不明 | クライアントの失効確認方式とCAの提供情報 |
表示されたチェーンと、信頼できる経路は同じとは限らない
サーバーは通常、leafと必要な中間証明書を送り、信頼の起点はクライアント側に用意します。RFC 9846 §4.5.1では、TLS 1.3の証明書列は送信者の証明書を先頭とし、信頼の起点を表す証明書は省略できます。中間証明書が欠けると、端末の保持情報や経路構築の方法によって結果が違う場合があります。
IssuerとSubjectの名前だけでは足りない
前のIssuerと次のSubjectが一致すると、候補のつながりを追えます。ただし同じ名前の証明書でも、鍵や制約が違う場合があります。文字列の一致は、署名検証や信頼の確認の代わりにはなりません。TLSの接続ではさらに、相手が対応する秘密鍵を使えることをハンドシェイクで確かめます。証明書ファイルの読取りだけで相手の鍵保有を確かめたことにはなりません。
表示するツールと、接続を調べるツールを使い分ける
証明書デコーダーは、入力ファイルをサーバーへ送ってSAN・期限などを読み取ります。解析成功だけでは信頼チェーンや名前、失効は検証されません。公開証明書だけを使うと、秘密鍵を渡さずに項目を読めます。
SSL/TLSチェッカーの結果を読む
SSL/TLSチェッカーは、入力したホストへサーバーから接続します。検証付き接続に失敗しても、証明書を表示するために検証を外して再取得するため、「情報が表示された」と「検証が成功した」は別です。OCSP情報がある場合には外部のOCSP URLへ照会しますが、応答署名は検証しません。表示された結果はこのサーバーの時刻・信頼設定・接続経路による観測として読み、利用するブラウザの結果とも照合します。
仕様と、証明書を準備する手順
RFC 5280 §4.1.2.5：有効期間、RFC 9525 §6.3–6.4：名前照合、RFC 9846 §4.5.2：鍵保有を確かめるCertificateVerify。TLS 1.3の現行仕様RFC 9846はRFC 8446を置き換えています。発行申請の前はCSRと秘密鍵、ファイルの準備は証明書形式のガイド、失効状態はOCSPの結果の読み方へ。