証明書チェーンが信頼されるとは？中間証明書の欠落・確認方法・診断基準

証明書チェーンが信頼されるとは

証明書チェーンが信頼されるとは、サーバー証明書から中間証明書を経て、広く信頼されたルート認証局（ルートCA）まで、署名の連鎖（証明書チェーン）を正しくたどれる状態のことです。証明書自体が有効期間内でホスト名が一致していても、サーバーが中間証明書を送っていない、あるいは信頼されていない認証局が発行した証明書を使っている場合、利用者の環境によっては接続エラーになります。

「自分のパソコンのブラウザでは表示できるのに、スマートフォンや外部システムからはエラーになる」という問題の多くは、このチェーンの不備が原因です。セキュリティAIチェッカーでは重大度high、重み4の項目です。

証明書チェーンの仕組み

TLSハンドシェイクでは、サーバーが「サーバー証明書＋中間証明書」をまとめて送り、クライアントは手元のルート証明書までの署名を検証します。ルート証明書はクライアント側にあるので、サーバーが送る必要はありません。

中間証明書の欠落はなぜ見落とされやすいのか

ブラウザが不足を補ってしまう

ブラウザによっては、サーバーが送らなかった中間証明書を、過去に訪れたサイトから得たキャッシュや、証明書内のAIA（Authority Information Access）拡張に書かれた取得先から補って検証を通すことがあります。そのため、担当者のパソコンでは問題なく表示され、不備に気づかないまま運用されがちです。

一方、Node.js（OpenSSL）、多くのプログラミング言語のHTTPクライアント、一部のスマートフォンや組込み機器は、送られてきた証明書と手元のルート証明書だけで検証します。中間証明書が欠けていれば、UNABLE_TO_VERIFY_LEAF_SIGNATURE（unable to verify the first certificate）などのエラーで接続を拒否します。セキュリティAIチェッカーはNode.jsで接続するため、中間証明書の欠落を「利用者の一部が接続できない状態」として検出できます。

「信頼されない」その他の原因

• 自己署名証明書：検証環境用の証明書を本番に置いてしまったケース。
• 私設CA・組織内CAの証明書：庁内ネットワーク向けに発行した証明書を、インターネット公開サーバーに流用したケース。庁内端末には私設CAのルートが配布されているため、庁内からは正常に見えます。
• ブラウザやOSが信頼を取り消した認証局：ルートプログラムから除外された認証局の証明書は、有効期間内でも信頼されなくなります。
• チェーンの順序誤りや別の中間証明書の混入：証明書ファイルの結合順を誤ったり、更新前の中間証明書を残したりすると、クライアントによって検証に失敗します。

よくある誤解

• 「ルート証明書もサーバーから送るべき」：不要です。クライアントは自分の信頼ストアにあるルートしか信頼しないため、送っても検証結果は変わらず、通信量が増えるだけです。
• 「ブラウザで鍵マークが出ているから問題ない」：前述のとおり、ブラウザが不足を補っている可能性があります。必ずコマンドラインや外部ツールでチェーンを確認してください。

なお、有効期間とホスト名の一致は「TLS証明書が現在有効」、失効確認の仕組みは「OCSP Stapling」の項目で扱います。

証明書チェーンが信頼されるの診断基準（セキュリティAIチェッカー）

取得方法

• Node.jsの https.request を rejectUnauthorized: true で使用し、Node.jsに組み込まれたMozillaのルート証明書群（tls.rootCertificates）を信頼の起点として、サーバーが送った証明書チェーンを検証します。AIAによる中間証明書の自動取得は行いません。
• リダイレクトの各段階のHTTPS接続すべてで、同じ検証を行います。

判定条件

• チェーン検証に失敗した場合、検証を無効化して接続を続けることはせず、診断を中断します。したがって、レポートが表示されてこの項目が○であれば、少なくともMozillaのルート証明書群を基準にした検証は成立しています。
• この項目は「公的に信頼されたチェーンが成立するか」を見るもので、証明書の失効、OCSP Stapling、鍵長や署名アルゴリズムの強度までは評価しません（OCSP Staplingは別項目）。
• HTTPのみのサイトは対象外ですが、「HTTPSで配信されている」が×になります。

自治体サイトでの判定例

証明書チェーンが信頼されないとどんなリスクがあるか

