証明書の有効期間の短縮スケジュール早見表：200日・100日・47日とLet’s Encryptの64日

証明書の有効期間が短くなる、という話は聞いたことがあると思います。では、いつ、何日になるのか。自分が使っている Let’s Encrypt や ACM、有料の証明書は、いつから影響を受けるのか。答えられるでしょうか。

短縮は一度では終わりません。2026年から2029年にかけて、CA/Browser Forum の決まりと、各 CA の既定の変更が少しずつ、別々の日付で効いていきます。この記事は、その日付を1つの年表にまとめた早見表です。内容は、日程が近づいたら更新していきます（最終の確認日は「更新履歴」を参照）。

結論：短縮の年表
いま（2026年11月）の状態
2つの「日数」：有効期間と再利用期間
何枚あると、年に何回の作業になるか
立場ごとの影響
次の切り替えまでにやること
更新履歴
参考資料

結論：短縮の年表

公開証明書（ブラウザーが最初から信頼する公開CAの証明書）について、決まっている日付を並べました。左の列が CA/Browser Forum の Baseline Requirements（BR）で、すべての公開CAに効く決まりです。右の列は、各 CA・サービスの既定の変更です。

日付	すべての公開CA（BR）	Let’s Encrypt・ACM
2026年2月18日	―	ACM の公開証明書が198日に（期限の45日前に自動更新）
2026年3月15日	最長有効期間 398日 → 200日。ドメイン認証の再利用 200日、組織情報の再利用 398日。メール・電話によるドメイン認証は非推奨に。MPIC は3拠点	―
2026年6月15日	MPIC が4拠点に	―
2026年12月15日	MPIC が5拠点に	―
2027年2月10日	―	Let’s Encrypt の既定が90日 → 64日、認証の再利用 30日 → 10日
2027年3月15日	最長有効期間 100日、ドメイン認証の再利用 100日。電話によるドメイン認証を廃止。CAA の `accounturi`・`validationmethods` を CA が必ず処理	―
2027年3月31日	―	ACM がメール検証を新しい証明書の申請で提供しなくなる
2027年9月30日	―	ACM がメール検証の証明書を更新しなくなる
2028年2月16日	―	Let’s Encrypt の既定が 45日、認証の再利用 7時間
2028年3月15日	メールによるドメイン認証を廃止	―
2029年3月15日	最長有効期間 47日、ドメイン認証の再利用 10日	―

200日・100日・47日の段階は、Ballot SC-081v3（2025年4月11日に可決）で決まり、BR の6.3.2節（有効期間）と4.2.1節（再利用期間）に書かれています。仕組みと決まった経緯は第6回（有効期間と再利用期間の短縮）で解説しました。

いま（2026年11月）の状態

公開証明書の上限は200日。2026年3月15日以降に発行・更新した証明書は、200日を超えられない
Let’s Encrypt の既定（classic プロファイル）は、まだ90日・認証の再利用30日。45日（tlsserver）と約6日（shortlived）のプロファイルは、選べば今でも使える
ACM の公開証明書は198日で、期限の45日前に自動で更新される
MPIC は4拠点。12月15日から5拠点になる
AD CS・AWS Private CA・vCenter の VMCA など社内CAの証明書は、BR の対象外。有効期間は社内の規程で決める

200日になったことで、1年に1回だった有料の証明書の更新は、すでに年に2回になっています。

2つの「日数」：有効期間と再利用期間

短縮には、2つの日数があります。

有効期間：証明書そのものが使える期間。期限が来たら、新しい証明書に入れ替える
再利用期間：CA が「申請者がそのドメインを管理している」と確かめた結果（ドメイン認証）を、次の発行に使い回せる期間

2029年3月には、有効期間が47日なのに対して、ドメイン認証の再利用は10日になります。つまり、更新のたびに、ほぼ毎回ドメイン認証をやり直すことになります。DNS に TXT レコードを置く、Web サーバーにファイルを置く、といった確認を毎回手作業で行うのは現実的ではありません。ACME による自動化が前提になる、というのはこの意味です。

組織情報（OV・EV の会社名など）の再利用期間は398日のままです。毎回変わるのは、ドメインの確認のほうです。

何枚あると、年に何回の作業になるか

