Let's Encrypt 45日証明書：タイムラインと準備方法

はじめに#

Let's Encrypt は証明書の有効期間を90日から45日に短縮します。この変更は2026年から2028年にかけて段階的に実施され、これは Let's Encrypt だけの判断ではありません。CA/Browser Forum はすでに、2029年3月までに公開信頼 TLS 証明書の有効期間を47日に上限設定することを可決しています。数百、数千のドメインを管理するチームにとって、更新は定期的な作業ではなく、独力で動作する仕組みにしなければならないものになります。

いまも SSL の更新を手作業で行っているなら、これからその負担を強く感じることになるでしょう。年4回だった更新サイクルは8回になります。四半期ごとの管理可能な作業は、絶え間ない運用負荷へと変わります。タイムラインはすでに動き出しており、今のうちに準備するインフラチームは移行を円滑に進められます。準備しないチームは、障害リスクの増大と運用上のオーバーヘッド拡大に直面します。

このガイドでは、正確な日程、更新で何が変わるのか、ACME 自動化と手動の証明書管理の比較、そして最も忘れられがちな証明書であるリダイレクトドメインとパークドメインのチェックリストを解説します。

発表内容: Let's Encrypt が証明書を90日から45日に移行#

2025年12月、Let's Encrypt は証明書の有効期間を90日から45日へ段階的に短縮し、ドメイン検証（認証）の再利用可能期間も短くすることを発表しました。変更は新規発行の証明書に適用されるため、各日付以降の次回更新でより短い有効期間が適用されます。

Let's Encrypt は開始当初から90日証明書を発行してきました。当時の多くの商用証明書の有効期間は1年超でした。短い有効期間は、すべての人を自動化へ促すことを目的としていました。45日への移行もその流れを継続するものであり、以下の業界全体のスケジュールとも一致しています。

実務上の影響は明快です。Let's Encrypt で保護されたすべてのドメインは、証明書更新を2倍の頻度で行う必要があります。すでに更新プロセスを自動化している組織にとっては、移行はほぼシームレスかもしれません。手動プロセスや半自動のワークフローに依存しているチームにとっては、運用への影響は大きいでしょう。

なぜ起こるのか: セキュリティのベストプラクティス — 侵害されうる期間の短縮#

証明書の有効期間を短くすることは、本質的にセキュリティ改善です。すべての TLS 証明書は潜在的な攻撃対象となり得ます。証明書の秘密鍵が侵害されると、攻撃者は証明書が失効または取り消されるまで、正規のドメインになりすますことができます。証明書の有効期間が長いほど、この侵害されうる期間も長くなります。

45日間の証明書は、現在の90日標準と比べてその期間を半分に縮めます。鍵が初日に侵害された場合、最大露出期間は90日ではなく45日です。実際には露出期間はたいていもっと短いのですが、その上限は重要です。特に、侵害をすぐには検知できない組織にとってはなおさらです。

失効に関する論点もあります。CRLやOCSPによる証明書失効は、歴史的に信頼性に欠けてきました。ブラウザは常に一貫して失効状態を確認するわけではなく、失効した証明書が引き続き信頼されることもあります。寿命が短ければ、失効基盤への依存を減らせます。証明書が45日しか有効でないなら、失効させることの重要性は下がります。どうせすぐ期限切れになるからです。

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

Let's Encrypt だけではない: CA/Browser Forum の47日ルール#

2025年、公開TLS証明書のルールを定める証明書 কর্ত выда? কর্তৃপক্ষ? and browser makers that sets the rules for public TLS certificates, adopted ballot SC-081v3. それは、DigiCert、Sectigo、GlobalSignを含むすべてのCAの、公開で信頼されるすべての証明書の最大有効期間を3段階で短縮し、ドメイン検証を再利用できる期間も短くしました:

つまり、今日1年契約の商用証明書を購入したとしても、すでに上限は200日であり、そこから47日へと同じ道筋をたどることになります。短い有効期間は、もはや一部の無料CAだけの特殊な仕様ではなく、ウェブ全体のルールです。

Let's Encrypt のタイムライン: 重要な日付#

各変更は本番環境の約 1 か月前に Let's Encrypt のステージング環境に反映されるため、まずそこで設定をテストできます。

7 時間の認証再利用は、人が見落としがちな変更です。現在は、一度検証されたドメインは、再検証なしで何週間も再発行できます。2028 年以降は、ほぼすべての更新で新たな検証が必要になるため、DNS レコードや HTTP チャレンジは、ドメインを設定した日だけでなく、更新時にも引き続き機能していなければなりません。

Let's Encrypt では、さらに進めたいチーム向けに、6日間の証明書を提供する短寿命プロファイルも用意しています。

実務上の期限は更新スケジュールです。Let's Encrypt は、固定の60日更新間隔ではもはや不十分だと言っています。クライアントが対応している場合は ACME Renewal Information (ARI) を使用してください。これは CA が更新時期を知らせる仕組みです。対応していない場合は、証明書の有効期間の約3分の2の時点で更新してください。

45日が実際に意味するもの: 年間8回の更新サイクル vs 現在の4回#

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

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

更新期間が短くなります。90日証明書では、期限切れの30日前に更新すれば十分な余裕があります。45日証明書では、有効期間の3分の2の時点で更新すると、失敗に気づいて修正するための猶予は約15日しかありません。

障害許容度が下がります。 90日証明書では、更新に失敗しても、失効前に数週間かけて調査・解決できます。45日証明書では、使えるのは数日です。更新失敗はすべてより緊急性が高くなり、監視もより迅速に反応する必要があります。

