TLS証明書が現在有効とは？期限切れ・ホスト名不一致の確認方法と診断基準

TLS証明書が現在有効とは

TLS証明書が現在有効とは、診断対象サイトのTLSサーバー証明書が「いま」有効である状態、すなわち有効期間内であり、接続したホスト名に対して発行された証明書であることを指します。証明書が期限切れ、または別のホスト名用であれば、ブラウザは全画面の警告を表示して閲覧を止めます。住民がサイトを見られなくなるだけでなく、「警告を無視して進む」習慣を植え付ける点でも重大です。

セキュリティAIチェッカーでは、標準的な証明書検証を有効にしたHTTPS接続が成立したことをもって「有効」と判断します。重大度はcritical、重みは5です。

証明書が「有効」であるための3つの条件

ブラウザやTLSライブラリは、少なくとも次の点を検証します。

1. 有効期間：現在時刻が証明書の notBefore と notAfter の間にあること。期限切れだけでなく、サーバー時計の誤りなどで「まだ有効になっていない」証明書も拒否されます。
2. ホスト名の一致：接続先ホスト名が証明書のSubject Alternative Name（SAN）に含まれること。WSTG-CRYP-01が述べるとおり、現在のブラウザはCommon NameではなくSANだけを見ます。city.example.lg.jp 用の証明書で www.city.example.lg.jp に接続すると不一致になります。
3. 信頼されたチェーン：信頼されたルート認証局まで署名をたどれること。これは「証明書チェーンが信頼される」の項目で詳しく扱います。

証明書の有効性がなぜ重要なのか

証明書の有効期間短縮（200日→100日→47日）

CA/Browser ForumはBallot SC-081v3（2025年4月可決）で、公開TLS証明書の最大有効期間を段階的に短縮しました。

従来の「年1回、担当者が手作業で更新」という運用は成り立たなくなり、更新漏れによる期限切れのリスクが高まっています。自動更新（ACMEプロトコル、CDN・クラウド事業者のマネージド証明書）の導入が事実上必須です。

HSTSとの関係（警告を回避できなくなる）

HSTSが有効なサイト（RFC 6797の「Known HSTS Host」）で証明書エラーが起きると、ブラウザは警告を出すだけでなく「無視して進む」選択肢を提供しません（RFC 6797 §12.1「no user recourse」）。HSTSは攻撃に強くなる一方、証明書の期限切れが即座に「誰も閲覧できない」障害に直結します。「HSTSが設定されている」の導入と、証明書の自動更新・監視はセットで考える必要があります。

期限切れ・ホスト名不一致が起きる典型的な原因

• 更新は済んでいるが、Webサーバーの再読み込みを忘れて古い証明書を配信し続けている。
• 複数台構成やロードバランサーの一部だけが古い証明書のままで、アクセスのたびに結果が変わる。
• ホスティング移転・CDN切替の際に、旧環境の証明書の自動更新が止まった。
• 担当者の異動で、契約更新や期限通知のメール宛先が引き継がれていない。

よくある誤解

• 「暗号化さえできれば自己署名証明書でもよい」：公開サイトでは不可です。ASVS V12.2.2は外部向けサービスに公的に信頼された証明書を求めています。
• 「期限が切れても暗号化は続くので問題ない」：ブラウザが接続を止めるため、利用者から見れば停止と同じです。
• 「wwwあり・なしのどちらかで証明書があれば十分」：両方のホスト名でアクセスされるなら、両方をSANに含める必要があります。転送元のホスト名でも、HTTPSで受ける以上は有効な証明書が必要です。

TLS証明書が現在有効の診断基準（セキュリティAIチェッカー）

取得方法

• Node.jsの https.request を rejectUnauthorized: true で呼び出し、SNIに対象ホスト名を指定して接続します。Node.jsの既定の検証は、Mozillaのルート証明書群（tls.rootCertificates）を信頼の起点にしたチェーン検証、有効期間の検証、tls.checkServerIdentity() によるホスト名（SAN）照合を含みます。
• リダイレクトをたどる途中のすべてのHTTPS接続で、同じ検証が行われます。

判定条件

