WEBサイトLet's Encryptの証明書は2027年2月10日から標準で64日になる ── 更新の設定の「日数の決め打ち」とARI対応を確かめる13項目（2026年10月時点）
Let's Encryptの証明書は2027年2月10日から標準で64日になる ── 更新の設定の「日数の決め打ち」とARI対応を確かめる13項目（2026年10月時点）
目次
01 何が起きたか — 証明書の標準の有効期間が、2027年2月10日から64日になる
2026年10月7日の告知
Let's Encryptの公式ブログに、2026年10月7日付で「64-Day Certificate Lifetimes Coming Feb 2027」（訳: 64日の証明書の有効期間が2027年2月に来る）が載った。2026年10月9日に本文を開いて確かめた。冒頭の文は、次のとおりである。
"On February 10, 2027, all Let’s Encrypt subscribers will move to certificates with 64 day lifetimes by default unless they select an even shorter lifetime (45 or 6 days, as previously announced)."
（訳: 2027年2月10日に、Let's Encryptのすべての利用者は、さらに短い有効期間（前に告知したとおり45日か6日）を選ばない限り、既定で64日の有効期間の証明書に移る。）
続く文は、いつから新しい期間になるか、古い証明書がいつまで残るかを書いている。
"This means that any certificate we issue or renew on and after that date will have a 64 day validity period, and we expect the last 90-day certificate to expire on May 11, 2027."
（訳: つまり、その日以降に発行または更新する証明書はすべて、64日の有効期間になる。最後の90日の証明書は、2027年5月11日に期限が切れると見込んでいる。）
2月10日の90日後が5月11日になる、という日付の計算も合っている。この記事は、告知の見立て（更新が自動で、ARIに対応していれば、問題ないはず）に、自分のサイトが当てはまるかを確かめる手順を整理する。
告知の日付を、日にちの順に並べる
告知と、同じ公式ブログの前の告知から、この変更に関わる日付だけを並べると、次の表になる。右の列は、その日付が書かれている場所である。
| 日付 | できごと | 書かれている場所 |
|---|---|---|
| 2026年10月7日 | 64日の証明書への移行を告知 | 2026年10月7日の告知 |
| 2026年10月14日 | 試験環境（staging）で、64日の証明書の発行を始める | 2026年10月7日の告知 |
| 2027年2月10日 | 標準のプロファイルが64日になる。認証の再利用期間は10日になる | 2026年10月7日と2025年12月2日の告知 |
| 2027年5月11日 | 最後の90日の証明書が、期限切れになる見込み | 2026年10月7日の告知 |
| 2028年2月16日 | 標準のプロファイルが45日になる。認証の再利用期間は7時間になる | 2025年12月2日の告知 |
告知が約束していること
告知は、まず、有効な証明書を失効させないことを約束している。
"We will not revoke valid certificates as a part of this process."
（訳: この過程の一部として、有効な証明書を失効させることはしない。）
02 なぜ・背景 — 業界の決まりが、証明書の寿命を短くしている
2025年12月の予告では、最終的に45日になる
今回の告知は、突然の変更ではない。2025年12月2日の告知「Decreasing Certificate Lifetimes to 45 Days」（訳: 証明書の有効期間を45日に短くする）が、全体の計画を先に書いていた。
"We currently issue certificates valid for 90 days, which will be cut in half to 45 days by 2028."
（訳: 現在は90日有効の証明書を発行しているが、2028年までに半分の45日に短くする。）
予告の段階は、2026年5月13日に利用者が選ぶ形のプロファイル（tlsserver）が45日、2027年2月10日に既定のプロファイル（classic）が64日、2028年2月16日に既定が45日である。今回の告知は、このうち2027年2月10日の段を、日付つきで念押ししたものである。2026年10月4日に更新された公式のプロファイルの説明では、tlsserverは45日、classicは、この記事を書いた時点では90日と載っている。
決めているのは、Let's Encryptだけではない
同じ告知は、この変更の理由を、業界の決まりに結びつけている。
"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."
（訳: この変更は、業界の他の組織と一緒に、CA/Browserフォーラムの基本要件が求めるとおりに行っている。基本要件は、私たちが従わなければならない技術的な要件を定めている。）
CA/Browserフォーラムの公式ページにある投票の記録（Ballot SC081v3）は、その内容を「Eventual reduction of maximum validity period from 398 days to 47 days」（訳: 最大の有効期間を、398日から47日へ、段階的に減らす）と要約し、減らし方は2026年3月に始まり、2029年3月に終わる計画だと書いている。証明書を出す会社を乗り換えても、短くなる流れは変わらない。
認証の再利用期間も、30日から10日に縮む
今回の告知は、有効期間とは別に、認証の再利用期間も縮めると書いている。ドメインの持ち主だと確かめた結果を、次の発行に使い回せる期間のことである。
"We will also be reducing the authorization reuse period from 30 days to 10 days."
（訳: 認証の再利用期間も、30日から10日に縮める。）
告知は、2028年には7時間になると書き、認証の再利用に頼る作りの更新ソフトでない限り、変更は要らない、と影響を受ける人を限っている。
更新の目安は「寿命の3分の2」
告知は、更新の時期を、日数ではなく割合で決めるよう求めている。
"If your renewals are hard-coded to a date from expiration you should update them to renew at approximately ⅔ of the lifetime instead."
（訳: 更新が、期限からの日数で決め打ちになっているなら、代わりに、寿命の約3分の2の時点で更新するように直す。）
2026年2月24日の公式の告知は、同じ目安を、90日の証明書の60日目ごろ、45日の証明書の30日目ごろと書いている。64日の証明書では、この記事の計算で約43日目になる（64日の3分の2は42.7日で、公式は64日の場合の日数を書いていない）。
03 用語 — 読み違えやすい言葉を先にそろえる
ACMEとARI
用語
ACME：証明書の発行と更新を、人の手を介さずに行うための通信の決まりである。更新ソフト（クライアント）が、証明書を出す側（認証局）と、この決まりで話す。ARI（ACME Renewal Info）：認証局が、更新ソフトに「いつ更新するとよいか」を伝える仕組みで、2025年9月に、RFC 9773として公開された。公式の説明は、認証局が多数の証明書を一斉に失効させる場合に、更新ソフトが失効の前に入れ替えられるようにするためにも使える、と書いている。
試験環境（staging）とプロファイル
用語
試験環境（staging）：本番と同じ手順で試せるが、出てくる証明書はブラウザに信頼されない、練習用の発行先である。プロファイル：証明書の中身や、発行の手順の違いを、まとめた設定の名前である。公式の説明は、classicを、プロファイルを指定しない注文の既定と書いている。tlsserverは45日、shortlivedは6日ほどで、どちらも利用者が自分で選ぶ。
決め打ちと、deploy hook
用語
決め打ち：「発行から80日後に更新する」「期限の30日前に更新する」のように、日数の数字を、設定や命令に直接書いてあることである。deploy hook：Certbotが、更新に成功したときだけ実行する命令である。公式の説明は、「更新を試みるたびに」ではなく、成功したときだけ動かしたい場合に、deploy hookを使うと書いている。
04 型別 — 自分が「任せている側」か「自分で管理する側」かで、順番が変わる
🅰 適用範囲 — 対象は、Let's Encryptの証明書を使っているサイト
この告知が直接関わるのは、Let's Encryptの証明書を使っているサイトである。ブラウザで証明書の情報を開くと、発行者の欄に出る。他の認証局の証明書を使っているサイトは、この告知の対象ではないが、前の節のとおり、業界全体で期間は短くなる。
🅱 公式が書いていないことと、この記事が確かめていないこと
告知にも、公式の関連ページにも、次のことは書かれていない。この記事も、断定しない。個々のレンタルサーバーやCMSが、2027年2月10日に自動で対応するかどうか。更新ソフトごとの、64日の証明書での更新日の一覧。ARIに対応した更新ソフトの、完全な一覧。
この記事は、64日の証明書を実際に発行して、更新を試すことも、していない。試験環境の切り替えが2026年10月14日で、この記事を書いた2026年10月9日には、まだ始まっていないためである。
🅲 手順1 — 任せている人は、5つの質問を1通のメールにまとめる
更新を、レンタルサーバー会社や制作会社に任せている場合、自分で設定を見る必要はない。代わりに、聞くべき質問を決めて、1通にまとめて送る。質問は5つに絞る。
- 証明書の発行元は、Let's Encryptか。
- 更新は自動か、手作業か。自動なら、どのソフトか。
- 2027年2月10日から、標準が64日になることを知っているか。対応の予定日はいつか。
- 使っている更新ソフトは、ARIに対応した版か。
- 更新に失敗したとき、誰に、どの連絡先で、通知が行くか。
返事が「問題ない」とだけなら、どの設定を見て判断したかを、もう1回聞く。
🅲 手順2 — 自分で管理する人は、期限と有効期間を読む
最初に、いまの証明書の期限を読む。ブラウザなら、アドレスの横の錠前のアイコンから、証明書の情報を開くと、発行者と、有効期間の開始日と終了日が出る。コマンドなら、OpenSSLのx509を使う。公式の説明は、終了日の表示を、次のように書いている。
"Prints out the expiry date of the certificate, that is the notAfter date."
（訳: 証明書の期限、つまりnotAfterの日付を表示する。）
終了日から開始日を引くと、有効期間の日数が分かる。90日なら「90」と出る。2027年5月11日より前には、まだ90日の証明書も残る。ただし、手元のパソコンから確かめる場合は、発行者の欄を必ず見る。セキュリティソフトが通信を中継していると、サイトの本物の証明書ではなく、ソフトが作り直した証明書が出る。実例は07章に書いた。
🅲 手順3 — 更新の設定から、日数の数字を探す
告知は、決め打ちの探し方まで書いている。
"Grep for common hardcoded numbers like 83, 80 or 60 in cron jobs, wrapper scripts and runbooks if you’re not sure."
（訳: 自信がなければ、cronの設定、ラッパーのスクリプト、手順書の中から、83・80・60のような、よくある決め打ちの数字を検索する。）
定期実行の場所は、Certbotの公式の説明が、crontabかsystemdのタイマーの中から、certbot renewの命令を探すよう書いている。
見つかった数字は、64日の証明書に当てはめて計算する。告知の「83・80・60」は、90日の証明書で「発行から何日後に更新するか」と読むと意味が通る（この記事の読みで、告知は単位を書いていない）。次の表は、その読みで、64日と45日に当てはめた結果である。
| 設定の書き方 | 64日の証明書（2027年2月10日以降） | 45日の証明書（2028年2月16日以降） |
|---|---|---|
| 発行から83日後に更新 | 寿命より長く、期限切れのあとになる | 寿命より長く、期限切れのあとになる |
| 発行から80日後に更新 | 寿命より長く、期限切れのあとになる | 寿命より長く、期限切れのあとになる |
| 発行から60日後に更新 | 期限の4日前になり、余裕が小さい | 寿命より長く、期限切れのあとになる |
| 期限の30日前になったら更新 | 発行から34日後に更新される | 発行から15日後に更新される |
| 寿命の3分の2の時点で更新 | 発行から約43日後に更新される | 発行から30日後に更新される |
表は、この記事の計算である。日数を書いた設定は、64日の時点で一部が壊れ、45日の時点でさらに壊れる。割合で決める設定は、どちらの寿命でも動く。なお、Certbotの公式の説明は、4.0.0から「寿命の残りが3分の1を切ったら更新の対象」になり、それより前の版は固定の30日だった、と書いている。
🅲 手順4 — 使っている更新ソフトが、ARIに対応しているか確かめる
告知は、ARIに対応していれば、更新の時期を認証局が伝えるので、おおむね問題がないと書いている。
"If your renewals are automated and your client supports ACME Renewal Info (ARI), you should be all set since ARI allows Let’s Encrypt to tell your client when to renew (you can review your ACME client’s documentation to determine if ARI is implemented)."
（訳: 更新が自動で、クライアントがACME Renewal Info（ARI）に対応しているなら、ARIによって、Let's Encryptがクライアントに更新の時期を伝えられるので、問題ないはずである（ARIが実装されているかは、ACMEクライアントの説明書で確かめられる）。）
説明書の書き方は、ソフトごとに違う。この記事で確かめた例は2つある。Certbotの変更履歴は、2025年6月10日の4.1.0に、ARIへの対応を載せている。
"For Let's Encrypt certificates this will typically cause renewal at around 2/3rds of the certificate's lifetime, even if the renew_before_expiry field of a lineage renewal config is set a later date."
（訳: Let's Encryptの証明書では、通常、設定ファイルのrenew_before_expiryがもっと後の日付でも、証明書の寿命の約3分の2の時点で更新する。）
もう1つは、ApacheのモジュールのMDRenewViaARIで、既定はon、状態は「Experimental」（訳: 試験的）である。ARIに対応しているのは、更新ソフトであって、Webサーバー全体ではない。名前と版が分からなければ、手順1の質問に戻る。
認証局の側がARIを出しているかは、公開の入口を開くと分かる。公式の導入の手引きは、「if a ‘renewalInfo’ endpoint is included in the CA’s directory object, then the CA supports ARI.」（訳: 認証局のディレクトリの情報に「renewalInfo」の入口が含まれていれば、その認証局はARIに対応している）と書いている。ただし、これで分かるのは、認証局がARIを出していることであって、自分の更新ソフトが使っていることではない。
🅲 手順5 — 更新のあとに、Webサーバーが読み直すか確かめる
更新に成功しても、Webサーバーが新しい証明書を読み込まなければ、ブラウザには古い期限の証明書が見える。告知も、再読み込みと配置の工程の自動化と、更新の失敗の通知を足す機会だと書いている。
確かめるのは2つである。更新に成功したときだけ動く命令（Certbotならdeploy hook）か、同じ働きの設定があるかないかと、直近の更新のあとに、外から見える期限の日付が実際に変わったかである。Certbotの公式の説明は、「certbot renew exit status will be 0 if no certificate needs to be updated」（訳: 更新が必要な証明書がなければ、終了コードは0になる）と書いている。終了コードが0でも、更新されたとは限らない。
🅲 手順6 — 失敗の通知先を確かめる
以前は、Let's Encryptが、期限が近づくと知らせるメールを送っていた。2025年6月26日の告知は、その終了を、「This service ended on June 4, 2025.」（訳: このサービスは、2025年6月4日に終了した）と書いている。公式は、代わりに第三者の見回りの仕組みを勧めている。つまり、更新が止まったときに知らせる仕組みは、自分で用意するものになっている。確かめるのは、通知の宛先が、いま読まれているメールアドレスか、である。
🅲 手順7 — 10月14日以降に、試験環境で更新を試す
告知は、「We will switch to issuing 64 day certificates in our staging environment on October 14, 2026 to enable testing.」（訳: 試験のために、2026年10月14日に、試験環境で64日の証明書の発行に切り替える）と書いている。試験環境の公式の説明は、Certbotでの使い方を、「you can use our staging environment with the --test-cert or --dry-run flag」（訳: --test-certか--dry-runの指定で、試験環境が使える）と書く。本番の証明書を触らずに、更新の流れを通せる。結果は、「成功」か「失敗」かと日付を書いて残す。
05 自分のサイトで確認するチェックリスト
下の13項目は、1項目5分ほどでできる作業である。項目1〜3が手順2、項目4・5が手順1、項目6・7が手順3、項目8が手順4、項目9・10が手順5、項目11が手順6、項目12が手順7、項目13が日付の登録に対応している。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。
- 自社サイトのトップページを開き、錠前のアイコンから証明書の情報を表示して、発行者の欄の名前を、そのままメモに書く
- 同じ画面で、有効期間の開始日と終了日を読み、終了日から開始日を引いた日数を書く（90日なら「90」と書く）
- 公開している別のドメインか、サブドメインを3つ選び、項目1と項目2を繰り返して、結果を1行ずつ書き並べる
- 各ドメインの証明書の更新を、誰が行っているか（自分・制作会社・サーバー会社）を、1行ずつ書く
- 任せている先に、「更新は自動か」「ARIに対応しているか」「2027年2月10日への対応予定日」「失敗時の通知先」の4つを、1通のメールにまとめて送り、送った日付を書く
- 自分で管理しているサーバーで、cronの設定とsystemdのタイマーの一覧を出し、証明書の更新の命令が書かれた行を探して、見つかった行の数を書く
- 更新の設定、スクリプト、手順書の中から、83・80・60のような日数の数字を検索し、見つかった数と場所を書く（見つからなければ「0件」と書く）
- 使っている更新ソフトの名前と版を調べ、公式の説明にARIへの対応が書かれているかを、「はい」「いいえ」「不明」のどれかで書く
- 更新に成功したあとで、Webサーバーに新しい証明書を読み直させる命令（deploy hookか再読み込み）が設定されているかを、「ある」か「ない」で書く
- 直近の更新の日付を探し、その日の前後で、外から見える期限の日付が実際に変わったかを、「変わった」か「変わらない」で書く
- 更新に失敗したときの通知の宛先を1つ書き、そのメールアドレスの受信箱で、直近3か月に届いた証明書の通知の数を数えて書く
- 10月14日以降に、試験環境を使った更新の試運転（Certbotなら--dry-run）を1回行い、結果を「成功」か「失敗」で書く
- 2027年2月10日、2027年5月11日、自社で最後に残る90日の証明書の期限の日付の3つを、カレンダーに登録して、登録した日を書く
06 代替・他の選択肢 — 手作業のまま使う、短い証明書を自分で選ぶ
Let's Encrypt以外の無料の証明書も、同じ規則の下にある
ACMEで自動更新できる無料の証明書は、Let's Encrypt以外にもある。ZeroSSLの公式の説明は、ACMEの機能で、90日の証明書を無料で、いくつでも発行できると書いている。使うには、管理画面で作るEAB（外部アカウントの結びつけ）の情報が要る。Google Trust Servicesの公式ページは、GTSのACMEのAPIで、公開で信頼される証明書を無料で出すと書き、Googleのクラウドの文書は、利用にはEABに対応したACMEクライアントが要ると書いている。この記事は、Google側の証明書の有効期間の日数を、公式の文書で確かめられなかった。
どの会社を選んでも、日数を決めるのは会社だけではない。CA/Browserフォーラムの基本要件（版2.3.1・2026年10月4日付）は、証明書の最長の有効期間を、2026年3月15日から200日、2027年3月15日から100日、2029年3月15日から47日と定めている。ZeroSSLの90日は今の上限の内側だが、2029年3月15日以降に発行する証明書は、47日以内でなければならない。会社を乗り換えて逃げられる話ではなく、どこを使っても、自動更新と、日数を決め打ちしない設定が要る。
手作業で更新しているサイト
証明書を、手作業で更新しているサイトもある。2025年12月の告知は、この方法に否定的である。
"Manually renewing certificates is not recommended, as it will need to be done more frequently with shorter certificate lifetimes."
（訳: 証明書の手作業での更新は勧めない。有効期間が短くなると、より頻繁に行う必要があるためである。）
更新の回数は、この記事の計算で、64日の証明書を約43日ごとなら年に約8.5回、45日なら30日ごとで年に約12回である。手作業のままにするなら、年に8〜12回、カレンダーの予定として動かせるかを、先に見積もる。
45日・6日の証明書を、自分で選ぶ
2027年2月10日を待たずに、短い証明書を選ぶ方法もある。公式のプロファイルの説明は、tlsserverを、「for subscribers who want smaller certificates and who fully embrace automation」（訳: より小さい証明書を求め、自動化を全面的に受け入れる利用者のため）と書いている。公式のよくある質問は、6日の証明書の更新について、「every three days」（訳: 3日ごと）を勧めている。短い証明書を選ぶ人ほど、自動更新が止まったときの被害が早く出る。
DNSの確認の方法を変える
2025年12月の告知は、認証の再利用期間が縮むことへの手当てとして、DNS-PERSIST-01という確認の方法の標準化を進めていると書いている。DNSのTXTの記録を、更新のたびに変えなくてよい方法である。この記事は、いまの提供の状況を確かめていない。使う前に、公式の最新の説明を開く。
確認の手がかりになる、当サイトの無料ツール
外から見える状態を一覧で見たいときは、当サイトの無料ツール🔧 WEBサイト総合分析・レポートツールが使える。外からの点検は、ログインして使う🔧 WEBサイトの外からできるセキュリティ対策監査ツールが手がかりになる。どちらも、証明書の有効期間や、更新の設定を判定するツールではない。
注意
更新の設定や、スクリプトを直すときは、直す前の状態を、日付つきで控えておく。更新が止まると、期限が切れた日に、サイトの入口にブラウザの警告が出る。試験環境で成功することを確かめてから、本番の設定に触る。
HTTPSの切り替えと、確認の画面の関係は、当サイトの記事「Chrome 154は、HTTPのページを開く前に既定で確認を出す。最終ページがHTTPSでも、転送の途中がHTTPなら出る ── 自社の入口を1つずつ開いて確認する13項目（2026年10月時点）」で扱った。この記事は、その内容を繰り返さない。
07 当サイトで確かめたこと
Let's Encryptの公開の入口に、ARIの項目があった
2026年10月9日16時57分に、Let's Encryptの本番と試験環境の、公開のディレクトリの情報（ACMEの入口の一覧）を開いた。どちらにもrenewalInfoの項目があった。針の確認として、同じ一覧に、注文の入口を示すnewOrderの項目があることも見た。一方、でたらめな名前の項目は、どちらにも0件だった。
言えるのは、認証局の側が、ARIを出していることだけである。当サイトの更新ソフトがARIを使っているかは、外からは見えない。
手元のパソコンで試したら、証明書が差し替わっていた
手順2のOpenSSLの命令を、2026年10月9日16時54分に、手元のパソコンから、当サイトの入口に向けて実行した。発行者の欄には、セキュリティソフトが、通信の検査のために作った、という意味の文字列が出た。サイトの本物の証明書ではなく、ソフトが作り直した証明書の情報だった。
そこで、同じ確認を、別の経路から行い直し、本物の証明書の期限の日付を読み取った。この結果は、当サイトの記事「外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた」で書いた、外から取った画面が、目当ての画面とは限らない、という話と同じ形である。
当サイトでも、期限の日付を確かめた
当サイトも、この記事の手順2に沿って、期限の日付と有効期間を読んだ。更新ソフトの名前や版、設定の中身などの細部は、載せると狙われやすくなるため、この記事には書かない。外から読めるのは、期限の日付だけである。
08 このテーマの、これまで
公式ブログの、日付つきの記録
| 日付 | 告知 | 要点 |
|---|---|---|
| 2025年6月26日 | 期限の通知メールの終了 | 2025年6月4日に、通知メールの送信を終えた |
| 2025年9月16日 | ARIがRFC 9773に | 更新の時期を、認証局が伝える仕組みが標準になった |
| 2025年12月2日 | 45日への短縮の予告 | 2026年5月・2027年2月・2028年2月の3段で進める |
| 2026年2月24日 | 速度制限と短縮 | 更新は速度制限の対象外で、制限の変更は要らない |
| 2026年10月7日 | 64日の告知 | 2027年2月10日から標準が64日になる |
当サイトの、関連する過去の記事
- 記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかった — 確認項目を、自分のサイトに当てた話。
- 外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた — 外から取った画面の読み違いの話。
- Search Console の通知 65 件のうち 33 件が未読だった ── 「修正を検証」を押さなかった理由と、毎週の点検にした日 — 通知を溜めていた話。
- 「測定中」と書いてあると、誰も測らなくなる ── llms.txtの52日分のログを、宣言から15日後に初めて開いた — 測定の約束を、測り直す話。
- 警告1,440件の中に、本物は2件だけだった ── 「報告は大げさ」は正しかったのに、記事ページは本当に遅かった — 大量の警告の中の本物の話。
現在の貴方のIPアドレス
このサイトで書いている人
