有効期間 47 日の TLS 証明書：スケジュールと自動化の対象

要点：2025年4月11日に採択された CA/Browser Forum の投票 SC-081 は、公的に信頼される TLS 証明書の最大有効期間を 3 段階で短縮します。2026年3月15日以降に発行される証明書の有効期間は最長 200 日、2027年3月15日以降は最長 100 日、2029年3月15日以降は最長 47 日になります。CA がドメイン検証を再利用できる期間も、同じ日付で 200 日、100 日、そして 10 日へと短くなります。実際には、すべての証明書を自動化（ACME）によって発行・デプロイしなければなりません。更新のタイミングは、CA が ARI で示す更新ウィンドウに従うべきです。また、失敗した更新を修正する時間がまだ残っているうちにアラートを出す監視が必要です。プライベート CA は影響を受けません。

スケジュール

このルールは ベースライン要件（バージョン 2.3.1、2026年10月）の 6.3.2 節と 4.2.1 節に定められています。投票 SC-081v3 は Apple が提案し、Sectigo、Google Chrome、Mozilla が賛同しました。CA の投票は賛成 25、反対なし、棄権 5 で可決され、ブラウザーベンダー 4 社もすべて賛成しました。

これらの数値を前提に計画を立てるうえで重要な詳細をいくつか挙げます。

• これらの数値は、CA が発行時に適用する上限です。2026年3月14日に発行された証明書なら、まだ 398 日間の有効期間が認められていました。期限切れになる前に交換しなければならないわけではありませんが、次に発行する証明書の有効期間は短くなります。
• 「有効期間」は両端の日を含めて数えます。BR（ベースライン要件）は有効期間を notBefore から notAfter まで（両端を含む）の期間と定義しており、1 日分の余裕を持たせることを推奨しています。証明書の有効期間は 199 日、99 日、46 日を超えるべきではありません（SHOULD NOT）。
• より大きな変化は、検証の再利用期間の上限です。現在、CA は example.com を管理していることの証明を数か月にわたって再利用できます。2029年以降はその証明が 10 日以内に取得されたものでなければならないため、ほぼすべての発行で新たなドメイン検証が必要になり、DNS や HTTP のチャレンジも自動化しなければなりません。
• OV 証明書と EV 証明書の組織の詳細情報（社名、所在地）は、825 日ではなく 398 日間再利用できます。
• 対象範囲：BR が規定するのは、公的に信頼される CA が発行する TLS サーバー証明書です。自社の内部 CA が発行する証明書、クライアント証明書、S/MIME 証明書は、別のルールに従うか、どのルールの対象にもなりません。

CA が現在発行している証明書

2026年10月20日時点で、いくつかの大規模サイトが提供している証明書は次のとおりでした。この出力は、監視のセクションにある lifetimes.sh スクリプトで取得したものです。

letsencrypt.org        Let's Encrypt              2026-09-04  ->  2026-12-03  (90 days)
www.google.com         Google Trust Services      2026-09-28  ->  2026-12-21  (84 days)
github.com             Sectigo Limited            2026-09-01  ->  2026-11-29  (90 days)
www.microsoft.com      Microsoft Corporation      2026-01-22  ->  2027-01-17  (360 days)
www.amazon.com         Amazon                     2026-01-19  ->  2027-01-11  (358 days)
www.digicert.com       DigiCert Inc               2026-10-11  ->  2026-11-26  (47 days)

このうち 2 つのサイトは、200 日の上限が適用される直前の 2026年1月に発行された、有効期間がほぼ 1 年の証明書をまだ使っています。DigiCert は自社サイトですでに有効期間 47 日の証明書を提供しています。Let's Encrypt が公開している計画は、BR の要求よりも速いペースで進みます。

