Let's Encrypt 45日証明書：エンタープライズチームが知っておくべきこと

はじめに#

SSL証明書の状況は、ここ数年で最も大きな変化を迎えようとしています。世界最大の認証局であるLet's Encryptが、証明書の有効期間を90日から45日に移行します。数百〜数千のドメインを管理するエンタープライズチームにとって、これは単なる調整ではなく、SSL証明書管理のあり方そのものを変える根本的な転換です。

チームがまだSSLの更新を手作業で行っているなら、これからその負荷を強く感じることになります。年4回だった更新が8回になります。四半期ごとの対応で済んでいた作業が、終わりのない運用上の負担になります。タイムラインはすでに動き始めており、今準備を進めるインフラチームは移行をスムーズに乗り切れます。準備しない場合、障害リスクの増大と運用負荷の積み上がりに直面するでしょう。

この記事では、発表内容、その背景にある理由、移行のタイムライン、そしてエンタープライズチームが準備すべきことを整理します。

発表：Let's Encryptが証明書の有効期間を90日から45日に移行#

Let's Encryptは2026年半ばに、最大の証明書有効期間を90日から45日に短縮する意向を発表しました。この変更は、移行日以降に発行されるすべての新しい証明書に影響します。既存の証明書は自然な有効期限まで引き続き有効として扱われますが、更新は新しい45日間の有効期間が適用されます。

これは突然の判断ではありません。Let's Encryptは、サービス開始以来、段階的に証明書の有効期間を短くしてきました。商用のCAの多くが1年証明書を提供していた時期には90日から始めています。45日への移行は、業界全体が向かってきた「より短い有効期間の証明書」という流れをさらに進めるものです。

実務上の影響はシンプルです。Let's Encryptで保護されている各ドメインは、証明書の更新がこれまでの2倍の頻度で必要になります。更新プロセスをすでに自動化している組織では、移行は問題なく進む可能性があります。一方で、手作業のプロセスや半自動のワークフローに依存しているチームでは、運用上の影響は大きくなります。

なぜ起きるのか：セキュリティのベストプラクティス — 侵害の猶予期間を制限する#

証明書の有効期間を短くすることは、根本的にセキュリティの改善です。TLS証明書はすべて、潜在的な攻撃経路になり得ます。証明書の秘密鍵が侵害された場合、攻撃者は証明書の有効期限が切れるか、または失効されるまで、正当なドメインになりすますことができます。有効期間が長いほど、侵害の猶予期間も長くなります。

45日間の証明書は、現在の90日標準と比べてその猶予期間を半分に縮めます。もし初日（day one）に鍵が侵害された場合、最大の影響期間は90日ではなく45日になります。実際には影響期間はさらに短くなることが多いものの、上限が重要です。特に、侵害をすぐに検知できない可能性のある組織にとってはなおさらです。

さらに、失効（revocation）の議論もあります。CRLやOCSPによる証明書の失効は、これまで歴史的に信頼性が高くありませんでした。ブラウザは失効ステータスを一貫して確認していないことがあり、失効済みの証明書が引き続き信頼されるケースもあります。証明書の有効期間が短くなるほど、失効インフラへの依存が減ります。証明書が45日しか生きないなら、失効させることの重要度は下がります。そもそもすぐ期限切れになるからです。

セキュリティコミュニティは長い間、証明書の有効期間を短くすることを提唱してきました。Let's Encryptの動きは、セキュリティ研究者が何年も前から推奨してきた内容を、実運用に落とし込むものです。

Googleの並列CA/ブラウザフォーラム提案 — これはLet's Encryptだけの話ではない#

Let's Encryptは単独で動いているわけではありません。Googleは、CA/ブラウザフォーラムを通じて、業界全体の証明書の最大有効期間を45日まで引き下げるための並列提案を進めています。これはLet's Encryptだけでなく、DigiCert、Sectigo、GlobalSignのような商用CAを含むすべての認証局に影響します。

