この記事の途中に、以下の記事の引用を含んでいます。
Let’s Encrypt Certificate Lifetimes go from 90 days to 45 days
インターネットの根本が変わる!? Let’s Encryptの証明書有効期間短縮、その全体像
Let’s Encrypt（レッツ・エンクリプト）は、近年急速に普及した無料のSSL/TLS証明書発行機関です。
今回は、その証明書の有効期間が「90日から45日」へと大幅に短縮されるという、業界全体に大きな影響を及ぼす決定の背景と今後について、公式発表記事をもとに紹介し、専門的な視点から詳しく解説します。
業界全体のトレンドを示す動き—Let’s Encryptからの公式発表
まずは、Let’s Encryptの公式発表から重要な主張を引用します。
“Let’s Encrypt will be reducing the validity period of the certificates we issue. We currently issue certificates valid for 90 days, which will be cut in half to 45 days by 2028.
This change is being made along with the rest of the industry, as required by the CA/Browser Forum Baseline Requirements, which set the technical requirements that we must follow. All publicly-trusted Certificate Authorities like Let’s Encrypt will be making similar changes. Reducing how long certificates are valid for helps improve the security of the internet, by limiting the scope of compromise, and making certificate revocation technologies more efficient.”
Let’s Encrypt Certificate Lifetimes go from 90 days to 45 days
この部分で、Let’s Encryptは証明書有効期間短縮が「CA/Browser Forum」の規定に適合するための業界全体の施策であり、セキュリティ向上が主目的、という点を明言しています。
さらに、既存の認証再利用期間（authorization reuse period）も現行の30日から2028年までに「7時間」へ大幅短縮されることも同時に盛り込まれています。
また、段階的なスケジュールも発表されており、2026年5月からオプトインのテストプロファイルで45日証明書発行を開始。
2027年2月にはデフォルトプロファイルで64日、2028年2月にはすべての新規証明書が45日間有効という流れです。
短縮の背景にある“本質”—なぜ証明書の寿命は短い方が良いのか？
SSL/TLS証明書の有効期間が年ごとにどんどん短くなっている現状をご存知でしょうか。
かつては3年証明書がありましたが、今や1年、90日と短縮が進み、ついに45日。
なぜこのような変化が求められるのでしょうか？
被害範囲の限定と失効技術の強化
記事によれば「Reducing how long certificates are valid for helps improve the security of the internet, by limiting the scope of compromise, and making certificate revocation technologies more efficient.（証明書が有効な期間を短くすれば、万が一証明書が漏洩・悪用された場合、被害範囲を狭めやすくなり、失効処理も現実的になる）」とのこと。
実際、証明書失効（CRLやOCSP）技術には速度や浸透率の課題があるため、短命化はそのリスクを時間的に“切る”戦略と一致します。
自動化推進とリスク管理
Let’s Encryptはサーバ管理者や開発者の利便性向上のため、証明書発行と更新の全自動化（ACMEプロトコル）を標準としています。
有効期間短縮が技術的に許されたのは、この自動化エコシステムの成熟があってこそです。
「証明書は自己管理・自動更新が前提」—この時代の変化こそが最も重要な背景です。
実務担当者への影響とその対応—自動更新の真価が問われる
では、現場の影響はどうでしょうか。
手動更新は現実的ではなくなる
45日ごとにSSL証明書を手作業で再発行・更新するのは明らかに非現実的です。
Let’s Encrypt公式も
“Manually renewing certificates is not recommended, as it will need to be done more frequently with shorter certificate lifetimes.”
Let’s Encrypt Certificate Lifetimes go from 90 days to 45 days
と、手動での運用を事実上推奨していません。
自動化されていない仕組みは淘汰される？
現実には、ホスティングサーバやレンタルサーバの中には、自動更新未対応のものや、更新環境が複雑なケースも多々ありました。
しかし、今回の有効期間短縮は、「自動更新できないサーバ＝時代遅れ」という明確なレッドカードとなりそうです。
監視・通知体制の必須化
証明書更新失敗＝サイトダウン・SEO低下・信頼喪失など、ビジネス的損失は計り知れません。
公式がモニタリングの強化も同時に推奨している点は見逃せません。
ACME Renewal Information（ARI）や、証明書有効期限監視ツールの導入は、もはや“あると便利”ではなく“必須要件”になるでしょう。
技術進化と課題解決—DNS-PERSIST-01の登場
認証簡素化へ向けた次世代技術の情報も発表されています。
ドメイン認証のハードルを下げる新しい仕組み
「自動更新にしたいけれど、インフラ側の自動化が難しい」
「DNSの権限委譲やAPI連携に抵抗がある」
そんな利用者の声を背景に、Let’s EncryptはDNS-PERSIST-01という新しい認証手法を標準化しようとしています。
“The key advantage of this new method is that the DNS TXT entry used to demonstrate control does not have to change every renewal.
This means you can set up the DNS entry once and begin automatically renewing certificates without needing a way to automatically update DNS.”
Let’s Encrypt Certificate Lifetimes go from 90 days to 45 days
つまり、一度DNSに設定してしまえば、その後はDNS上の変更作業なしで証明書を自動更新できるという革新的な方式です。
2026年頃の導入を予定しており、これによって「自動化困難な環境」の壁が一気に低くなりそうです。
批評的視点—“短命化”がすべての答えか？
ここまで読むと、「期間短縮＝絶対的な善」という印象を受けがちですが、あえてその先を考えてみます。
本当にリスクが減るのか？技術的課題
短期間証明書の自動化更新が前提では、以下の新たなリスクが浮上します。
- 自動化システムのバグや運用ミスによる証明書期限切れ
- ACMEサーバ障害時の一斉証明書期限切れリスク
- 大量証明書の失効・更新によるネットワーク/クラウド負荷
近年「Let’s Encrypt証明書切れで大手サービスが一時ダウン」といった事故は実際に発生しているため、「どんなに自動化しても監視・バックアップ体制は不可欠」と言えます。
小規模サイト・自作インフラへの負担増
趣味用途や個人開発の場合、「さっと発行してしばらく放置」といった運用がしにくくなり、管理の手間・障壁は明らかに上がります。
これをどう補完するかは、サービス/コミュニティによる情報発信や、より簡便な更新ツールの普及が欠かせません。
まとめ—インターネットの新スタンダード時代、今から備えるべきを考える
Let’s Encryptの証明書有効期間短縮は、「セキュリティ向上」と「自動化推進」を同時に体現した、現代インターネットインフラの大きな転機です。
将来的には、証明書発行と管理は“絶え間ない自動化＋監視”が当たり前になり、人手による証明書管理の重要性は激減していくでしょう。
一方で、単なる技術改良ではなく
- 十二分な監視体制の整備
- 自動更新スクリプトの安定運用
- 新しい認証方式（DNS-PERSIST-01等）の情報キャッチアップ
これらを怠ると、逆にサービスリスクが跳ね上がる“諸刃の剣”でもあります。
「証明書の管理は自動化して終わり」ではありません。
誰もが気軽にセキュアなWeb環境にアクセスできる未来へ、あなた自身の管理体制も今一度見直してみてはいかがでしょうか。
categories:[security]
コメント