第8回（ライフサイクルと自動化）の表を再掲します。

最長有効期間	適用開始	1枚の年間の更新回数（目安）	100枚なら年間の作業
398日	2020年9月	約1回	約100回
200日	2026年3月15日	約2〜3回	約200〜300回
100日	2027年3月15日	約4〜6回	約400〜600回
47日	2029年3月15日	約8〜12回	約800〜1,200回

（回数の幅は、期限ぎりぎりで更新する場合と、余裕を持って残り1/3で更新する場合）

次の切り替え（2027年3月15日の100日）で、手作業の回数はもう一度倍になります。手作業の枚数を減らすなら、この前が区切りです。

立場ごとの影響

有料の公開CAの証明書を、手作業で更新している

いちばん影響が大きい立場です。今は年に2回、2027年3月15日からは年に4回前後、2029年3月15日からは毎月近くになります。

2026年3月から、メール・電話によるドメイン認証は非推奨。電話は2027年3月15日、メールは2028年3月15日に使えなくなる。DNS か Web サーバーで確かめる方法へ移す
複数年の契約でも、証明書は上限の日数ごとに発行し直す。契約の期間と証明書の期間は別

Let’s Encrypt を使っている

自動で更新していて、ACME クライアントが ARI（ACME Renewal Information、RFC 9773） に対応していれば、ほとんど何もしなくて済みます。Let’s Encrypt も、ARI に対応したクライアントなら準備はできている、としています。

注意が要るのは、更新の時期を固定の日数で書いている場合です。2027年2月10日以降は、新しく発行・更新した証明書が64日になります（45日・約6日のプロファイルを選んだものを除く）。

「期限の何日前に更新」「60日ごとに更新」のように日数を固定していると、64日の証明書では余裕がほとんど無いか、更新が間に合わない
Let’s Encrypt は、固定の日数をやめて有効期間の約2/3で更新するよう勧め、cron やスクリプト・手順書の中の 83・80・60 といった数字を探すよう呼びかけている
90日の証明書の最後のものは、2027年5月11日に期限を迎える見込み
認証の再利用が10日になる。再利用を前提に作った仕組みでなければ、変更は要らない

ACM（AWS Certificate Manager）を使っている

ACM が発行した公開証明書は、すでに198日で、期限の45日前に自動で更新されます。

DNS 検証の CNAME レコードを消さない。消すと自動更新ができない
メール検証で発行した証明書は、DNS 検証に移す。2027年3月31日から新しい申請でメール検証が使えなくなり、2027年9月30日からはメール検証の証明書が更新されなくなる
ACM にインポートした証明書は自動更新の対象外。期限は自分で管理する

社内CAの証明書を使っている

AD CS などの社内CAが発行した証明書は、BR の上限の対象外です。今の運用をすぐに変える必要はありません。

ただし、公開CAの証明書を社内のシステムに使っているなら、上の「有料の公開CA」と同じ影響を受ける。外に公開しない管理画面などは、社内CAの証明書に切り替えると、短縮の影響を受けなくなる（第11回の問3）
有効期間を何日にするかは、社内の規程で決める。長すぎると、鍵が漏れたときの影響が長く続く

次の切り替えまでにやること

2027年2月10日（Let’s Encrypt の64日）と2027年3月15日（100日）の前に、次の順で確かめておくと安心です。

棚卸し：自社のドメインの証明書を、CT のログ（crt.sh など）・スキャン・台帳で洗い出す。知らない証明書は自動化できない（第8回）
更新の方法を決める：ACME で自動化できるものは自動化する。自動化できない機器は、ロードバランサーで終端する・社内CAに切り替える・ACME 対応の製品に替えるのどれかを選ぶ（第8回・第9回）
更新の時期を固定していないか確かめる：cron・スクリプト・手順書の固定の日数を探し、ARI か有効期間の2/3に替える
ドメイン認証の方法を確かめる：メール・電話で確かめている証明書は、DNS か Web サーバーの方法へ移す（第6回）。ACM はメール検証から DNS 検証へ
CAA を確かめる：使っている CA が CAA に書かれているか。accounturi を書いているなら、アカウントが正しいか（第5回）
期限を監視する：「残り何日」だけでなく、「更新されるはずの時期を過ぎても古いまま」を警告する（第8回）