証明書期限の余裕とは？SSL/TLS証明書の更新時期・有効期間短縮への対応・診断基準

証明書期限の余裕とは

証明書期限の余裕とは、Webサイトが使うTLS（SSL）証明書の有効期限までに、十分な残り日数があるかどうかを表す指標です。TLS証明書には有効期間（notBefore〜notAfter）があり、期限を過ぎるとブラウザは警告画面を表示して閲覧を事実上止めます。

この項目が見るのは「今この瞬間に証明書が有効か」ではなく、**「期限まで十分な余裕があり、更新が計画どおり回っているか」**です。今この瞬間の有効性は「TLS証明書が現在有効」、チェーンの信頼性は「証明書チェーンが信頼される」で別に判定します。

有効期間と期限切れのしくみ

• 証明書の notAfter（Node.js では valid_to）を過ぎると、ブラウザは NET::ERR_CERT_DATE_INVALID などのエラーを表示します（notBefore／notAfter は RFC 5280 で定められたX.509の項目です）。
• 398日（または200日）の商用証明書は手作業で更新されることが多く、担当者の異動や予算執行の遅れで期限切れが起こりやすい傾向があります。

証明書の有効期間はどれだけ短くなるのか

最大有効期間の短縮スケジュール（Ballot SC-081v3）

CA/Browser Forum の Ballot SC-081v3（2025年4月可決）により、証明書の最大有効期間は段階的に短縮されます。

同じ Ballot により、ドメイン認証結果の再利用期間も最終的に10日まで短縮されます。手作業の更新は年に数回以上必要になるため、ACMEによる自動化がほぼ前提になります。

Let's Encrypt の短期化

• Let's Encrypt は2026年1月15日に、約6日間（160時間）の短期証明書（shortlived プロファイル、任意選択）を一般提供しました。
• 標準の証明書も90日から45日へ段階的に短縮しています。2026年5月13日に任意選択の tlsserver プロファイルが45日へ移行済みで、既定の classic プロファイルは2027年2月10日に64日、2028年2月16日に45日へ移行予定です。

このため「残り30日を切ったら警告」という固定の閾値だけでは、正しく自動更新されている短期証明書を誤って警告してしまいます。セキュリティAIチェッカーは、証明書自身の有効期間に比例した閾値で判定します。

更新タイミングの目安

• Let's Encrypt は、ARI（ACME Renewal Information）を証明書ごとに1日2回以上確認し、ARIが勧める時期に更新することを推奨しています。そのうえでARIの補完（バックストップ）として、「残りの有効期間が全体の3分の1になった時点（有効期間の約3分の2が経過した時点）で自動更新する」ことを推奨しています。90日証明書なら残り約30日、45日証明書なら残り約15日が更新の目安です。
• 有効期間が10日未満の短期証明書については、有効期間の半分が経過した時点（6日証明書なら残り約3日）での更新が推奨されています。

閾値を有効期間に比例させる理由

監視の閾値は「更新が予定どおり行われていれば到達しない残り日数」に置くのが合理的です。90日証明書を残り30日で更新する運用では、残り日数は通常30〜90日の範囲にあり、残り22.5日を下回れば更新が1週間以上遅れていると判断できます。

同じ考え方を47日証明書に当てはめると、更新目安は残り約15日、警告は残り12日弱になります。固定の30日を全証明書に適用すると、45日・47日の証明書は発行から2週間余りで常に警告となり、利用者は警告を無視するようになります。本診断は、有効期間の4分の1（上限30日）を警告、8分の1（上限7日）を不合格の目安としています。

証明書の期限についてよくある誤解

• 「サーバーの証明書ファイルを更新したから大丈夫」：それだけでは不十分です。Webサーバーの再読み込み、ロードバランサーやCDNへの証明書の差し替え、すべての冗長構成への反映が必要です。
• 「サーバー証明書が有効ならチェーンも大丈夫」：中間証明書の期限は別に存在します。サーバー証明書が有効でも、古い中間証明書を送り続けているとチェーンが壊れることがあります（チェーンの信頼性は別項目で判定）。
• 「期限通知メールが来るから安心」：通知メールに頼る運用は危険です。Let's Encrypt は2025年6月で期限通知メールを終了しており、監視は利用者側で用意する必要があります。

証明書期限の余裕の診断基準（セキュリティAIチェッカー）

取得方法

最終URLがHTTPSの場合、対象ホストの公開IPへ Node.js の tls.connect で直接接続し（SNI付き、証明書検証あり、TLS 1.2以上、5秒タイムアウト）、getPeerCertificate() で得た valid_from と valid_to を使います。追加のHTTP取得はありません。

閾値の計算方法

• 残り日数 remaining ＝（valid_to − 現在時刻）÷ 1日（小数を切り捨てない実数）
• 証明書の有効期間 lifetime ＝（valid_to − valid_from）÷ 1日（実数。取得できない場合は90日とみなす）
• 警告閾値 warnDays ＝ min(30, lifetime ÷ 4)
• 不合格閾値 failDays ＝ min(7, lifetime ÷ 8)

閾値も切り捨てずに実数のまま比較するため、有効期間が数日の短期証明書でも閾値が0日に潰れません。

判定条件

