InfraAcademy Blog

証明書の更新をカレンダーで管理する時代が、そろそろ終わります。2026年に始まった有効期間200日ルールと自動化への移行

公開日: 2026-09-21 更新日: 2026-09-21 | #インフラ運用 #TLS #サーバー証明書

Linuxをブラウザで試してみる

Linux・ネットワーク・AWSを、環境構築なしで実践学習できます

こんにちは、インフラエンジニアのryuです。

サーバー証明書の有効期限を、チームの共有カレンダーに登録している現場は多いと思います。1年に1度、担当者が思い出して更新する。長いあいだ、それで回ってきました。

ところが2026年、その前提が静かに崩れました。

2026年3月15日以降に発行されるサーバー証明書の有効期間が、最長200日に短縮されたのです。これまでの398日から、ほぼ半分になりました。そしてこれは終着点ではなく、途中経過にすぎません。

今日は、この変更がどういうものなのか、現場の運用に何が起きるのかを整理してみます。

何が決まったのか¶

決めたのは、認証局とブラウザベンダーが集まって基準を作っている CA/Browser Forum という団体です。2025年4月、SC-081v3 という議案が可決されました。賛成25、反対0という結果でした。

内容は、証明書の有効期間を4年かけて段階的に縮めていく、というものです。

発行日	有効期間の上限	これまでとの比較
2026年3月14日まで	398日	従来どおり
2026年3月15日以降	200日	およそ半分
2027年3月15日以降	100日	年3〜4回の更新
2029年3月15日以降	47日	年8回前後の更新

47日という数字は、少し不思議に見えるかもしれません。これは「1か月（最大31日）＋予備の2週間＋数日」という考え方から来ています。月次の運用サイクルを守りつつ、更新に失敗しても立て直す余裕を残した長さ、というわけです。

対象は、これから発行する証明書です¶

ここは誤解が生まれやすいところです。

ルールが適用されるのは、その日以降に新しく発行される証明書です。すでに手元にある証明書が、ある日突然短くなるわけではありません。

つまり、2026年3月14日に398日の証明書を取得していれば、それは2027年4月ごろまで有効なまま使えます。移行は、次の更新のタイミングで順番にやってくるという形になります。

逆に言えば、この記事を読んでいる時点でまだ影響を感じていない現場でも、次の更新日を境に確実に切り替わるということです。

ドメイン検証の使い回しも短くなります¶

証明書の有効期間と並んで、もうひとつ地味に効いてくる変更があります。ドメイン検証（DCV）の結果を使い回せる期間です。

証明書を発行するとき、認証局は「あなたがそのドメインの持ち主であること」を確認します。この確認結果は一定期間キャッシュされ、次の発行時に再利用できました。その再利用期間も、証明書の有効期間と同じスケジュールで短くなっていきます。

サブジェクト代替名（SAN）の検証データについては、最終的に10日まで縮む予定です。ここまで来ると、事実上、発行のたびに検証をやり直すことになります。

証明書そのものだけでなく、その裏側にある「持ち主であることの証明」も短命になっていく。

証明書の仕組みそのものを整理し直したい方は、サーバー証明書の仕組みを解説した記事を先に読んでおくと、この話が立体的に見えてくると思います。

なぜ、わざわざ短くするのでしょうか¶

更新の手間が増えるのに、なぜこんな決定がされたのか。理由は大きく2つあります。

ひとつは、失効の仕組みが当てにならないからです。

秘密鍵が漏れたとき、認証局は証明書を失効させます。ですが、失効情報がブラウザに行き渡るまでには時間差がありますし、そもそも失効チェックを厳密に行わないクライアントも存在します。つまり、失効させたはずの証明書が、現実にはしばらく通用してしまう。

この「危険な期間」の上限を決めているのが、証明書の有効期間です。有効期間が短ければ、失効が効かなくても、証明書は勝手に期限切れになります。失効という不確実な仕組みに頼らず、時間で強制的に無効化してしまおう、という発想です。

もうひとつは、ドメインの持ち主が変わることです。

ドメインは売買されますし、解約もされます。1年以上前に「この人が持ち主だ」と確認した結果を信じ続けるのは、そもそも無理があります。検証の使い回し期間が縮むのは、こちらの理由が大きいところです。

社内と社外の境界を信用しない考え方が広がってきた流れとも、根っこはつながっています。ゼロトラストの考え方を整理した記事と合わせて読むと、業界全体が「一度確認したことを信じ続けない」方向へ動いているのが見えてきます。

現場の運用は、どう変わるのか¶

いちばん大きな変化は、人が更新作業を担当できなくなることです。

年1回なら、担当者が手で更新できました。年8回になると、話が変わります。更新のたびに手順書を開き、CSRを作り、認証局の画面で申請し、ファイルを配置して、サービスを再起動する。これを8回繰り返すのは、現実的ではありません。

更新の頻度	手作業の現実味	失敗したときの影響
年1回（398日）	なんとか回る	気づけば半日で復旧
年2回（200日）	忘れる人が出始める	属人化が進む
年3〜4回（100日）	担当者の負担が常態化	更新漏れが定期的に起きる
年8回前後（47日）	事実上むり	サービス停止が日常のリスクに

証明書の期限切れによる障害は、決して珍しいものではありません。2020年2月にMicrosoft Teamsが数時間つながらなくなったのも、認証に使う証明書の更新漏れが原因でした。大きな会社でも、人が覚えている限りは起こります。

ちなみに、期限切れの証明書に出会ったときにクライアント側で何が起きるかは、curlのSSL証明書エラーを扱った記事が具体的でわかりやすいです。エラーメッセージから状況を読む練習にもなります。

自動化の道具は、もうそろっています¶

ではどうするか。答えははっきりしていて、ACME による自動更新に移行することです。

