WebサイトのHTTPSを支える証明書は、普段は意識しないほど静かな部品です。ところが期限切れになると、ブラウザの警告やAPI接続の失敗として一気に表面化します。無料CAのLet’s Encryptは、2027年2月10日から標準の証明書有効期間を90日から64日へ短縮する予定です。
「まだ数カ月先」と思うかもしれません。しかし、更新日を固定値で計算したcron、成功通知だけを見て実際の配布を確かめていない構成、証明書を差し替えてもWebサーバーを再読み込みしない構成では、短い有効期間が小さな見落としを早く表に出します。今のうちに更新の流れを一本通して確かめておくと、期限変更を単なる不安ではなく運用改善のきっかけにできます。
64日化は、HTTPSを手作業で更新するための新ルールではありません。
狙いは、発行・検証・配布・再読み込みまでを自動化し、失敗したときだけ人が気付ける状態から抜け出すことです。
Let’s Encryptの「64日」はいつ、何が変わる？
Let’s Encryptの公式発表によると、2027年2月10日以降に発行または更新される証明書は、標準で64日間有効になります。最後の90日証明書は2027年5月11日までに期限を迎える見込みで、今回の移行に伴って有効な証明書が取り消されるわけではありません。
つまり、2月10日の朝に全サイトが切り替わるのではなく、次の更新から短い期間の証明書を受け取る流れです。まずは自分の環境で、現在の証明書の発行元、有効期限、更新クライアント、更新の実行場所を結び付けて見ておきましょう。CDN、ホスティング、ロードバランサーを使う場合は、どの層が証明書を管理しているかも重要です。
見るべき数字は「残り日数」だけではありません。証明書を更新するプロセスが、DNSやHTTPの検証を通り、正しいサーバーへ新しい証明書を置き、実際に読み直せているかまでが一つの仕事です。
90日運用のまま、どこで詰まりやすいのか
有効期間が短くなると、失敗が増えると決まったわけではありません。きちんと自動化され、失敗を検知できる構成なら、運用者が毎回カレンダーを数える必要はありません。一方で、更新日を「有効期限の83日前」「80日前」「60日前」のように固定したスクリプトや手順書は、見直し候補になります。
Let’s Encryptは、有効期間から固定日数を引くのではなく、有効期間のおよそ3分の2で更新するよう案内しています。64日なら約43日、将来45日になれば約30日というように、期間に合わせて動く考え方です。設定値を一つ直して終わりにせず、古いcron、ラッパースクリプト、運用メモにも固定値が残っていないか探すと安心です。
更新コマンドが成功しても、利用中の証明書が変わったとは限りません。更新後に外部から有効期限と発行者を確認し、NginxやApache、アプリのプロキシが新しいファイルを読んでいるかまで確かめてください。
ARI対応なら、更新時期を「推測」しなくてよい
ACMEには、CAがクライアントへ適切な更新時期を伝えるARI（ACME Renewal Information）という仕組みがあります。Let’s Encryptの説明では、ARIに対応した自動更新クライアントなら、CA側から示されるタイミングを利用できるため、今回の短縮にも対応しやすいとされています。
ただし、ここで「自動更新を使っているから大丈夫」と決めつけるのは早計です。クライアントがARIを実装しているか、ホスティングやコンテナ基盤がどのクライアントを呼んでいるか、更新後のデプロイ処理まで連動しているかは別の確認項目です。実装を増やす前に、今の構成を一枚の図にしてみると、責任の切れ目が見つかりやすくなります。
一時公開の経路と継続運用の入口を分ける考え方は、Cloudflare Quick Tunnelsの記事にも通じます。短時間のプレビューでは動いても、本番の更新・配布・監視が回るとは限りません。
ARIは更新処理そのものを代行する機能ではありません。
対応するクライアント、DNSやHTTPの認証、鍵ファイルの保護、更新後の再読み込み、障害通知は、それぞれの環境で引き続き整える必要があります。
ステージングで先に通したい「更新から再読み込み」
Let’s Encryptは、本番変更に先立ち2026年10月14日にステージング環境で64日証明書の発行へ切り替える予定です。テスト用のドメインや検証環境があるなら、本番の期限を待たずに一連の更新を試せます。
試す順番は難しくありません。まず現在使うクライアントで証明書を取得し、次に実際の配布先へ反映し、Webサーバーやリバースプロキシを安全に再読み込みする。最後に外部から接続して、証明書の有効期限とホスト名を確認します。ここで失敗したときに通知が届くか、誰が対応するか、元へ戻すには何が要るかも一緒に決めておきたいところです。
ステージングの成功を「本番も必ず成功する証明」とは扱わず、設定差を洗い出す場にしましょう。DNSプロバイダー、コンテナの永続ボリューム、権限、ロードバランサーの反映待ちなど、本番だけにある要素を順に足していくと確認が具体的になります。
2028年の45日化まで見据えると、何を残すべきか
これは64日で終わる話ではありません。Let’s Encryptの今後の機能案内では、標準のclassicプロファイルは2028年2月16日に45日へ、認証結果を再利用できる期間も7時間へ短縮される計画です。証明書の更新頻度だけでなく、認証のやり直しに必要なDNSやHTTPの到達性を、より安定して保つ必要が出てきます。
一方で、更新リクエストが増えるから既存ドメインの更新が直ちにレート制限へ引っかかる、という話ではありません。Let’s Encryptはレート制限の説明で、更新は新規発行向けの制限とは別であり、この変更でレート制限は影響を受けないと案内しています。心配すべき中心は回数ではなく、更新を最後まで通せるかです。
64日化は、サーバーを毎月慌てて触る未来を意味しません。今のうちに証明書の担当、更新ログ、失敗通知、再読み込み、外部確認をつなげておけば、45日化のときも同じ仕組みをそのまま磨けます。HTTPSを「期限切れの直前に思い出す作業」から、「静かに成功を確認できる自動処理」へ変える好機にしたいところです。