• 2026年5月13日：オプトイン方式の tlsserver プロファイルが、有効期間 45 日の証明書を発行します。
• 2027年2月10日：デフォルトの classic プロファイルが有効期間 64 日の証明書を発行し、認可の再利用期間は 10 日になります。
• 2028年2月16日：classic プロファイルが有効期間 45 日の証明書を発行し、認可の再利用期間は 7 時間になります。

稼働中の ACME ディレクトリには、現在リクエストできるプロファイルが一覧で示されています。

"meta": {
  "profiles": {
    "classic": "https://letsencrypt.org/docs/profiles#classic",
    "shortlived": "https://letsencrypt.org/docs/profiles#shortlived",
    "tlsserver": "https://letsencrypt.org/docs/profiles#tlsserver"
  }
},
"renewalInfo": "https://acme-v02.api.letsencrypt.org/acme/renewal-info"

自動化すべきこと

有効期間 398 日の証明書であれば、年 1 回の手動更新は面倒ではあっても何とか乗り切れました。有効期間 47 日の証明書と 10 日の検証再利用期間のもとでは、手動更新はドメイン名ごとに年 8 回以上発生するエラーの起きやすい作業になり、有効期間の 3 分の 2 の時点で更新するなら 12 回近くになります。作業は 4 つに分かれます。

1. ACME による発行：公開 CA から取得するすべての証明書に、ACME クライアント（RFC 8555）を使います。商用 CA の多くも ACME エンドポイントを提供しており、外部アカウントバインディングを伴うことがよくあります。まだメール、ポータルからのダウンロード、チケットで受け取っている証明書があれば、真っ先に対応リストに加えてください。

2. 無人で実行できる検証：人手を介さずに完了するチャレンジを選びます。

• http-01 では、そのドメイン名で応答するすべてのホストで 80 番ポートに到達できる必要があります。
• dns-01 には DNS プロバイダーの API へのアクセスが必要です。プロバイダーが対応していれば、トークンのスコープを _acme-challenge レコードに限定してください。
• tls-alpn-01 は 443 番ポートだけで完結します。

まさにこうした状況のために作られた、新しい方式が 2 つあります。BR §3.2.2.4.21 の「DNS Labeled with Account ID」（ACME の dns-account-01 チャレンジ）を使うと、複数の ACME アカウントが 1 つの _acme-challenge レコードを奪い合うことなく、同じドメイン名を検証できます。「DNS TXT Record with Persistent Value」（§3.2.2.4.22、投票 SC-088）では、常設のレコードを一度公開するだけで済みます。

_validation-persist.example.com IN TXT "authority.example; accounturi=https://authority.example/acct/123; persistUntil=1782424856"

CA がこのレコードの確認結果を有効とみなせるのは、1 回の確認につき最長 10 日です。ただし、CA は自らレコードを再確認するため、更新のたびに誰かが DNS を操作する必要はありません。この方式を前提にする前に、CA が対応しているかどうかを問い合わせてください。

3. CA の指示に従う更新：早めに更新し、タイミングの判断は CA に任せます。

• 有効期間の約 3 分の 2 の時点で更新します。有効期間 45 日の証明書なら 30 日目です。Let's Encrypt は「60 日というハードコードされた間隔で更新するだけでは、もはや十分ではなくなる」と述べています。certbot はバージョン 4.0 以降、残り 30 日という固定の基準ではなく、有効期間の 3 分の 1 が残った時点で更新します。
• ARI を使います（RFC 9773、詳しくは次のセクションで説明します）。CA が各クライアントに更新時期を伝え、証明書を一括で失効させる必要がある場合には、その更新ウィンドウを前倒しできます。
• CA のデフォルトが変わる前に有効期間 45 日の証明書を使いたい場合は、プロファイルを明示的にリクエストします。

4. すべてのコピーへのデプロイ：ディスク上のファイルを更新すれば終わりではありません。証明書のコピー先をすべて洗い出してください。