CA/Bフォーラムの提案はまだ議論中ですが、Googleの関与は、45日間の有効期間が単なるLet's Encryptの方針ではなく、業界標準になっていく可能性を示しています。最大のブラウザベンダーと最大の認証局がセキュリティ方針で足並みをそろえると、採用は後からついてくる傾向があります。

エンタープライズチームにとっては、これにより45日間の証明書時代はLet's Encrypt固有の懸念ではなくなります。現在、1年有効の商用証明書を使っているなら、その有効期間も同様に短くなることを見込むべきです。SSL証明書のエコシステム全体が短寿命証明書へ向かっており、その移行はすでに始まっています。

タイムライン：変更がいつ起きるのか、そして移行期間はどのようになるのか#

Let's Encryptは段階的な展開を示しています。正確な日付はまだ確定していませんが、想定されるタイムラインは、これまでの有効期間短縮と同様のパターンに沿う見込みです：

**発表フェーズ（現在）：** 公開コミュニケーション、ドキュメントの更新、ツールの準備。CertbotやACMEライブラリのようなクライアントソフトウェアは、新しい有効期間に対応するためのアップデートを受け取ります。

**段階的ロールアウト：** 45日間の有効期間はまず、新しい証明書の発行の一部に適用されます。これにより、Let's Encryptは問題の有無を監視し、更新（更新）パターンに関するデータを収集できます。

**全面的な適用：** Let's Encryptが発行するすべての新しい証明書には、45日間の最大有効期間が適用されます。既存の90日間の証明書は、その自然な有効期限が来るまで継続します。

エンタープライズチームにとっての実務上の期限は、移行後に現在の自動化が更新サイクルに到達する時点です。たとえば、現在証明書が60日ごとに更新されているなら、方針変更後に45日間の証明書を発行するまでの間に、だいたい1回の更新サイクルがあります。

45日とは実際に何を意味するのか：年間8回の更新サイクル（現状4回）#

計算は単純ですが、運用上の影響は単純ではありません。90日間の証明書から45日間の証明書へ移行すると、次のようになります：

**更新頻度が2倍になります。** ドメインごとに年間4回だった更新サイクルが、8回になります。100ドメインを管理するチームでは、年間の更新イベントが400回ではなく800回になります。何千ものドメインを管理するチームでは、完全な自動化なしには数値が手に負えなくなります。

**更新ウィンドウが短くなります。** 90日間の証明書では、多くの自動更新システムが有効期限の30日前から更新を試みます — そのため、30日間の余裕が確保されます。45日間の証明書では、同じ30日前のリードタイムでも、余裕は15日間しか残りません。更新ロジックは、より積極的で、より確実である必要があります。

**許容できる失敗が減ります。** 90日間の証明書では、更新に失敗しても、有効期限までに調査・解決するための数週間があります。45日間の証明書では、猶予は数日です。更新の失敗はより緊急になり、監視はより機敏である必要があります。

**レート制限が懸念になります。** Let's Encryptは証明書発行にレート制限を設けています。更新頻度が2倍になるということは、レート制限の予算を2倍消費することを意味します。90日間の証明書で上限に近いチームは、45日間の証明書で上限に達し、発行パターンの調整が必要になる可能性があります。

結論：90日間ではかろうじて機能していた手動または半自動の更新プロセスは、45日間では失敗します。完全な自動化はもはや「任意」ではありません。

最も影響を受けるのは誰か：手作業のSSLプロセスで100以上のドメインを管理するチーム#

45日間の証明書時代は、誰にでも同じように影響するわけではありません。最も大きな影響を感じるのは、次のようなケースです。

**ドメイン投資家およびポートフォリオマネージャー。** 数百〜数千の駐車・リダイレクト・収益化されたドメインを管理するチームでは、運用上の負担が最も大きくなります。各ドメインにはそれぞれ証明書が必要です。90日での手作業更新ですらすでにつらいものでしたが、45日では現実的ではありません。

