- チェーン刷新（Generation Y）・クライアント認証EKU削除・有効期間短縮…結局なにが変わる？
- ✅ 変更点①：証明書の有効期間が「90日 → 45日」に向かう
- ✅ 変更点②：証明書チェーンが「Generation X → Generation Y」に刷新
- ✅ いつ切り替わる？（プロファイル別タイムラインが超重要）
- ✅ 変更点③：TLSクライアント認証EKUが削除される
- 🧰 実務的な対策：あなたの環境は何をすべき？
- 🆕 追加トピック：IPアドレス証明書の発行（対応範囲が拡大）
- ✅ まとめ：Let’s Encryptの変更は「自動化前提の世界」への移行宣言
- 📚 参考・出典（本文中リンクは削除して一括掲載）
チェーン刷新（Generation Y）・クライアント認証EKU削除・有効期間短縮…結局なにが変わる？
Let’s Encryptが、今後の証明書発行方針について 重要な変更点をまとめて発表しました。内容は大きく3本柱です👇
- 🧬 証明書チェーンの刷新（Generation X → Generation Y）
- 🪪 TLSクライアント認証EKU（Extended Key Usage）の削除
- ⏳ 証明書の有効期間を段階的に短縮（最終的に45日へ）
結論から言うと、通常のWebサイト運用（HTTPS）だけなら多くの人は追加作業なしで追従できます。
ただし、mTLS（クライアント証明書認証）や独自用途でLet’s Encrypt証明書を使っている人は、2026年に向けて要チェックです。⚠️
✅ 変更点①：証明書の有効期間が「90日 → 45日」に向かう
なぜ短くするの？（安全性・運用の現実・業界ルールの変更）
有効期間短縮の背景は、ざっくり言うと次の3つです。
- 🔒 漏えい・誤発行の影響を短くする（ダメージ時間を減らす）
- 🔁 暗号アルゴリズムや運用変更に“素早く追随”できる（俊敏性）
- 🧩 CA/Bフォーラム（ブラウザ・認証局の業界ルール）要件変更に合わせる
🗓️ Let’s Encryptが示したスケジュール（重要）
- 2026年： 「tlsserver」プロファイルで 45日証明書をオプトイン提供（早期導入・テスト向け）
- 2027年： デフォルトの有効期間が 64日へ短縮
- 2028年： デフォルトが 45日へ短縮（最終到達点）
💡ポイント：
これからは「更新回数が増える」ので、手動更新は現実的ではなくなります。
逆に言えば、いま既に ACME（certbot等）で自動更新している人は影響が軽いです。
✅ 変更点②：証明書チェーンが「Generation X → Generation Y」に刷新
“チェーン刷新”って何？（多くの人は気づかず通過する変更）
証明書は「サーバ証明書」だけで成り立っていません。
その裏には 中間認証局（Intermediate）→ ルート認証局（Root） という“信頼の鎖（チェーン）”があります。
Let’s Encryptはこの信頼チェーンを、従来の Generation X から、新しい Generation Y に移行します。
🧬 Generation Yの特徴
- 新しい ルート2つ + 中間6つ を中心とする構成
- 既存環境でも動くように、Generation Xのルートからクロス署名される設計
💡「クロス署名（Cross-sign）」は、
“新しいルートに移行したいが、古い環境の互換性も残したい”ときに使う定番の手法です。
✅ いつ切り替わる？（プロファイル別タイムラインが超重要）
Let’s Encryptは、ACMEの 証明書プロファイル（certificate profiles） を活用して、段階導入します。
ここを理解すると「自分がいつ影響を受けるか」が一発でわかります👇
🟦 1) classic（デフォルトの大半がこれ）
- 2026年5月13日：Generation Yへ切り替え
✅ 普通のWebサーバでLet’s Encryptを使っている人の多くは、ここで自然に切り替わります。
🟩 2) tlsserver / shortlived（短命・先行プロファイル）
- 2025年12月第3週：Generation Y由来の証明書発行へ切り替え
- shortlived：有効期間6日の短期証明書がオプトインで一般提供
✅ 「早めに新チェーンを試したい」「超短命証明書でリスクを減らしたい」用途向けです。
（※通常のサイト運用では必須ではありません）
🟧 3) tlsclient（クライアント証明書用途向け）
- 2026年5月まで利用可能（移行猶予）
- このプロファイルは当面Generation Xを維持
⚠️ 重要：
互換性問題が出る場合の“退避先”として残されますが、恒久的なものではないと考えるのが安全です。
✅ 変更点③：TLSクライアント認証EKUが削除される
影響が出るのは「mTLSでLet’s Encryptをクライアント証明書に使っている人」
今回、最も誤解されやすいのがここです。
**「TLSクライアント認証EKU」**とは、証明書に入る用途宣言のようなもので、
「この証明書は“クライアント証明書として使う想定です”」という情報です。
Let’s Encryptは2026年から、発行する証明書に TLSクライアント認証EKUを含めない方針です。
理由は、**ルートプログラム要件（ブラウザ/OS側の要求）**に合わせるため、と説明されています。
🧨 影響が出るパターン（代表例）
- 社内VPNや社内APIで クライアント証明書認証（mTLS） をしている
- Let’s Encryptで発行した証明書を クライアント側に配布して認証に使っている
- 一部の製品・ミドルウェアが EKUの存在を必須チェックしている
✅ 一方、普通のHTTPS（サーバ証明書）だけなら、ほぼ気にしなくてOKです。
🧰 実務的な対策：あなたの環境は何をすべき？
✅ A. ほとんどのWebサイト運用者（HTTPSだけ）
- 💤 基本的に何もしなくてOK
- 🔁 ただし 自動更新（ACME）が動いているかだけは確認推奨
（45日化が進むほど、手動更新は事故ります）
⚠️ B. mTLS（クライアント証明書認証）にLet’s Encryptを使っている
2026年に向けて、次の方向性を検討してください👇
- 🏢 社内用は社内CA（Private CA）へ移行（最も王道）
- ☁️ クラウドのマネージドCAを使う（AWS ACM PCA / Google CAS 等）
- 🧩 SPIFFE/SPIREなど、サービス間ID基盤として再設計
- 🧾 どうしても公開CAが必要なら、クライアント証明書対応の別CAを検討
※ Let’s Encryptは「Webを暗号化するためのサーバ証明書」に最適化されており、クライアント証明書は今後縮退する流れです。
🆕 追加トピック：IPアドレス証明書の発行（対応範囲が拡大）
Let’s Encryptは、ドメイン名ではなくIPアドレスを直接指定するサーバ向けにも証明書発行を可能にする方針を示しています。
これは、次のような用途で便利です👇
- 🌐 DNSを持たない閉域環境
- 🧪 検証用・一時環境
- 🏗️ インフラ内部の特定用途（※設計次第）
ただし、運用設計（更新・管理・監査）まで含めると「ドメインで統一」の方が楽なケースも多いので、導入は慎重に。
✅ まとめ：Let’s Encryptの変更は「自動化前提の世界」への移行宣言
今回の発表を一言でまとめると、こうです👇
- ⏳ 証明書は短命化し、自動更新が必須になる
- 🧬 チェーンはGeneration Yへ移行し、多くの利用者は無停止で移行できる
- 🪪 mTLS用途（クライアント証明書）は、Let’s Encryptに依存しない設計が必要になる
つまり、今後は「証明書を取る」ではなく、
**“証明書が勝手に回り続ける仕組みを作る”**のが標準になります。🔁✨
📚 参考・出典（本文中リンクは削除して一括掲載）
- Let’s Encrypt Community Support：「Upcoming Changes to Let’s Encrypt Certificates」（2025年12月）
- Let’s Encrypt Blog：「Decreasing Certificate Lifetimes to 45 Days」（2025年12月）
- Let’s Encrypt Blog：「New “Generation Y” Hierarchy of Root and Intermediate Certificates」（2025年11月）
- Let’s Encrypt Blog：「Ending TLS Client Authentication Certificate Support in 2026」（2025年5月）
- Let’s Encrypt Blog：「Announcing Six Day and IP Address Certificate Options…」（2025年1月）
- CA/Browser Forum：Baseline Requirements（要件改定・有効期間短縮の議論・スケジュール関連）
