WEBサイトLet's Encryptのドメイン確認の使い回しは30日から10日に縮む。通常の更新は、寿命の約3分の2で動くなら毎回確認し直している計算になる ── 確認の方法が毎回通るかを自社で確かめる14項目（2026年10月時点）
Let's Encryptのドメイン確認の使い回しは30日から10日に縮む。通常の更新は、寿命の約3分の2で動くなら毎回確認し直している計算になる ── 確認の方法が毎回通るかを自社で確かめる14項目（2026年10月時点）
目次
01 何が起きたか — ドメイン確認の使い回しは30日から10日に縮むが、通常の更新は、寿命の約3分の2で動くなら毎回確認し直している計算になる
2026年10月7日の告知の、使い回しに関する2文
Let's Encryptの公式ブログに、2026年10月7日付で「64-Day Certificate Lifetimes Coming Feb 2027」（訳: 64日の証明書の有効期間が2027年2月に来る）が載った。有効期間が64日になる話は、当サイトの記事「Let's Encryptの証明書は2027年2月10日から標準で64日になる ── 更新の設定の「日数の決め打ち」とARI対応を確かめる13項目（2026年10月時点）」で扱った。この記事が扱うのは、同じ告知の中で短く触れられている、ドメインの持ち主だと確かめた結果の使い回しである。2026年10月12日に本文を開いて確かめた該当の部分は、次の2文である。
"We will also be reducing the authorization reuse period from 30 days to 10 days. In 2028, the reuse period will shrink to seven hours."
（訳: Let's Encryptは、認可の再利用期間も、30日から10日に縮める。2028年には、再利用期間は7時間に縮む。）
「認可」は、証明書を出す側（認証局）が、「この利用者はこのドメインを扱ってよい」と認めた記録を指す。つまり、一度ドメインの確認に通ると、その結果を30日間は次の発行にも使える仕組みが、10日、続いて7時間まで短くなる。
使い回しに頼らない設定には、変更は要らない
"Unless you have specifically designed your ACME client to rely on validation reuse, you will not need to make any changes."
（訳: ACMEクライアントを、確認の再利用に頼るように、わざわざ設計していない限り、何も変える必要はない。）
「ACMEクライアント」は、証明書の発行や更新を自動で行うソフト（Certbotなど）のことである。この文は、自分の更新が使い回しに頼っているかどうかが分かれ目だと言っている。ただし、告知は確かめ方まで書いていない。この記事は、そこを整理する。
日付を、使い回しの期間の側から並べる
使い回しの期間に関わる日付を、Let's Encryptの2025年12月2日の告知と、同じ公式の「プロファイル」の説明ページから並べると、次の表になる。業界の決まり（基本要件）の上限も、同じ説明ページに書かれている。
| 日付 | 変わること | 書かれている場所 |
|---|---|---|
| 現在 | 標準のプロファイル（classic）の再利用期間は30日 | プロファイルの説明（2026年10月4日更新） |
| 2027年2月10日 | 標準のプロファイルで、再利用期間が10日になる | 2025年12月2日の告知 |
| 2027年3月15日 | 業界の決まりの上限が、この日以降に発行する証明書で100日になる | プロファイルの説明 |
| 2028年2月16日 | 標準のプロファイルで、再利用期間が7時間になる | 2025年12月2日の告知 |
| 2029年3月15日 | 業界の決まりの上限が、10日になる | プロファイルの説明 |
この記事の見立て: 通常の更新は、寿命の約3分の2で動くなら毎回確認し直している
ここからは、この記事の計算である。更新ソフトが、寿命の約3分の2の時点で更新するなら（2026年10月7日の告知が、決め打ちの設定の直し先として勧めている形）、90日の証明書では、発行から約60日後に更新が動く。再利用期間は30日なので、次の更新のときには、前回の確認の結果は、もう使えない。
| 証明書の有効期間 | 更新の間隔（寿命の約3分の2） | 再利用期間 | 年あたりの更新と確認の回数 |
|---|---|---|---|
| 90日（現在） | 約60日 | 30日 | 約6回 |
| 64日（2027年2月10日から） | 約43日 | 10日 | 約8.5回 |
| 45日（2028年2月16日から） | 30日 | 7時間 | 約12回 |
更新の間隔は、いつも再利用期間より長い。決まった間隔の更新だけなら、使い回しは今も効いていない。効くのは、再利用期間より短い間隔で、同じドメインの証明書をもう一度出すときだけである。実務で効いてくるのは、むしろ確認が年に約6回から約12回に増えることのほうで、確認の方法が毎回通るかどうかが、この記事の本題になる。
02 なぜ・背景 — 業界の決まりと、CAAの再確認が理由になっている
告知が書く、短くする理由
"We are making this change to comply with a 2029 reduction in maximum validation reuse periods, and to remove the need for “CAA rechecking”, where we have to repeat part of the validation process if the validation data is more than 7 hours old."
（訳: この変更は、2029年に確認の再利用期間の上限が縮められることに合わせるため、そして、確認のデータが7時間より古い場合に確認の過程の一部をやり直さなければならない「CAAの再確認」の必要をなくすために行う。）
理由は2つある。1つは、業界の決まりが、2029年3月15日に再利用期間の上限を10日にすること。もう1つは、CAAの再確認を避けることである。CAAは、「このドメインの証明書を出してよい会社」をDNSに書いておく記録で、03章で説明する。
7時間と8時間、公式の2か所で書き方が違う
同じ公式の「プロファイル」の説明ページは、再利用期間が7時間の理由を、別の書き方で説明している。
"This is because the Baseline Requirements require that we re-check Certification Authority Authorization (CAA) after eight hours, so limiting the reuse period means that we don’t have to perform rechecks."
（訳: これは、基本要件が、認証局による認可（CAA）を8時間後に再確認するよう求めているためで、再利用期間を限れば、再確認をしなくて済む。）
告知は「7時間より古い」、プロファイルの説明は「8時間後」と書いている。この記事は、2つの書き方の違いを、公式には確かめていない。7時間は、8時間の基準に余裕を持たせた値だろうと読めるが、これは推測である。
上限は先に決まっていて、確認の回数は増える
プロファイルの説明は、基本要件が再利用期間の上限を200日とし、2027年3月15日以降に100日、2029年3月15日以降に10日へ下げると書いている（01章の表）。ほかの認証局に乗り換えても、2029年3月15日以降は、10日を超えない決まりの下に置かれる。2025年12月の告知は、利用者への影響を、こう書いている。
"Reducing certificate lifetimes and the authorization reuse period will make users need to demonstrate control more often."
（訳: 証明書の有効期間と認可の再利用期間を短くすると、利用者は、ドメインを管理していることを、より頻繁に示す必要が出てくる。）
03 用語 — 認可・チャレンジ・CAAを先にそろえる
認可と、その使い回し
用語
認可（authorization）：ACMEという発行の決まりの中で、認証局が、ある利用者のアカウントに、あるドメイン名を扱ってよいと認めた記録である。RFC 8555は、有効期限の項目「expires」を、「The timestamp after which the server will consider this authorization invalid, encoded in the format specified in [RFC3339].」（訳: この時刻を過ぎると、サーバーはこの認可を無効とみなす。形式はRFC 3339に従う）と定めている。Let's Encryptのよくある質問は、確認が通った認可が「あなたのアカウント向けに」保存されると書いている。つまり、使い回しはアカウントごとの話になる。
よくある質問は、使い回しが起きたときの見え方も書いている。
"If the certificate you requested has all of the necessary authorizations cached then validation will not happen again until the relevant cached authorizations expire."
（訳: 要求した証明書に必要な認可がすべて保存されていれば、保存された認可が期限切れになるまで、確認は再び行われない。）
つまり、使い回しが起きたときは、更新に成功したのに、確認が行われなかったように見える。同じ質問ページは、期間を「up to 30 days from the time of validation, depending on the associated profile」（訳: 確認の時点から最長30日で、関連するプロファイルによって決まる）とも書く。プロファイルの説明では、既定のclassicが30日、自分で選ぶtlsserverとshortlivedは、すでに7時間である。
チャレンジ: 確認の方法そのもの
用語
チャレンジ（challenge）：ドメインの持ち主だと示すための、確認の方法である。HTTP-01は、Webサーバーに確認用のファイルを置く方法で、80番のポートで行う。DNS-01は、DNSに確認用のTXT記録を置く方法である。公式の説明は、迷ったら更新ソフトの既定か、HTTP-01を選ぶよう書いている。
CAA: 証明書を出してよい会社の記録
用語
CAA（Certification Authority Authorization）：ドメインのDNSに書いておく、証明書を出してよい会社の記録である。RFC 8555は、ACMEのディレクトリ情報の「caaIdentities」の項目を、「This allows clients to determine the correct issuer domain name to use when configuring CAA records.」（訳: これにより、クライアントは、CAA記録を設定するときに使う、正しい発行者のドメイン名を知ることができる）という目的で定めている。Let's Encryptの公開のディレクトリ情報には、この項目に「letsencrypt.org」が載っている（07章で開いて確かめた）。
04 型別 — 使い回しに頼る設計かと、毎回の確認が通るかを、分けて確かめる
🅰 適用範囲 — 使い回しに頼りうる、4つの場面
告知は、使い回しに頼る設計の例を挙げていない。次の4つは、この記事の整理であり、公式の文ではない。再利用期間より短い間隔で、同じアカウントから、同じドメインの証明書をもう一度出す場面である。
- 手作業の確認: TXT記録やファイルを人が置き、一度通った確認を、追加の発行に使い回している
- 名前の追加: 確認済みの名前が残るうちに、新しい名前を足した証明書を作り直している
- 複数の場所での発行: 同じアカウントで、複数のサーバーや環境が、同じ名前の証明書を別々に出している
- 短い間隔の再試行や試験: 失敗した更新を何度もやり直したり、強制的な更新を試したりしている
どれにも当てはまらない自社は、使い回しの短縮では、ほぼ何も変わらない。確認の回数は増えるので、手順は「毎回の確認が通るか」を中心に組む。
🅱 その告知が測っていないこと
- 各更新ソフトが、使い回しの短縮をどう扱うかは、確かめていない
- DNS-PERSIST-01という新しい確認の方法が、Let's Encryptの本番で使えるかは、確かめていない（06章）
🅲 手順1 — 証明書と、確認の方法を書き出す
最初に、証明書を管理しているドメインを全部書き出し、ドメインごとに、発行元と有効期間の日数を読む。ブラウザなら、アドレスの横の錠前のアイコンから、証明書の情報を開くと、発行者と、開始日・終了日が出る。
次に、確認の方法を調べる。Certbotの公式の説明は、設定ファイルを「/etc/letsencrypt/renewal/」の下と書き、例に「authenticator = standalone」の行を載せている。この行の値が、確認の方法を決める。手作業の確認は、特に注意する。
"Certificates created using --manual do not support automatic renewal unless combined with an authentication hook script via --manual-auth-hook to automatically set up the required HTTP and/or TXT challenges."
（訳: --manualで作った証明書は、必要なHTTPやTXTのチャレンジを自動で用意する認証用のフックのスクリプトを--manual-auth-hookで組み合わせない限り、自動更新に対応しない。）
🅲 手順2 — 更新の間隔を、記録から計算する
更新の記録から、直近の更新の日付を3回分書き、前回との間隔を日数にする。Certbotの公式の説明は、ログの置き場を「/var/log/letsencrypt」と書いている。
間隔が10日より短い更新が1回でもあれば、使い回しが効いていた可能性がある。失敗のやり直しか、手動の実行か、設定の変更かを、一言添えて残す。同じ名前を含む証明書が何枚あるかも、ここで数える。Let's Encryptの速度制限の説明は、全く同じ名前の組み合わせに、「Up to 5 certificates can be issued per exact same set of identifiers every 7 days.」（訳: 全く同じ識別子の組み合わせでは、7日ごとに最大5枚まで証明書を発行できる）という上限を書いている。
🅲 手順3 — HTTP-01なら、80番のポートと確認用の道を確かめる
HTTP-01の確認は、確認用のファイルを、http://ドメイン/.well-known/acme-challenge/トークンの形のアドレスで取りに来る。転送の扱いは、公式が書いている。
"Our implementation of the HTTP-01 challenge follows redirects, up to 10 redirects deep."
（訳: HTTP-01のチャレンジのLet's Encryptの実装は、10段までの転送をたどる。）
続けて、「It only accepts redirects to “http:” or “https:”, and only to ports 80 or 443.」（訳: 受け付ける転送先は「http:」か「https:」だけで、ポートは80番か443番だけである）と書く。つまり、HTTPからHTTPSへの転送はたどってもらえる。導入の手引きは、「We recommend always allowing plain HTTP access to your web server, with a redirect to HTTPS.」（訳: Webサーバーへの通常のHTTPの接続は、HTTPSへの転送をつけて、常に許可しておくことを勧める）と書く。
実務のヒント
確認に使うIPアドレスは、公開されていない。公式のよくある質問は、「We don’t publish a list of IP addresses we use to validate, and these IP addresses may change at any time.」（訳: 確認に使うIPアドレスの一覧は公開しておらず、これらのIPアドレスはいつでも変わりうる）と書く。特定のIPアドレスだけを許可する設定は、確認を止める原因になりうる。
Webサーバーが複数台なら、公式の説明は、「If you have multiple web servers, you have to make sure the file is available on all of them.」（訳: Webサーバーが複数あるなら、ファイルがそのすべてで利用できるようにしなければならない）と書く。台数を数えて、全台に置けるかを確かめる。
🅲 手順4 — DNS-01なら、TXTの記録と鍵の範囲を確かめる
DNS-01は、_acme-challenge.ドメインという名前のTXT記録を使う。更新ソフトが、DNSの会社のAPIを呼んで、更新のたびに記録を書き換える。確かめる点は2つある。
1つ目は、古いTXT記録が残っていないかである。公式の説明は、「However, you should make sure to clean up old TXT records, because if the response size gets too big Let’s Encrypt will start rejecting it.」（訳: ただし、古いTXT記録は掃除しておくこと。応答のサイズが大きくなりすぎると、Let's Encryptは受け付けなくなる）と書く。
2つ目は、DNSのAPIの鍵の範囲である。
"Note that putting your full DNS API credentials on your web server significantly increases the impact if that web server is hacked."
（訳: DNSのAPIの全権限の認証情報を、Webサーバーに置くと、そのWebサーバーが乗っ取られたときの影響が、大きく増すことに注意すること。）
反映の待ち時間も効く。公式の説明は、反映を確かめる手段がないDNSの会社では、確認を始める前に、更新ソフトを「often as much as an hour」（訳: 多くの場合、最長1時間ほど）待たせるよう書いている。待ち時間が足りないと、確認は失敗する。
🅲 手順5 — CAAの記録に、Let's Encryptの名前があるか調べる
CAAは、使い回しの短縮の理由の1つに挙げられていた。自社のドメインにCAAの記録があるかを調べる。なければ「CAAなし」で終わる。あれば、中にletsencrypt.orgが書かれているかを見る。名前は、公開のディレクトリ情報から読み取れる。
🅲 手順6 — 失敗が続くときの、再試行の回数を確かめる
確認が失敗したとき、更新ソフトが続けてやり直すと、制限に当たる。
"Up to 5 authorization failures per identifier can be incurred by one account every hour."
（訳: 1つのアカウントは、識別子ごとに、1時間あたり最大5回まで、認可の失敗を起こせる。）
失敗できる回数は、「1 per identifier every 12 minutes」（訳: 識別子ごとに12分に1回）の割合で回復する。連続の失敗には、別に最大1,152回の上限がある。原因を直さずに再試行を重ねると、制限で更新自体が止まる。更新ソフトの再試行の設定を、1時間あたりの回数に直して確かめる。
🅲 手順7 — 10月14日以降に、試験環境で更新を通す
公式の説明は、Certbotの試運転を、「--dry-run uses the Let’s Encrypt staging server, unless --server is specified on the CLI or in the cli.ini configuration file.」（訳: --dry-runは、コマンドラインかcli.iniの設定ファイルで--serverが指定されていない限り、Let's Encryptの試験用サーバーを使う）と書く。2026年10月14日からは、試験環境が64日の証明書を出すので、2027年2月10日の前に、新しい期間で更新が通ることを確かめられる。
05 自分のサイトで確認するチェックリスト
下の14項目は、1項目5分ほどでできる作業で、04章の手順1〜7に順に対応している。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。
- 証明書を管理しているドメインとサブドメインを全部書き出し、それぞれの発行元がLet's Encryptかどうかを、1行ずつ書く
- 書き出した各ドメインで、証明書の開始日と終了日を読み、有効期間の日数を書く（90日なら「90」と書く）
- 各証明書の確認の方法を、「HTTP-01」「DNS-01」「手作業」「不明」から1つ選んで書く（Certbotなら、renewalフォルダの設定ファイルのauthenticatorの行を見る）
- 確認が手作業の証明書の数を数えて書く（なければ「0件」と書き、数えた範囲も書く）
- 更新の記録から、直近3回の更新の日付を書き、前回との間隔を日数で2つ書く
- 項目5の間隔のうち、10日より短いものがあったかを、「ある」か「ない」で書き、あれば原因を一言書く
- 同じドメイン名を含む証明書が、何枚、何台のサーバーや環境で出されているかを、数えて書く
- HTTP-01を使うドメインで、外から
http://ドメイン/.well-known/acme-challenge/の後ろに存在しない適当な名前をつけて開き、返ったステータスコードを書く（403・接続できない・時間切れなら「要確認」と書く） - HTTP-01を使うドメインで、Webサーバーの台数と、確認用のファイルを置ける台数を書く（1台なら「1台」と書く）
- DNS-01を使うドメインで、DNSの管理画面を開き、
_acme-challengeで始まる名前のTXT記録の数を数えて書く（なければ「0件」と書く） - DNS-01で更新ソフトに渡しているDNSのAPIの鍵の権限を、「ゾーン全体」「TXT記録だけ」「不明」のどれかで書く
- 自社ドメインのCAAの記録を調べ、letsencrypt.orgが書かれているかを、「ある」「ない」「CAAなし」のどれかで書く
- 更新ソフトの再試行の設定を、1時間あたりの回数に直し、5回を超えるかを「超える」「超えない」「不明」のどれかで書く
- 2026年10月14日以降に、更新の試運転（Certbotなら--dry-run）を1回実行し、結果を「成功」か「失敗」で書き、失敗なら最初のエラー文を1行書く
06 代替・他の選択肢 — 確認の方法を選び直す
4つの確認の方法を、並べて比べる
確認の方法は、HTTP-01とDNS-01だけではない。Let's Encryptの公式の説明と、IETFの草案から、特徴を並べると、次の表になる。
| 方法 | 置くもの | 向く場面 | 公式が書く弱み |
|---|---|---|---|
| HTTP-01 | Webサーバーの確認用ファイル（80番） | 追加の知識なしで自動化しやすい。市販のWebサーバーで動く | 80番を塞ぐ回線では使えない。ワイルドカードは出せない。複数台では全台に必要 |
| DNS-01 | DNSのTXT記録 | ワイルドカード。複数台のWebサーバー。公開していないWebサーバー | DNSのAPIの鍵を置くリスク。APIの無いDNSの会社がある。反映の待ち時間 |
| TLS-ALPN-01 | 443番での専用の応答 | 80番が使えない場合。主に大きなホスティング事業者 | クライアントの対応が限られる。ワイルドカードは出せない |
| DNS-PERSIST-01 | 変えないTXT記録（認証局とアカウントの情報） | 更新のたびにDNSを書き換えたくない場合 | IETFの草案の段階。Let's Encryptの本番で使えるかは、この記事では確かめていない |
DNS-01の弱みを、減らす設計
公式の説明は、DNS-01の鍵の問題に、2つの手を挙げている。
"Best practice is to use more narrowly scoped API credentials, or perform DNS validation from a separate server and automatically copy certificates to your web server."
（訳: 最善の方法は、より範囲を絞ったAPIの認証情報を使うか、DNSの確認を別のサーバーから行い、証明書を自動でWebサーバーにコピーすることである。）
もう1つ、確認用の名前を、別のゾーンに委任する方法がある。公式の説明は、「you can use CNAME records or NS records to delegate answering the challenge to other DNS zones」（訳: CNAME記録かNS記録を使って、チャレンジへの応答を、ほかのDNSのゾーンに委任できる）と書く。
DNS-PERSIST-01という新しい方法
2025年12月の告知は、使い回しの短縮への手当てとして、新しい確認の方法を挙げている。
"The key advantage of this new method is that the DNS TXT entry used to demonstrate control does not have to change every renewal."
（訳: この新しい方法の最大の利点は、管理を示すために使うDNSのTXTの項目を、更新のたびに変えなくてよいことである。）
IETFの草案（draft-ietf-acme-dns-persist-02・2026年9月20日更新）は、認証局が、永続的なDNSのTXT記録の存在を確認して、ドメインの管理を確かめる方法として書いている。ただし、草案はまだ標準ではない。いまLet's Encryptの本番で使えるかは、この記事では確かめていない。使う前に、公式の最新の説明を開く。
確認の手がかりになる、当サイトの無料ツール
設定を見直したあと、公開ページが正しく返っているかを確かめたいときは、当サイトの無料ツール🔧 WEBサイト内のリンク漏れ・チェックツールが使える。外からのセキュリティの点検は、ログインして使う🔧 WEBサイトの外からできるセキュリティ対策監査ツールが手がかりになる（利用には無料の会員登録が必要です）。どちらも、証明書の更新の設定そのものを判定するツールではない。
注意
確認の方法を切り替えるときは、本番の設定に触る前に、試験環境で更新が通ることを確かめる。DNSの鍵を作り直したり、80番の設定を変えたりする場合は、直す前の状態を、日付つきで控えておく。確認が失敗し続けると、速度制限で更新が止まり、期限が切れた日に、ブラウザの警告が出る。
07 当サイトで確かめたこと
Let's Encryptの公開の案内（directory）で、プロファイルとCAAの名前を読んだ
2026年10月12日17時36分に、Let's Encryptの本番と試験環境の、公開のディレクトリ情報（ACMEの案内の一覧）を開いた。どちらにも、3つのプロファイル（classic・tlsserver・shortlived）の項目と、caaIdentitiesの項目があり、中身はletsencrypt.orgの1つだった。更新の時期を伝えるrenewalInfoの項目もあった。言えるのは、認証局の側が、複数のプロファイルとARIの案内を用意していることである。再利用期間の値は、この一覧には載っていない。
当サイトの証明書は、有効期間が90日だった
手順1に沿って、当サイトの証明書の開始日と終了日を読み、差を取ると90日だった。この記事では、外から見える範囲だけを扱う。外から読めたのは、有効期間の日数だけである。
当サイトの更新が、使い回しに頼っているかは、外からは見えない。通常の更新は使い回しが効かない、というのはこの記事の計算であって、確かめた事実ではない。2026年10月14日以降に試運転をしたら、結果を追記する。
08 このテーマの、これまで
公式の、日付つきの記録
- 2025年12月2日: 「Decreasing Certificate Lifetimes to 45 Days」（訳: 証明書の有効期間を45日に短くする）。再利用期間を7時間にする計画と、DNS-PERSIST-01の予告が載った
- 2026年10月7日: 「64-Day Certificate Lifetimes Coming Feb 2027」。再利用期間を30日から10日に縮めると書かれた
当サイトの、関連する過去の記事
- 記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかった — 確認項目を自分のサイトに当てた話。
- 外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた — 外から取った応答の読み違いの話。
- Search Console の通知 65 件のうち 33 件が未読だった ── 「修正を検証」を押さなかった理由と、毎週の点検にした日 — 通知を溜めていた話。
- 「0件」に、探した数を書いていなかった ── 9種類で確かめた5日後、73種類で確かめ直した — 「0件」には探した範囲も書く話。
- 「測定中」と書いてあると、誰も測らなくなる ── llms.txtの52日分のログを、宣言から15日後に初めて開いた — 約束した確認を期限つきで行う話。
現在の貴方のIPアドレス
このサイトで書いている人