**クライアントのドメインを管理する代理店。** デジタルエージェンシーは、数十〜数百のクライアントドメインに対してSSLを管理することがよくあります。各クライアントは、異なるインフラ、異なる更新プロセス、そして異なるレベルの自動化を採用している場合があります。45日というスケジュールは、更新ワークフロー上のあらゆる不一致を増幅させます。

**複数のストアフロントを持つECプラットフォーム。** マルチブランドのEC運用では、ブランドごと、地域ごと、キャンペーンごとに別々のドメインを運用します。証明書の数はすぐに増え、それに伴って更新の負担も急速に大きくなります。

**カスタムドメインを扱うSaaSプラットフォーム。** 顧客が自社ドメインを持ち込めるSaaS製品では、通常オンボーディングの一環としてSSLのプロビジョニングを行います。45日間の証明書では、更新インフラは「万全」である必要があります。顧客のドメインで更新に失敗すると、そのサイトにセキュリティ警告が表示されます。

完全に自動化されたACMEベースの更新を行っているチームは、変更をまったく感じないかもしれません。証明書の有効期間は、自動更新するインフラによって抽象化されます。分岐点は自動化です。更新プロセスに、人がダッシュボードを確認したりスクリプトを実行したりする要素があるなら、そこから外れている可能性が高いです。

エンタープライズにおける準備度のギャップ#

業界調査は、懸念のある状況を示しています。Let's Encryptの利用可能性やACMEの自動化が成熟してきたにもかかわらず、一定の割合の組織は依然として、SSLの更新を手作業または半自動のプロセスで管理しています。

よくあるギャップには、次のようなものがあります。自動監視ではなくスプレッドシートで管理している証明書、手動での起動が必要な更新スクリプト、監視されていない受信箱に届く期限切れアラート、そして更新の中央集約的な連携なしにインフラ全体へ展開されるワイルドカード証明書。

準備のギャップは、Let's Encryptを早期に導入したものの、更新のパイプラインを完全には自動化していない組織で最も大きくなります。彼らは5年前にいくつかのサーバーにCertbotをセットアップし、cronジョブを追加したものの、その後セットアップを見直していません。これらのcronジョブは60日ごとに実行されるかもしれませんが、45日間の証明書にはそれでは頻度が足りません。

移行をすでに完了したインフラチームからの推奨は一貫しています。今すぐ更新プロセスを監査してください。インフラ内のすべての証明書を洗い出し、更新が自動化され監視されていることを確認し、障害発生時の復旧手順をテストしてください。45日間の時代は、更新パイプラインのあらゆるギャップをあぶり出します。

結論#

45日間の証明書の時代がやって来ます。これは単なるLet's Encryptの方針変更ではなく、セキュリティのベストプラクティスによって証明書の有効期間を短くするという、業界全体のシフトです。エンタープライズチームにとって、影響を感じる人と感じない人の境界はシンプルです。それは「自動化」です。

SSLの更新パイプラインがACMEによって完全に自動化されているなら、証明書が更新され、インストールされ、そして人の介入なしに検証されるのであれば、設定パラメータを更新する以外、変化にまったく気づかない可能性があります。更新プロセスに手作業、スプレッドシート、人が起動するスクリプトが含まれている場合、45日間のタイムラインはインフラのあらゆるギャップを明らかにします。

実行すべき手順は明確です。証明書の棚卸しを行い、自動化のカバレッジを確認し、更新失敗のシナリオをテストし、監視がユーザーにブラウザ警告が表示される前に期限切れを検知できるようにしてください。タイムラインが短くなる前にこれを今すぐ行うチームは、トランジションを事故なく乗り切ることができます。

今すぐSSL更新プロセスを監査してください。45日間の時代が来ます。自動化されたSSL管理がどのように機能するかを確認しましょう。