• 証明書をアップロードして使うロードバランサーや CDN
• Kubernetes のシークレット
• Java のキーストアと PKCS#12 バンドル
• アプライアンス、メールサーバー、データベース、メッセージブローカー
• リーフ証明書をピンニングしているモバイルアプリ

どのコピー先にも、リロード用のフックか、新しい証明書を取得する連携の仕組みが必要です。この頻度では、アプリでリーフ証明書やその鍵をピンニングする運用は成り立ちません。代わりに CA の鍵をピンニングするか、できればピンニング自体をやめてください。

次のテストでは、tlsserver プロファイルで有効期間 45 日の証明書を発行するローカルの Pebble 2.10.1 ACME サーバーに対して、certbot 5.8.0 を実行しています。プロファイルのリクエストと更新の設定が、ドキュメントどおりに動作することがわかります。

$ certbot certonly --standalone --non-interactive --agree-tos --register-unsafely-without-email \
    --server https://localhost:14000/dir -d app.example.test --preferred-profile tlsserver
Account registered.
Requesting a certificate for app.example.test
Successfully received certificate.
This certificate expires on 2026-12-04.
$ openssl x509 -in /etc/letsencrypt/live/app.example.test/cert.pem -noout -startdate -enddate
notBefore=Oct 20 11:47:52 2026 GMT
notAfter=Dec  4 11:47:51 2026 GMT
$ grep -E "preferred_profile|server" /etc/letsencrypt/renewal/app.example.test.conf
preferred_profile = tlsserver
server = https://localhost:14000/dir
$ certbot renew --non-interactive
Processing /etc/letsencrypt/renewal/app.example.test.conf
Certificate not yet due for renewal

certbot はプロファイルを更新設定に保存するため、以降の更新でも毎回同じプロファイルをリクエストします。--preferred-profile フラグは certbot 4.0 から使えます。指定したプロファイルが CA のディレクトリに載っていない場合は、CA のデフォルトにフォールバックします。--required-profile を指定すると、フォールバックせずに発行や更新が失敗します。プロファイルは draft-ietf-acme-profiles で定義されており、このドラフトは 2026年10月時点で IESG のレビュー待ちでした。certbot 以外のクライアントでは、フラグ名が異なります。

ACME Renewal Information（ARI）

ARI（RFC 9773、2025年6月）によって、更新のタイミングはクライアント側の推測ではなく、CA への問い合わせで決まるものになります。クライアントは証明書ごとに、その証明書の Authority Key Identifier（機関鍵識別子）とシリアル番号から識別子を組み立てます。

url = renewalInfo || '/' || base64url(AKI keyIdentifier) || '.' || base64url(Serial)

次に、その URL を認証なしでポーリングします。レスポンスには suggestedWindow が含まれ、Retry-After ヘッダーが次に問い合わせるべき時期を示します。Let's Encrypt の証明書であれば、どれについても自分で問い合わせられます。

