Dev Study
← Webを支えるソフトウェア
レッスン 8 / 13·約 9 分·第3期 Webを支えるソフトウェア

証明書は誰が更新するのか — ACMEと期限

リクエストがアプリケーションに届くまで
  1. ブラウザURL入力
  2. DNS名前→IP
  3. ルータ経路選択
  4. ロードバランサ振り分け今ここ
  5. Nginx受け口
  6. アプリ処理
  7. DB保存

第33週で「どこで暗号を解くか」を見ました。その暗号を成立させる証明書には期限があり、誰かが更新し続けなければなりません。

まず結論

証明書の有効期間の上限を決めているのはRFCではなく、CA/Browser Forum という業界団体の Baseline Requirements です。そしてその上限は2026年3月に大幅に短縮されました。

「上限は398日」という広く流布した値は、現時点では古い値です。期限にまつわる数字は更新され続けるので、「いつ時点の値か」を確かめずに引用できません。

? 読む前に予測

「公的に信頼されるTLSサーバ証明書の有効期間の上限は398日である」——この説明を評価してください。

当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。

抽象原理

証明書には期限があり、誰かが更新し続ける

第33週で、暗号をどこで解くかを見ました。その暗号を成立させているのが証明書です。そして証明書には必ず期限があります。

期限が切れれば、利用者のブラウザは警告を出し、通信は事実上止まります。つまり証明書の運用とは、期限が来る前に新しいものへ置き換え続ける作業です。人手でやると忘れるので、自動化のプロトコルが作られました。それが ACME(RFC 8555) です。

ただし今週の主題は自動化そのものではなく、**「その数字はどの文書が、いつ時点で決めたのか」**です。この領域は数字が更新され続けるからです。

具体実物

上限を決めているのはRFCではない

「証明書の有効期間の上限は何日か」を調べると、出典が3つの層に分かれていることが分かります。

誰が何を決めているか表
文書                              決めていること
RFC 8555(ACME)                   発行・更新を自動化する手順
                                → 有効期間は規定していない
CA/Browser Forum                  有効期間の上限
Baseline Requirements             → 業界団体の文書。RFCではない
各CAの運用方針                     実際に発行する期間
(例: LE の既定90日。2026-09時点)  → 上限より短く自分で選べる

よくある誤解が**「90日はACMEが決めている」です。RFC 8555 に有効期間の規定はありません。90日は Let's Encrypt という一つのCAの選択です。同社は理由を「鍵の漏洩と誤発行による被害を抑える」「自動化を促す」と説明し、「これらの理由から、当社は90日を超える有効期間の証明書を提供していない」と一人称で述べています(2015年の記事)。ただし90日は2026年9月時点**の既定です。同社は2025-12-02の告知で、既定を2027-02-10に64日、2028-02-16に45日へ短くすると発表しています。

✓ ここまでの確認

「Let's Encrypt の証明書が90日なのは、ACME(RFC 8555)がそう定めているからだ」——この説明は正しいですか。

具体実物

ACMEのチャレンジ — 何を証明しているのか

自動更新の中心にあるのがチャレンジです。CAは「あなたが本当にそのドメインを支配しているのか」を確かめる必要があり、その確かめ方が定義されています。

RFC 8555 の2つの定義文は、並べるときれいに対になります。

RFC 8555 の定義(§8.3 / §8.4)表
§8.3 HTTP Challenge
特定の HTTP リソースをプロビジョニングさせることにより
ドメイン名の支配を証明する
 
§8.4 DNS Challenge
特定の DNS リソースをプロビジョニングさせることにより
ドメイン名の支配を証明する

証明している対象は同じです。どちらも「ドメイン名の支配」であって、片方が「サーバの所有」を証明しているわけではありません。違うのは、何を置かせるかだけです。

もう一つ注意すべき点があります。3つ目のチャレンジ tls-alpn-01 は、RFC 8555 に登場しません。 これは別文書 RFC 8737(2020年2月) が定義するもので、ALPN識別子 "acme-tls/1" を使います。「ACMEの話題だから8555だろう」という連想が、そのまま誤帰属になる例です。