ACME は、証明書の申請・検証・発行を機械同士でやりとりするためのプロトコルです。Let's Encrypt が広めたものですが、いまでは商用の認証局も対応しています。

certbot と systemd timer で回す形¶

もっとも素直な構成は、certbot のようなACMEクライアントを入れて、定期実行に任せる形です。

# 更新できるものだけ更新する（期限が近くないものは何もしない）
sudo certbot renew

# 実行内容を確認したいときは、まずドライランで
sudo certbot renew --dry-run

# 自動実行のタイマーが動いているかを確認する
systemctl list-timers | grep certbot

certbot renew は、期限が近い証明書だけを対象にします。1日2回まわしても問題はなく、むしろ推奨されている使い方です。

いつ更新すべきかを、認証局が教えてくれる仕組み¶

2025年には、ACME に ARI（ACME Renewal Information）という拡張が追加され、RFC 9773 として標準化されました。

これは、認証局側が「この証明書は、この時間帯に更新してください」とクライアントに伝える仕組みです。更新が特定の時刻に集中して認証局が詰まるのを防げますし、認証局側で証明書をまとめて失効させる必要が生じたときに、更新を前倒しするよう指示できます。

Let's Encrypt が2020年に300万枚の証明書を失効させた際、利用者へ更新を促す手段がなかった経験から生まれた仕組みだと説明されています。

そして2026年1月、Let's Encrypt は有効期間160時間、つまり約6日の証明書と、IPアドレス向けの証明書を正式提供に切り替えました。こちらはオプトインで、既定にする予定はないとされています。とはいえ、6日の証明書が現実に使われ始めているという事実は、業界がどこへ向かっているかをよく表しています。

落ちるのは「取得」ではなく「反映」です¶

自動更新を入れた現場で実際に起きる事故は、証明書が取得できないことではありません。取得はできているのに、サービスに読み込まれないまま古い証明書が配られ続けるパターンです。

ファイルは新しくなっているのに、NginxもApacheもメモリ上に古い証明書を持ったままなので、誰も異変に気づきません。そして期限の日に、いきなり落ちます。

# 更新に成功したときだけ再読み込みを走らせる
sudo certbot renew --deploy-hook "systemctl reload nginx"

# 実際に配信されている証明書の期限を外から確認する
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates

大事なのは、下のコマンドのようにサーバーの外側から確認することです。ファイルの中身ではなく、実際に配信されている証明書を見る。ここを監視項目に入れておけば、反映漏れは必ず見つかります。

自動化しづらい証明書を、どう扱うか¶

ここまで読んで、「うちはそう簡単にいかない」と思われた方もいるはずです。実際、ACMEをそのまま適用できない場所は現場にいくつもあります。

代表的なのは、インターネットから到達できない閉域のサーバー、ネットワーク機器やアプライアンスに組み込まれた管理画面、そして証明書ファイルを手で入れるしかない古いミドルウェアです。

外から見えないサーバーは、検証の方法を変える¶

ACMEのドメイン検証は、ふつう外部からのアクセスで持ち主を確認します。閉域のサーバーは、この確認を受けられません。

その場合は、HTTPによる検証ではなくDNSによる検証に切り替えます。DNSのTXTレコードを一時的に置いて確認してもらう方式なので、サーバー自体が外部から見えなくても成立します。DNSの権威サーバーをAPIで操作できる環境なら、ここも自動化できます。名前解決の仕組みそのものに不安があるなら、DNSの基本を扱った記事で先に整理しておくと理解が早くなります。

もうひとつの選択肢が、社内に内部認証局を置く方法です。社内向けのサーバーであれば、公的な認証局の証明書を使う必然性はありません。内部CAならルールの適用外なので、有効期間も自分たちで決められます。

マネージドサービスに寄せるのも、立派な対策です¶

自前で更新の仕組みを作らず、クラウド側に任せてしまう手もあります。

たとえばAWSのCertificate Managerで発行した証明書は、ロードバランサーやCloudFrontに紐づけておけば自動で更新されます。証明書の期限を意識する必要が、そもそもなくなります。取得の流れはAWSで無料のサーバー証明書を取得する方法の記事にまとまっているので、まだ触ったことがなければ一度試してみる価値があります。

どうしても手作業が残る箇所については、無理に自動化せず、代わりに「必ず気づける仕組み」を用意します。外部から期限を監視して、残り日数が一定を切ったら通知する。台数が少ないなら、この割り切りで十分に回ります。

大事なのは、自動化できるものとできないものを混ぜたまま放置しないことです。全部を同じ運用で扱おうとすると、いちばん手間のかかるものに全体が引きずられます。

明日からできる棚卸し¶

いきなり全部を自動化しようとすると、たいてい止まります。まずは現状を把握するところからです。

やること	具体的に	目的
証明書の一覧を作る	ドメイン、認証局、期限、設置場所を書き出す	どこに何枚あるか把握する
ACME対応可否を分ける	外部公開か、閉域か、機器組み込みか	自動化できる順に並べる
反映の経路を確認する	更新後に何を再読み込みするか	反映漏れの事故を防ぐ
外部監視を入れる	期限を外側から定期チェックする	最後の砦を用意する

棚卸しの結果は、そのまま作業手順の見直しにつながります。手順をどう読み、どう整えるかについては、手順書との向き合い方をまとめた記事も参考にしてみてください。

こうした変化に落ち着いて対応するには、TLSやDNS、名前解決といったネットワークの土台を筋道立てて理解しておく必要があります。断片的な知識だと、新しいルールが出るたびに振り回されてしまうからです。InfraAcademy では、通信の仕組みを順番に積み上げていくネットワークの学習ロードマップを用意しています。証明書の話を「暗記」ではなく「納得」に変えたい方は、のぞいてみてください。