#!/bin/bash
set -e
host="$1"
openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null | openssl x509 -out cert.pem
aki=$(openssl x509 -in cert.pem -noout -ext authorityKeyIdentifier | grep -o -E '([0-9A-F]{2}:){19}[0-9A-F]{2}' | tr -d ':')
serial=$(openssl x509 -in cert.pem -noout -serial | cut -d= -f2)
# The DER INTEGER content keeps a leading 00 byte when the high bit is set.
[ $(( 16#${serial:0:1} )) -ge 8 ] && serial="00$serial"
b64url() { python3 -c 'import sys,base64; print(base64.urlsafe_b64encode(bytes.fromhex(sys.stdin.read().strip())).decode().rstrip("="))'; }
id="$(printf %s "$aki" | b64url).$(printf %s "$serial" | b64url)"
ari=$(curl -s https://acme-v02.api.letsencrypt.org/directory | grep -o '"renewalInfo": *"[^"]*"' | cut -d'"' -f4)
openssl x509 -in cert.pem -noout -issuer -startdate -enddate
echo "GET $ari/$id"
curl -s -D - "$ari/$id" | grep -i -E '^retry-after|^\{|"'

issuer=C=US, O=Let's Encrypt, CN=YE2
notBefore=Sep  4 14:34:32 2026 GMT
notAfter=Dec  3 14:34:31 2026 GMT
GET https://acme-v02.api.letsencrypt.org/acme/renewal-info/uVnyjs8i8IbTN0j_dhQYuoLYVYc.BUOTO-OGs6KzrdU08hA7yLZf
retry-after: 25769
{
  "suggestedWindow": {
    "start": "2026-11-02T17:18:36Z",
    "end": "2026-11-04T12:29:25Z"

この有効期間 90 日の証明書では、ウィンドウは発行の 59 日後、つまり有効期間の約 3 分の 2 の時点で始まります。クライアントはウィンドウ内のランダムな時点を選ぶべきであり、これにより更新が時間的に分散されます。CA が証明書を一括で失効させなければならない場合は、ウィンドウを過去に移動させます。すると、仕様どおりに動作するクライアントは期限切れで失敗するのではなく、数時間以内に更新します。更新時、クライアントは新しいオーダーの replaces フィールドに古い証明書の識別子を入れて送信します。

主なクライアントの ARI 対応状況を、各クライアントのリリースノートからまとめました。

更新の失敗を検知する監視

自動化は気づかないうちに失敗します。DNS API のトークンの期限切れ、80 番ポートを塞ぐファイアウォールの変更、動かなくなったリロード用フックなどです。有効期間 47 日の証明書を 30 日目に更新する場合、最初の更新失敗から障害が起きるまでの猶予は約 17 日です。この猶予期間の早い段階でアラートを出してください。

外部からの監視：覚えているドメイン名だけでなく、公開しているすべてのドメイン名をプローブしてください。Prometheus の blackbox exporter は、提供中のチェーンの有効期限を probe_ssl_earliest_cert_expiry として出力します。

probe_ssl_earliest_cert_expiry 1.795737599e+09
probe_success 1
probe_tls_version_info{version="TLS 1.3"} 1

次の 2 つのアラートルールは promtool check rules（Prometheus 3.5.0）のチェックを通過します。1 つ目は更新が遅れているとき、2 つ目は障害が迫っているときに発火します。

groups:
  - name: certificates
    rules:
      - alert: CertificateRenewalOverdue
        # Fires when less than a third of a 47-day lifetime (about 16 days) is left:
        # the renewal job should have replaced the certificate by now.
        expr: probe_ssl_earliest_cert_expiry - time() < 16 * 86400
        for: 1h
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }}: certificate expires in {{ $value | humanizeDuration }}"
      - alert: CertificateExpiresSoon
        expr: probe_ssl_earliest_cert_expiry - time() < 7 * 86400
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }}: certificate expires in {{ $value | humanizeDuration }}"

スクリプトによる監視：openssl x509 -checkend N は、証明書が N 秒以内に期限切れになる場合に終了ステータス 1 で終了します。cron ジョブや CI のステップにはこれで十分です。

$ openssl x509 -in cert.pem -noout -enddate
notAfter=Nov 26 23:59:59 2026 GMT
$ openssl x509 -in cert.pem -noout -checkend $((30 * 86400)); echo "exit status: $?"
Certificate will not expire
exit status: 0
$ openssl x509 -in cert.pem -noout -checkend $((45 * 86400)); echo "exit status: $?"
Certificate will expire
exit status: 1

このページの冒頭にある調査結果の表は、次のスクリプトで作成しました。

#!/bin/bash
for host in "$@"; do
  openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null | openssl x509 -out /tmp/c.pem 2>/dev/null || { echo "$host: no certificate"; continue; }
  nb=$(openssl x509 -in /tmp/c.pem -noout -startdate | cut -d= -f2)
  na=$(openssl x509 -in /tmp/c.pem -noout -enddate | cut -d= -f2)
  issuer=$(openssl x509 -in /tmp/c.pem -noout -issuer -nameopt multiline | grep -E "organizationName" | head -1 | cut -d= -f2 | sed 's/^ *//')
  days=$(( ($(date -d "$na" +%s) - $(date -d "$nb" +%s) + 1) / 86400 ))
  printf '%-22s %-26s %s  ->  %s  (%s days)\n' "$host" "$issuer" "$(date -u -d "$nb" +%F)" "$(date -u -d "$na" +%F)" "$days"
done

CA 側からの監視：Certificate Transparency のログには、自分のドメインに対して発行されたすべての証明書が記録されます。CT モニターを使うと、実際に行われた更新や、想定外の証明書を確認できます。詳しくは開発者のための Certificate Transparency を参照するか、CT 履歴ツールでドメインの履歴を調べてください。複数のドメインの準備状況を確認したい場合は、証明書の有効期間計算ツールで、手持ちの証明書ごとにスケジュールを当てはめて確認できます。

CAA とアカウントバインディング

検証の再利用期間が短くなると検証の回数が増え、そのたびに CAA レコードが確認されます。2027年3月15日以降（投票 SC-098）、CA は RFC 8657 の accounturi パラメーターと validationmethods パラメーターにも従わなければなりません。これにより、証明書の発行を自分の ACME アカウントと、選んだチャレンジの種類に限定できます。

example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789; validationmethods=dns-01"

CAA レコード生成ツールで、こうしたレコードを作成できます。古いままの CAA レコードは自分自身の更新をブロックしてしまう点に注意してください。しかも更新は、年 1 回ではなく、少なくとも年 8 回行われるようになります。

よくある間違い

• 固定の更新間隔：「60 日ごとに更新」では、有効期間 45 日の証明書にはすでに対応できません。有効期間に対する割合に基づいて、または ARI に従って更新してください。
• リロードなしの更新：新しいファイルはディスク上にあるのに、サーバーは期限切れになるまでメモリ上の古い証明書を提供し続けます。更新だけでなく、デプロイフックもテストしてください。
• コピーの更新漏れ：オリジンは自動で更新されても、CDN やロードバランサーには手動でアップロードした証明書が残っています。
• 残り 7 日でのアラート：有効期間 47 日の証明書では、期限切れの 1 週間前のアラートでは、DNS API やファイアウォールの問題をデバッグする時間が残りません。更新が遅れた時点でアラートを出してください。
• リーフ証明書の鍵のピンニング：モバイルアプリや API クライアントでこれを行うと、新しい鍵で更新するたびに動作しなくなります。
• プライベート PKI も従う必要があるという思い込み：内部 CA は独自のポリシーを維持できます。そこでも有効期間を短くするのは良い考えですが、採用するかどうかは自分で決められます。

出典

• CA/Browser Forum、ベースライン要件 v2.3.1：§1.2.2（関連する日付）、§3.2.2.4.21〜22（新しい DNS 方式）、§4.2.1（再利用期間）、§6.3.2（有効期間）
• 投票 SC-081v3（2025年4月11日採択、2025年5月16日発効）
• RFC 9773：ACME Renewal Information、RFC 8555：ACME、draft-ietf-acme-profiles
• Let's Encrypt、証明書の有効期間を 45 日に短縮、プロファイル
• certbot、Caddy、lego、acme.sh、cert-manager のリリースノート
• RFC 8659（CAA）と RFC 8657（CAA の accounturi と validationmethods）

コマンドの出力は 2026年10月20日に、node:24.22.0-trixie（OpenSSL 3.5.7、curl 8.14.1）、ghcr.io/letsencrypt/pebble:2.10.1 と組み合わせた certbot/certbot:v5.8.0、quay.io/prometheus/blackbox-exporter:v0.25.0、prom/prometheus:v3.5.0 で取得しました。