• 一部の利用者が閲覧できない：中間証明書の欠落は、古いスマートフォン、組込みブラウザ、アプリ内ブラウザなどで接続エラーを招きます。担当者の環境で再現しないため、問い合わせが来ても原因の特定が遅れがちです。
• 機械連携の停止：オープンデータの取得、RSSの配信、他システムからのAPI連携、検索エンジンや翻訳サービスのクローラーなど、プログラムからのアクセスが失敗します。
• 警告を無視する習慣の形成：自己署名証明書などで警告が常態化すると、利用者が警告を無視することに慣れ、中間者攻撃による偽証明書を見分けられなくなります（CWE-295）。
• HSTS下での完全停止：HSTSが有効なサイトでチェーン検証に失敗すると、ブラウザは警告を回避する手段を提供しません（RFC 6797 §12.1）。

証明書チェーンの設定方法（Apache・nginx・IIS・Vercel）

1. 正しい「フルチェーン」ファイルを設定する

認証局から受け取った中間証明書を、サーバー証明書の後ろに結合した「fullchain」を設定します。順序は「サーバー証明書 → 中間証明書（発行元に近い順）」です。ルート証明書は含めません。

# 結合例（ファイル名は認証局の配布物に合わせる）
cat server.crt intermediate.crt > fullchain.pem

Apache 2.4.8以降

SSLCertificateFile    /etc/ssl/certs/fullchain.pem
SSLCertificateKeyFile /etc/ssl/private/server.key
# 2.4.8未満では SSLCertificateChainFile で中間証明書を指定

nginx

ssl_certificate     /etc/ssl/fullchain.pem;  # 中間証明書を含める
ssl_certificate_key /etc/ssl/server.key;

IIS：中間証明書をWindowsの「中間証明機関」ストアにインポートします。PFXに中間証明書を含めてインポートすると、ストアにも登録されます。インポート後にバインドの証明書を選び直し、IISまたは該当サイトを再起動します。

Next.js（Vercel）／CDN：マネージド証明書を使っている場合、チェーンは事業者が管理します。独自に証明書をアップロードする方式のときは、アップロード画面で中間証明書の欄を必ず埋めます。

2. 公開サーバーには公的CAの証明書を使う

庁内CAや自己署名の証明書は、インターネット公開サーバーで使わないでください（ASVS V12.2.2）。

3. 証明書チェーンの確認方法

# サーバーが送っているチェーンを表示（"Certificate chain" 以下に s:/i: が並ぶ）
openssl s_client -connect www.city.example.lg.jp:443 -servername www.city.example.lg.jp -showcerts </dev/null

# 検証結果の確認（"Verify return code: 0 (ok)" が正常）
openssl s_client -connect www.city.example.lg.jp:443 -servername www.city.example.lg.jp </dev/null 2>/dev/null \
  | grep "Verify return code"

# Node.js で本診断と同じ条件の検証を確認
node -e "require('https').get('https://www.city.example.lg.jp/',r=>console.log(r.statusCode)).on('error',e=>console.log(e.code))"

openssl s_client で「Certificate chain」にサーバー証明書1枚しか表示されず、Verify return code: 21 (unable to verify the first certificate) となる場合は、中間証明書が欠けています。

4. 運用チェックリスト

サイトを壊さないための注意点

• 証明書の更新時に認証局の中間証明書が変わることがあります。更新のたびに、新しい証明書に対応する中間証明書を使ってfullchainを作り直してください。古い中間証明書を流用すると、チェーンが成立しない場合があります。
• 設定変更後は apachectl configtest、nginx -t で構文を確認し、問題がなければ再読み込みします。
• 複数台のサーバーやロードバランサーで証明書を配布している場合、全台で同じfullchainが使われているかを確認します。1台だけ欠落していると、アクセスのたびに結果が変わり、原因の切り分けが難しくなります。

よくある質問（FAQ）

参考資料

• OWASP ASVS 5.0.0 V12 Secure Communication
• OWASP WSTG-CRYP-01 Testing for Weak Transport Layer Security
• Node.js TLS ドキュメント（既定のCAストア、証明書エラーコード）
• RFC 6797 HTTP Strict Transport Security（§12.1 No User Recourse）
• IPA「TLS暗号設定ガイドライン」
• Vercel Docs「Encryption and TLS」

「証明書チェーンが信頼される」と関連する診断項目

• TLS証明書が現在有効critical
• OCSP Staplinglow
• HTTPSで配信されているcritical
• 証明書期限の余裕high
• HTTPからHTTPSへ転送high
• HSTSが設定されているhigh
• HSTSの有効期間medium
• HSTSをサブドメインにも適用medium