根拠欄には「証明書期限まで約N日です（有効期間約M日、警告W日未満・不合格F日以下）。」の形で、残り日数（小数切り捨て）・有効期間（四捨五入）・適用した閾値（小数第1位まで）を表示します。90日証明書なら「警告22.5日未満・不合格7日以下」、6日証明書なら「警告1.5日未満・不合格0.8日以下」です。判定は、表示用に丸める前の実数で行います。

得点への影響

期限切れの証明書は通常、診断の最初のHTTPS取得自体が失敗するため、実際に×が出るのは「期限は切れていないが数日以内に切れる」ケースが中心です。

自治体サイトでの判定例

証明書期限の余裕がないとどんなリスクがあるか

• 閲覧停止と警告慣れ：期限切れになると、住民は警告画面を見て閲覧をあきらめるか、警告を無視する習慣を身につけます。後者は、本物の中間者攻撃の警告も無視される土壌になります。
• 繁忙期の情報提供停止：災害時・選挙時など、自治体サイトへのアクセスが集中する時期に期限切れが起きると、情報提供そのものが止まります。
• 大規模障害の原因：証明書の期限切れは大規模障害の原因として繰り返し報告されています。2020年2月の Microsoft Teams の障害は、認証用証明書の期限切れが原因でした。米国会計検査院（GAO）の Equifax 侵害に関する報告書では、通信監視装置の証明書が期限切れだったため、不正な通信の検知が遅れたことが指摘されています。
• 二次障害：期限切れ直前の慌ただしい手動更新では、誤った鍵・チェーンの配置や、旧証明書の残存といった二次障害も起こりやすくなります。

証明書の期限切れを防ぐ方法（自動更新・監視・Apache・nginx・IIS）

1. 自動更新（ACME）を基本にする

# certbot（Let's Encrypt）: systemd タイマーまたは cron で1日2回実行
certbot renew --quiet --deploy-hook "systemctl reload nginx"

# 更新処理の予行（実際には更新しない）
certbot renew --dry-run

ARI対応のACMEクライアント（certbot 4.1以降、lego、Caddy など）を使うと、CAが推奨する時期に更新されます。更新後のサーバー再読み込み（deploy-hook）を忘れないことが重要です。

2. 手動更新の証明書は台帳と多段通知で管理する

• 証明書台帳（ホスト名、CA、期限、担当課、更新手順、予算科目）を作り、期限の60日前・30日前・14日前・7日前に通知します。
• 2026年3月15日以降、新規発行の最大有効期間は200日です。年1回の手作業を前提にした契約・予算は見直しが必要です。

3. 外部から期限を監視する

# 残り期限を表示
echo | openssl s_client -connect www.city.example.lg.jp:443 -servername www.city.example.lg.jp 2>/dev/null \
  | openssl x509 -noout -startdate -enddate

# 30日（2592000秒）以内に切れるなら終了コード1（監視スクリプト向け）
echo | openssl s_client -connect www.city.example.lg.jp:443 -servername www.city.example.lg.jp 2>/dev/null \
  | openssl x509 -noout -checkend 2592000

監視対象には、メインサイトだけでなく、サブドメイン（予約、オープンデータ、メールのWeb画面など）、ロードバランサーの各ノード、IPv4／IPv6の両方を含めます。

4. 構成別の注意

サイトを壊さないための注意点（ガードレール）

• 更新時に秘密鍵を毎回新しくする場合、HPKPのような鍵固定の仕組み（現在は非推奨）や、取引先システムでの証明書ピン留めがないか確認します。
• 中間証明書を含む完全なチェーン（fullchain）を配置し、更新後に SSL Labs 等でチェーンを確認します。
• DNSのCAAレコードで許可するCAを限定している場合、CAを乗り換えると更新が失敗します。CA変更時は「CAAレコード」を先に更新してください。
• 自動更新の失敗はログに残るだけで気づかれないことが多いため、更新ジョブの失敗通知と、外部からの期限監視の二重化を推奨します。
• 6日証明書のような短期証明書を採用する場合は、更新失敗が数日で障害に直結します。監視と再試行の仕組みを先に用意してください。

よくある質問（FAQ）

参考資料

• CA/Browser Forum Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods
• Let's Encrypt ブログ（2025年12月2日）：Decreasing Certificate Lifetimes to 45 Days（証明書の有効期間を45日へ短縮）
• Let's Encrypt ブログ（2026年1月15日）：6-day and IP Address Certificates are Generally Available（6日証明書とIPアドレス証明書の一般提供）
• Let's Encrypt ブログ（2025年1月22日）：Ending Support for Expiration Notification Emails（期限通知メールの終了）
• Let's Encrypt Integration Guide
• Certbot 4.1.0 Release（Let's Encrypt Community）
• OWASP ASVS 5.0.0 V12 Secure Communication
• OWASP WSTG-CRYP-01 Testing for Weak Transport Layer Security
• Node.js TLS (SSL) ドキュメント
• RFC 5280 Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• U.S. GAO「Data Protection: Actions Taken by Equifax and Federal Agencies in Response to the 2017 Breach」（GAO-18-559）

「証明書期限の余裕」と関連する診断項目

• TLS証明書が現在有効critical
• 証明書チェーンが信頼されるhigh
• CAAレコードlow
• OCSP Staplinglow
• HTTPSで配信されているcritical
• HTTPからHTTPSへ転送high
• HSTSが設定されているhigh
• HSTSの有効期間medium