✓ ここまでの確認

ACMEの http-01 チャレンジと dns-01 チャレンジは、それぞれ何を証明するものですか。RFC 8555 の趣旨に即して選んでください。

⇄ 2つを見比べる
具体例 A

証明書の更新(今週)

期限が来る前に新しい証明書へ置き換えます。Let's Encrypt はARIの指示での更新を第一に、予備として残り3分の1での更新を推奨し、90日証明書なら期限の30日前にあたると述べています。有効期間を短くする理由として同社が挙げるのは、鍵の漏洩と誤発行の被害を抑えることです。

期限と取り直しのタイミング表
有効期間   上限は BR が決める(短縮が進行中)
実際の期間 各CAの方針(LE は2026-09時点で90日)
更新時期   ARIの指示。予備に残り1/3 = LEの推奨
具体例 B

DNSレコードのTTL(第25週)

第25週で見たように、DNSの応答にはTTLが付き、その時間が過ぎるとキャッシュは権威サーバへ問い直します。TTLを短くすれば変更が早く行き渡りますが、問い合わせの回数は増えます。

期限と取り直しのタイミング表
有効期間   TTL(レコードごとに設定)
取り直し   TTL 経過後、権威サーバへ問い直す
短くすると 変更が早く反映。問い合わせは増える

証明書の有効期間とDNSのTTL。この2つに共通する構造は何でしょうか。そして「期間を短くする」という判断は、どちらでも何と引き換えになっているでしょうか。

「期限が切れたら何が起きるか」と「期限を短くすると何が増えるか」を両方について考えてください。

この章のまとめ

  • 有効期間の上限を決めているのはRFCではなく CA/Browser Forum の Baseline Requirements(業界団体の文書)。
  • BR §6.3.2: 2026-03-15 以降の発行分は200日、2027-03-15 以降は100日、2029-03-15 以降は47日(施行日の一覧は §1.2.2)。
  • 「398日」は現時点の上限ではない。 2026年3月に大幅短縮された。学習データに残りやすい古い値の代表例。
  • RFC 8555 に有効期間の規定は無い。 Let's Encrypt の90日(2026年9月時点の既定。短縮が告知済み)はそのCA自身の方針(「当社は提供していない」という一人称)。
  • 更新タイミングもRFCの規定ではない。 Let's Encrypt はARIの指示を第一に推奨し、「残り1/3(90日なら30日前)」はその予備。
  • http-01 と dns-01 はどちらも「ドメイン名の支配」を証明する。 違いは何をプロビジョニングさせるか。
  • tls-alpn-01 は RFC 8737。 RFC 8555 にこの語は登場しない。

自分の現場で確かめる

読んだだけでは身につきません。手元の環境で実際に見てみてください。

環境:

理解度チェック

読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。

問題 1 / 3正解: 0

証明書の有効期間の上限について、出典として正しい組み合わせはどれですか。

用語集(5語)
CA/Browser Forum Baseline Requirements
公的に信頼されるTLSサーバ証明書の発行と管理について、CAとブラウザベンダが合意した業界団体の文書。RFCではない。有効期間の上限はここで決まる。
Validity Period(有効期間)
Baseline Requirements §1.6.1 の定義では「notBefore から notAfter まで(両端を含む)の期間」。証明書の中に書かれた2つの日時で決まる。
ACME(RFC 8555)
証明書の発行・更新を自動化するプロトコル。ドメイン名の支配を証明するチャレンジの仕組みを定める。有効期間や更新タイミングは規定していない。
http-01 / dns-01
ACMEのチャレンジ。どちらも「ドメイン名の支配」を証明する。違いはHTTPリソースをプロビジョニングさせるか、DNSリソースをプロビジョニングさせるか。
tls-alpn-01
ALPN識別子 "acme-tls/1" を使うチャレンジ。定義は RFC 8737(2020年2月)であって RFC 8555 ではない。

出典(一次ソース)