TLS証明書の有効期間は急速に短縮されており、これによりすべての組織が更新、検証、および障害防止の方法を変更しています。Let’s Encryptは、90日間の証明書から45日間の証明書へ（段階的なロールアウトで）移行し、認可の再利用期間を大幅に短縮することを確認しました。同時に、CA/Browser Forumの投票SC-081v3は、最終的に2029年3月15日までに公開TLS証明書の有効期間を47日に制限する、より広範な業界スケジュールを採用しました。
数十または数千の証明書を管理するチームにとって、本当の問題は「短い証明書」ではありません。更新の速度向上、検証の再利用制限の強化、そして運用ミスの許容範囲の大幅な縮小です。ウェブサイトの監視とアラートは必要不可欠になります。
SSL/TLS証明書の有効期間における変更点とは？
45日間のポリシー（Let’s Encrypt）
Let’s Encryptは現在90日間有効な証明書を発行しており、2028年までにこれを45日に短縮します。これは突然の「スイッチ切り替え」ではありません。Let’s EncryptはACMEプロファイルを使い段階的に展開しています：
日付 | 変更内容 | 認可の再利用期間 | 影響を受けるプロファイル |
|---|---|---|---|
2026年5月13日 フェーズ1 | オプトインの tlsserverプロファイルが45日間の証明書を発行 | 30日（変更なし） | 初期導入者/テスト |
2027年2月10日 フェーズ2 | デフォルトの classicプロファイルが64日間の証明書に移行 | 10日間に短縮 | tlsserverまたはshortlived以外の全ユーザー |
2028年2月16日 フェーズ3 | デフォルトの classicプロファイルが45日間の証明書に移行 | 7時間に短縮 | デフォルトプロファイルの全ユーザー |
重要なポイント
認可の再利用期間は証明書の有効期間自体と同じくらい重要です。これは、以前のドメイン管理検証を再利用して追加の証明書を発行できる時間窓です。Let’s Encryptはこれを30日から2028年までにわずか7時間に短縮するため、確実なACME自動化が必須となります。任意ではありません。
業界標準：47日（CA/Browser Forum）
CA/Browser Forumの投票SC-081v3は、公開TLS証明書の最大有効期間を段階的に縮小するスケジュールを導入しました。200日（2026年）、100日（2027年）、そして47日（2029年）です。
Let’s Encryptの「45日」は業界の「47日」の最大値と完全に互換性があり、Let’s EncryptはCA/B Forumの要求より1年早くこの最終状態に到達する予定です。
なぜ証明書の有効期間が短縮されているのか？
有効期間の短縮は、4つの相互に関連した目標によるセキュリティと回復力の強化を目的としています：
- 侵害時の被害範囲の縮小：秘密鍵が盗まれたり誤発行された証明書があっても、短い有効期間により悪用される期間が制限されます。
- より効果的な失効エコシステム：短期間の証明書は失効処理の完璧さへの依存を減らし、Let’s Encryptは短期間の有効期間が失効技術の効率向上につながると指摘しています。
- 鮮度の高い検証データ：CA/Bの変更により、ドメインおよびIP検証の再利用期間も短縮され、2029年3月までに10日間となります。
- 自動化と機敏性の促進：ブラウザとルートプログラムは、自動化を明確に推奨しており、これにより短いライフサイクルでの障害を減らし、迅速なセキュリティ改善が可能になります。
証明書有効期間短縮のタイムライン
825日から45日への進展の実際のストーリーは以下の通りです：
最大有効期間 | 時代 | 主な要因 |
|---|---|---|
825日 | 2020年以前の旧最大値 | 業界での最大制限なし |
398日間 | 2020年9月以降 | Appleは2020年9月1日以降に発行された証明書に対し398日の最大期間を強制しました；非準拠の証明書は接続障害の原因となります |
90日間 | Let’s Encryptの標準（2014年〜2027年） | Let’s Encryptは「自動化ネイティブ」の期待を構築しました；Chromeのセキュリティチームは敏捷性と回復力のために自動化を強調しました |
45 / 47日間 | 2028年〜2029年の目標 | Let’s Encryptは45日間に達します（2028年2月16日）；CA/Bフォーラムは業界の上限を47日間に設定します（2029年3月15日） |
45日証明書の移行による業界全体への影響
これはLet’s Encryptだけの変更ではありません。Let’s EncryptはCA/ブラウザフォーラムのベースライン要件に沿って「業界全体と共に」動いていると明言しており、すべての公開信頼CAが同様の変更を行う予定です。
Let’s Encryptおよび他のCAへの影響
- 更新速度が標準の運用モードに：2029年までに、組織は実質的に継続的な更新サイクルの中で運用されます — 特に大規模の場合。
- 検証の再利用が大幅に縮小：ドメインおよびIP検証の再利用は2029年3月までに10日に短縮され、手動または断続的なプロセスは脆弱になります。
- ACMEと更新インテリジェンスの重要性向上：Let’s EncryptはACME更新情報（ARI）の利用を推奨し、クライアントがいつ更新すべきかを把握できるようにし、「60日ごと」のようなハードコードされた更新間隔は45日サイクルでは機能しなくなると警告しています。
- 新しい検証アプローチが登場：頻繁なドメイン検証の運用負荷を軽減するため、Let’s Encryptは2026年導入予定のDNS-PERSIST-01を開発中で、永続的なDNS TXTレコードの利用を可能にします。
45日証明書の運用上の課題
45日証明書は単に「更新が2倍の頻度になる」だけではありません。失敗モードが根本的に変わります：
- エラー許容のバッファが小さくなる：1回の更新の見逃しがユーザーに見えるダウンタイムに直結します。
- 運用要素の増加：ロードバランサー、CDN、Kubernetes Ingress、サービスメッシュ、APIゲートウェイ、レガシー機器など、すべて調整した更新が必要になる可能性があります。
- 検証における摩擦：2028年までにLet’s Encryptのクラシックプロファイルで認可の再利用時間が7時間まで短縮され、自動化されたDNS/HTTPチャレンジは「ベストエフォート」でなく堅牢である必要があります。
- インベントリの盲点：ほとんどの障害は「忘れられた」証明書に起因します — 非本番環境のエンドポイントが本番化されたもの、古いサブドメイン、パートナー管理のドメイン、または機器やミドルウェアに埋め込まれた証明書など。
- 変更管理の手間増加：より頻繁な証明書ローテーションにより、誤設定の可能性が高まります：誤ったチェーン、不完全なチェーン、ホスト名の不一致、一部ノードへののみの展開など。
これらの多くの失敗モードは証明書発行後、伝播、リロード、エッジキャッシュ、部分的ロールアウトの間に発生するため、チームは外部からの検証を追加すると活用できます：内部ログだけでなく、実際のクライアントが本番環境で受け取っているものを確認するチェックです。
証明書有効期限監視の重要性
Let’s Encrypt自体も証明書が期待通りに更新されない場合に警告を出すために十分な監視を推奨しており、SSL監視ツールの使用を奨励しています。実務では、監視が以下の問題を捕捉します：
- 静かに失敗した更新自動化;
- 再発行による「サイクル外」有効期限切れ;
- チェーンや発行者の変更;
- ホスト名の不一致や不完全な展開。
適切な監視なしでは、SSL証明書がブラウザに「接続はプライベートではありません」の警告を表示させ、SEOランクを一晩で下げ、訪問者のサイトアクセスを完全に遮断する可能性があります。影響は即時かつ測定可能で、約30日に一度更新される45日証明書では、静かな失敗をユーザーに見える障害になる前に検知する時間がかなり狭まります。
🔍 Dotcom-Monitorが証明書の有効性を維持する仕組み
Dotcom-MonitorのSSL証明書監視は、30以上のグローバルロケーションから定期的にチェックを行う、インテリジェントで常時稼働の証明書チェッカーとして機能します。ドメインを追加すると、実際の世界のユーザーが体験するのと同様に証明書の検証が開始され、単なるpingにとどまらず完全なTLSハンドシェイクを実行します。
監視された各ドメインまたはエンドポイントに対して、プラットフォームは自動的に以下を検証します：
- 証明書チェーンの整合性および発行者の正確性;
- 有効期限および残存日数のカウントダウン;
- SAN（Subject Alternative Name）およびホスト名の整合性;
- 不一致、無効な応答、信頼されていない発行者の可能性;
- 監視対象全デバイスの設定健全性。
すべての結果はリアルタイムで中央集約されたダッシュボードに表示され、インテリジェントな並べ替え・フィルター機能により、少数のドメインでも数百でもチームが迅速に問題点を把握できます。
45日サイクルにおける自動化リスク
証明書の有効期間短縮は、更新事象の頻度を増やし、それに伴い自動化失敗の可能性も高まります。45日サイクルでは、小さな運用上の問題がより早く、より頻繁に表面化します。
なぜ自動化だけでは45日サイクルで頻繁に壊れるのか
代表的な失敗ポイントは以下の通りです：
- DNS-01レコードの伝播が予想より遅い;
- CDNやWAFレイヤーによるHTTP-01チャレンジの遮断;
- 誤設定されたファイアウォールポリシーによる検証遮断;
- 再試行中に発動するACMEのレートリミット;
- 再起動時に証明書ディレクトリが消失するコンテナ;
- 静かに失敗するsystemdタイマー;
- 更新された証明書を再読込しないロードバランサー。
重要：
これらの問題は新しい問題になったわけではなく、緊急性を増した問題です。更新が2倍の頻度で動くと、これらの問題に遭遇する確率が比例して上がります。自動化は不可欠ですが、外部からの検知なしではライフサイクルの展開側の状態を盲目的に運用することになります。
🔍 Dotcom-Monitorが更新失敗を検知する仕組み
ACME自動化が静かに失敗すると—systemdタイマーが作動しなかった、DNSチャレンジがタイムアウトした、ロードバランサーが再読込しなかったなど—Dotcom-Monitorは連続する外部からの検証によってそれを検知します。証明書の有効期限が迫っている、または既に無効状態に入ったことを検知した瞬間にプラットフォームは即座に通知を送ります。内部の自動化ログが何を報告していようとも関係ありません。
通知はチームが既に使っているチャネルで配信されます：
- メール
- SMS
- Slack
- Microsoft Teams
- PagerDuty
- Webhook
カスタマイズ可能な警告閾値により、警告は早すぎてアラート疲れを招いたり、遅すぎて障害を防げなかったりすることなく、ちょうど良いタイミングで届きます。各警告は証明書、ドメイン、推奨される対応を明確に識別します。
隠れたリスク：更新後の展開ドリフト
更新成功は必ずしも展開成功を意味しません。分散環境では、この2つの状態は頻繁に乖離します。この乖離を展開ドリフトと呼び、TLS失敗モードの中で最も過小評価されているものの一つです。よくある原因は：
- オリジンの更新後もCDNがキャッシュされた証明書チェーンを提供し続ける;
- 複数地域のロードバランサーが一地域だけ更新される;
- Kubernetesポッドが更新済みTLSシークレットをリロードしない;
- リバースプロキシが新しいキーぺアを拾うために完全再起動を必要とする;
- ロールイングインフラの更新中にエッジノードの遅延が発生する。
重要ポイント
90日サイクルではドリフトは偶発的な出来事でしたが、45日サイクルでは明確に監視しなければ統計的により発生しやすくなります。短い有効期間は単純に更新頻度を増やすだけでなく、分散システム全体の伝播リスクも高めます。
なぜ外部証明書監視が最も信頼できる独立したチェックなのか
内部システムは更新パイプラインを監視し、外部システムはユーザー体験を監視します。これらの視点は多くの場合で乖離します。内部監視はACMEクライアントの実行、証明書発行、ファイル記述を確認できますが、エッジで正しい証明書が提供されているか、すべての地域が更新されているか、信頼チェーンが完全かどうかを確認できないことが多いです。
外部監視はクライアントのように証明書を検証します：
- 完全なTLSハンドシェイクを実行;
- チェーンの整合性を検査;
- SANおよびホスト名の整合を確認;
- 予期しない発行者やチェーンの変化を検出;
- 本番環境での有効期限を確認;
重要ポイント
特に重要なのは、外部監視は地理的に分散したロケーションから実行できるため、一拠点の内部監視では見逃しやすい地域レベルのドリフトやCDNエッジの不整合を検出する助けとなります。外部からの検証は、更新成功が正しく本番環境に反映されたかを最も確実に検証する方法です。
🔍 Dotcom-Monitorがあなたの自動化スタックに必要な独立チェックである理由
Dotcom-Monitorは世界中のサーバーで証明書をチェックし、国際的なトラフィックに正確な結果を提供し、証明書のホスティング場所に関わらず継続的なSSL監視を保証します。このグローバルなリーチは、CDNエッジ、多地域ロードバランサー、Kubernetesクラスターなど分散インフラを持つウェブサイトに特に重要で、オリジンでは証明書が正しく更新されていても、すべてのエッジノードにまだ伝播していない場合があります。
プラットフォームはエッジネットワーク、ロードバランサー、CDN全体での監視をサポートし、展開ドリフトが最も頻発するレイヤーで機能します。また、スケジュールされたグローバルレポート（日次、週次、月次）でタイムライン、ステータス更新、監視中デバイスの証明書健康状態をまとめ、手動作業を減らしチーム間の可視性を強化します。
コンプライアンス重視の組織向けに、監査に必要な証明書詳細、発行者情報、信頼チェーン記録、エラーログなどを含むエクスポート可能な監査レポートも生成します。
短命証明書のための監視戦略の構築
45日証明書のライフサイクルには単なる有効期限アラート以上のものが必要です。監視は「期限前に思い出させる」から「正しい展開を継続的に検証する」へ進化すべきです。
完全なインベントリから開始
ほとんどの障害は盲点から発生します。監視にはすべての公開ウェブサイトやサブドメイン、APIやパートナー向けエンドポイント、CDNエッジやオリジンサーバー、外部に公開された内部ゲートウェイ、レガシーインフラおよび機器を含めてください。監視されていないエンドポイントは管理されていないリスクです。
複数のグローバルロケーションからの監視
単一のプローブでは地域的なドリフト、CDNのエッジの不整合、ISP特有の信頼チェーンの問題を検出できません。グローバルな検証により、どこでもチェーンの正確性、地域間の一貫性、エッジ伝播の成功が保証されます。Dotcom-Monitorは30以上のグローバルロケーションからチェックを行い、これらの多地点チェックをスケジュール上で繰り返しかつ一貫して実施できます — 初期設定後の手動作業は不要です。
有効期限以上の検証を行う
有効期限は失敗モードの一つに過ぎません。監視は以下も検証すべきです：
- 完全な信頼チェーンと正しい中間CA；
- SAN/ホスト名の正確性；
- 暗号とプロトコルの互換性；
- 予期しない発行者の変更。
更新後の検証をトリガーする
更新イベントは即時に本番検証、多地域の証明書比較、チェーン検証チェックを自動的に開始すべきです。ドリフトは多くの場合、有効期限前ではなく更新直後に現れます。
45日ライフサイクルのための段階的アラートを使用する
まとめ：45日時代の監視と検出
短命証明書はセキュリティ姿勢を向上させます。その一方で運用許容度を圧縮し、設定や展開のエラー検出の窓を縮小します。自動化は依然として必須ですが、検証なき自動化は大規模になると脆弱になります。
45日時代における真の運用シフトは以下です：
- 更新は継続的に行われる；
- 検証の再利用期間は短縮される；
- 展開ドリフトが統計的により頻繁になる；
- 外部検証が必須となる
Dotcom-MonitorのSSL証明書監視はまさにこの環境を念頭に設計されています。30以上の世界中のロケーションからチェーンの正確性、ホスト名の整合性、有効期限状況、グローバル展開の一貫性を外部から検証し、リアルタイムアラートをSlack、Teams、メール、SMS、PagerDutyにお届けします。単一のドメイン管理から数百にわたる場合でも、プラットフォームはすべての証明書を整理、追跡、検証を自動的に行います。
TLSのライフタイムが業界全体で短縮される中、検出と検証はオプションの保護策ではなく基本的な管理手段となります。以下は内部自動化のみでは実現できないDotcom-Monitorの提供価値です：
機能 | それが解決する課題 |
|---|---|
30以上のグローバル監視ロケーション | 地域ドリフトやCDNエッジの不整合を検出 |
完全なTLSハンドシェイク検証 | 内部ログではなく実際のユーザーの受信状況を確認 |
チェーン＆発行者の検証 | 不完全なチェーン、誤った中間証明書、予期しない発行者の変更を検出 |
カスタマイズ可能な有効期限アラート閾値 | 45日間のライフサイクルに合わせて調整された、20日、10日、5日の段階的警告 |
Slack、Teams、PagerDuty、SMSアラート | 適切なチャネルを通じて適切な人物に瞬時に届く |
自動スケジュールレポート | 発行者、チェーン、アルゴリズム、およびエラーの詳細を含む監査準備済みエクスポート |
Edge、CDN、ロードバランサー対応 | デプロイメントのズレが最も頻繁に発生する正確なレイヤーを監視 |
集中管理型マルチドメインダッシュボード | 数十または数百の証明書を管理するチームのための単一ビュー |
FAQ: Let's Encrypt 45日間証明書の有効期限切れ
tlsserver ACME プロファイルは2026年5月13日に開始され、デフォルトの classic プロファイルは2028年2月16日に45日間に達します。変更は各本番日のおよそ1ヶ月前にステージング環境に展開されます。