• 証明書が無効な場合、この診断は「× 要改善」を記録するのではなく、診断そのものを完了できずにエラーを返します。安全側に倒すため、検証を無効化して接続を続行することはしません。結果として、レポートが表示されていてこの項目が○であれば、その時点で証明書は「有効期間内・ホスト名一致・信頼チェーン成立」の3条件を満たしています。
• HTTPのみのサイトは対象外ですが、「HTTPSで配信されている」（transport.https、重み5）が×になるため、スコア上の不利は解消されません。
• 失効（revocation）はこの項目では確認しません。Node.jsの既定の検証はOCSPやCRLによる失効確認を行わないためです。
• 期限までの残り日数は「証明書期限の余裕」で評価します（残り30日未満で△、7日以下で×。有効期間が短い証明書では、有効期間の4分の1未満・8分の1以下に読み替えます）。

自治体サイトでの判定例

TLS証明書が無効だとどんなリスクがあるか

• サービス停止と同等の影響：期限切れが発生すると、ブラウザに警告が出て住民が閲覧できなくなります。災害時や申請期限の直前に起きれば影響は深刻です。
• 警告慣れ（警告疲れ）：自治体サイトで頻繁に証明書警告が出ると、住民が警告を無視して進むことに慣れてしまい、本物の中間者攻撃やフィッシングを見抜けなくなります。
• 中間者攻撃の成立：利用者が警告を無視して進むと、攻撃者の偽証明書による接続でも区別がつかず、通信の盗聴・改ざんが成立します（CWE-295）。
• 周辺システムへの波及：外部連携システム（オープンデータAPI、他システムからの取り込み）は証明書エラーで通信を中断するため、ブラウザ以外の連携も停止します。

TLS証明書を有効に保つ対策（自動更新・SAN・期限監視）

1. 自動更新の導入

• CDN・クラウドWAF・ホスティング事業者のマネージド証明書：最も確実です。CMS提供事業者に「証明書が自動更新される契約か」「誰が期限を監視するか」を確認します。
• ACME（Let's Encrypt等）：自前のサーバーではcertbotなどで自動更新し、更新後にWebサーバーを再読み込みする仕組みを入れます。

# certbot の自動更新を試験実行（実際には更新しない）
sudo certbot renew --dry-run

更新後にWebサーバーを再読み込みするフックは、/etc/letsencrypt/renewal-hooks/deploy/reload.sh に実行権限を付けて置きます。

#!/bin/sh
systemctl reload nginx

2. ホスト名（SAN）の網羅

利用者がアクセスしうるホスト名をすべてSANに含めます。たとえば city.example.lg.jp と www.city.example.lg.jp の両方です。

# SANの確認
openssl s_client -connect www.city.example.lg.jp:443 -servername www.city.example.lg.jp </dev/null 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName

3. Webサーバーでの証明書の指定（Apache・nginx・IIS・Vercel）

Apache

SSLCertificateFile    /etc/ssl/certs/fullchain.pem
SSLCertificateKeyFile /etc/ssl/private/privkey.pem

nginx

ssl_certificate     /etc/ssl/fullchain.pem;   # サーバー証明書＋中間証明書
ssl_certificate_key /etc/ssl/privkey.pem;

IIS：「サイトのバインド」で443のバインドを編集し、更新後の証明書を選択します。証明書を更新しても、バインドが古い証明書を指したままだと期限切れになるため、更新手順にバインドの変更を含めます。

Next.js（Vercel）：独自ドメインの証明書は自動発行・自動更新されます。DNSのCNAME/Aレコードが外れると更新に失敗するため、DNSを変更したときはダッシュボードで証明書の状態を確認します。

4. 期限監視と有効期限の確認方法

• 自動更新でも失敗はありえます。外部監視サービスや内部スクリプトで、期限の30日前・14日前・7日前に通知する体制をつくります。
• セキュリティAIチェッカーの「証明書期限の余裕」も定期診断に組み込み、30日以下になったら担当者へ連絡します。

# 期限日の確認
echo | openssl s_client -connect www.city.example.lg.jp:443 -servername www.city.example.lg.jp 2>/dev/null \
  | openssl x509 -noout -enddate

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

• 証明書を差し替える際は、秘密鍵と証明書の組み合わせが一致しているかを事前に確認します（不一致だとWebサーバーが起動しません）。設定変更後は apachectl configtest や nginx -t で構文を確認してから再読み込みします。
• HSTSを有効にしているサイトで証明書が切れると、利用者は警告を回避できません。更新作業は期限ぎりぎりではなく、余裕をもって行います。
• 仮サーバーや検証環境の自己署名証明書を、本番の公開ホスト名に誤って配置しないよう、配置先と証明書の対応を一覧で管理します。

よくある質問（FAQ）

参考資料

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

「TLS証明書が現在有効」と関連する診断項目

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