レート制限が懸念事項になります。 Let's Encrypt は証明書発行にレート制限を適用しています。更新頻度が2倍になれば、消費するレート制限の枠も2倍になります。90日証明書で上限に近いチームは、45日証明書で上限に達する可能性があり、発行パターンの調整が必要になる場合があります。

要するに: 90日ではかろうじて機能していた手動または半自動の更新プロセスは、45日では機能しなくなります。完全自動化はもはや任意ではありません。

最も影響を受けるのは誰か: 手動のSSL運用で100以上のドメインを管理するチーム#

45日証明書の時代は、誰にとっても同じように影響するわけではありません。最も大きな影響を受けるのは次のような人たちです。

ドメイン投資家とポートフォリオ管理者。 駐車中、リダイレクト中、または収益化済みのドメインを数百、数千単位で管理するチームは、最も大きな運用負担を抱えます。各ドメインごとに証明書が必要です。90日でもこの規模の手動更新はすでに大変でした。45日では現実的ではありません。

クライアントのドメインを管理する代理店。 デジタルエージェンシーは、数十から数百のクライアントドメインのSSLを管理することがよくあります。各クライアントでインフラも更新手順も自動化の度合いも異なる場合があります。45日という期間は、更新ワークフローにあるあらゆる不整合をさらに浮き彫りにします。

複数のストアフロントを持つEコマースプラットフォーム。 複数ブランドを展開するEコマース運営では、ブランドごと、地域ごと、キャンペーンごとに別々のドメインを運用します。証明書の数はすぐに増え、それに伴って更新負担も増えます。

カスタムドメインを持つSaaSプラットフォーム。 顧客が独自のドメインを持ち込めるSaaS製品では、通常、SSLのプロビジョニングがオンボーディングの一部として行われます。45日証明書では、更新基盤は絶対に失敗が許されません。顧客のドメインの更新に失敗すると、そのサイトにはセキュリティ警告が表示されてしまいます。

ACMEベースの更新を完全に自動化しているチームは、変化をまったく感じないかもしれません。証明書の有効期間は、自動更新するインフラによって意識する必要がなくなっているからです。分岐点は自動化です。更新プロセスで人がダッシュボードを確認したりスクリプトを実行したりしているなら、その影響を受ける側にいます。

エンタープライズ対応のギャップ#

証明書の自動化を何年も前に済ませ、その後は見直していないチームは少なくありません。ギャップは、いつも同じような場所で現れます。

証明書を監視ではなくスプレッドシートで管理している、誰かが手動で実行しなければならない更新スクリプト、誰も見ていない受信箱に届く失効アラート、そして単にリダイレクトしているだけなので証明書があること自体を誰も意識していないドメインです。

この対応準備のギャップが最も大きいのは、Let's Encrypt を早期に導入したものの、更新パイプラインを完全には自動化しなかった組織です。5年前に数台のサーバーへ Certbot を導入し、cronジョブを追加したまま、その後は設定を見直していません。そうした cronジョブは60日ごとに実行されているかもしれませんが、45日証明書ではそれでは十分な頻度ではありません。

90日間証明書がまだ安全余裕として使える今のうちに監査しましょう。すべての証明書を一覧化し、自動更新されることを確認し、更新が失敗した場合に何が起こるかをテストしてください。

ACME と手動の証明書管理#

リダイレクトおよび駐車ドメインのチェックリスト#

リダイレクトのみのドメインは忘れがちですが、https:// と入力した訪問者も、リダイレクトが行われる前に有効な証明書が必要です。2027年と2028年の日付までに:

1. 旧ブランド、タイプミスのドメイン、キャンペーンドメインを含む、リダイレクトするすべてのドメインと、ルートおよび www の両方を一覧にする。
2. それぞれについて、証明書を誰が発行し、どのように更新されるかを記録する。「レジストラの転送」では、HTTPS がまったく使えないことがよくあります。
3. 各 ACME クライアントが ARI をサポートしているか、または固定の60日 cron ではなく、ライフタイムの3分の2の時点で更新することを確認する。
4. 更新時にも検証が引き続き機能することを確認してください。DNS が HTTP チャレンジを応答している先を引き続き指しているか、DNS チャレンジの認証情報が引き続き有効である必要があります。
5. 期限監視を設定し、1人の個人の受信箱ではなく共有チャンネルにアラートを送るようにしてください。
6. 本番変更の前に毎回、Let's Encrypt のステージング環境でテストしてください。

あるいは、各ドメインごとに HTTPS を発行・更新するリダイレクトプラットフォームへ移行することで、リダイレクト用ドメインをリストから完全に外すこともできます。

結論#

45日証明書時代が到来しつつあります。これは単なる Let's Encrypt のポリシー変更ではなく、セキュリティのベストプラクティスに後押しされた、証明書の有効期間短縮という業界全体の流れです。エンタープライズチームにとって、この影響を受けるか受けないかの分かれ目は、シンプルに自動化できているかどうかです。

SSL 更新パイプラインが ACME によって完全に自動化されており、証明書の更新・インストール・検証が人手を介さずに行われるなら、構成パラメータを更新する程度で、変更にまったく気づかないかもしれません。更新プロセスに手作業、スプレッドシート、または人がトリガーするスクリプトが含まれている場合、45日というタイムラインはインフラのあらゆる隙間を露呈させるでしょう。

実践的な手順は明快です。証明書の在庫を監査し、自動化の適用範囲を確認し、更新失敗のシナリオをテストし、ユーザーがブラウザの警告を見る前に期限切れを監視が確実に検知できるようにします。今すぐこれを行うチームは、タイムラインがさらに短くなる前に、この移行を問題なく乗り切れるでしょう。

リダイレクト用ドメインを運用していますか？ 証明書エラーなしで HTTPS 経由のドメインリダイレクトを行う方法 をご覧ください。