TLS証明書の有効期間は47日へ。ACMEによる自動更新と証明書の棚卸しで期限切れ障害を防ぐ

Webサイトの証明書が切れて、ブラウザに警告画面が出ます。年に1回の更新作業を担当者が覚えていて、手順書どおりに差し替えれば防げていた障害です。この前提が2026年から段階的に崩れます。CA/Browser ForumがBallot SC-081v3を採択し、公開TLS証明書の最大有効期間は2029年3月15日以降47日まで短くなります。本記事では、変更の日程を一次情報で確認したうえで、手動更新が回らなくなる理由、証明書の棚卸しの進め方、ACMEによる自動更新の設計、ACMEに対応しない機器の扱い、期限監視と切り戻し、CTログによる発行監視を順に整理します。

公開TLS証明書の有効期間は2029年に47日まで段階的に短くなる#

CA/Browser Forumは、ブラウザ事業者と認証局(CA)が参加し、公的に信頼されるTLSサーバ証明書の発行基準であるBaseline Requirements(ベースライン要件)を定める団体です。Ballot SC-081v3は2025年4月4日から11日まで投票にかけられ、認証局側は30票中25票の賛成、ブラウザなどの証明書利用者側は4票すべての賛成で採択されました。この投票でベースライン要件の4.2.1節(検証データの再利用)と6.3.2節(証明書の有効期間)が改められ、次の日程が決まりました。

OV証明書やEV証明書に記載する組織情報の検証結果の再利用期間も、2026年3月15日から825日が398日へ短くなりました。日程は発行日で判定されるため、2026年3月14日までに発行された398日の証明書は、その有効期限まで使えます。本記事の執筆時点で、2026年3月15日からの200日上限はすでに適用されています。

ドメイン検証の再利用期間とは、認証局が一度確かめた「申請者がそのドメインを管理している」という結果を、次の発行に使い回せる期間です。2029年以降はこれが10日になるため、47日ごとの更新でも、ほぼ毎回ドメインの管理権を確かめ直すことになります。

採択の経緯と改正対象の節はCA/Browser Forumの投票ページ(CA/Browser Forum)を、日付ごとの上限は同フォーラムが公開するベースライン要件の本文と、DigiCertの解説(DigiCert)で照合しました。

この変更の対象は、ブラウザやOSに組み込まれたルート証明書につながる公開TLSサーバ証明書です。社内CAが発行し、社内端末にだけ信頼を配った証明書はベースライン要件の対象外です。電子メールの署名や暗号化に使うS/MIME証明書も、別の要件で扱われます。ただし、メールサーバがSMTPやIMAPの通信に公開CAのTLS証明書を使っている場合は、Webサーバと同じく今回の短縮の対象です。

手動更新が回らなくなる理由#

有効期間が398日の頃、証明書の更新は年に1回の作業でした。47日になると、単純計算でも1枚あたり年に8回前後の更新が必要になります。実際には期限の数週間前に差し替えるため、回数はさらに増えます。証明書が20枚ある組織なら、年に20回だった作業が160回を超える計算です。

回数だけではありません。手動更新は、CSR(署名要求)の作成、ドメイン検証への対応、発行された証明書と中間証明書の取得、サーバへの配置、サービスの再読み込み、表示確認という手順の連なりです。どこか一つを忘れると障害になります。よくある失敗は、証明書は更新したのにサービスを再読み込みしておらず古い証明書が配信され続ける、中間証明書を入れ忘れて一部の端末だけ接続に失敗する、ロードバランサの側だけ差し替えを忘れる、といったものです。回数が8倍になれば、この種の取りこぼしが起きる機会も8倍になります。

担当者の交代も影響します。年に1回の作業は手順が属人化しやすく、担当者が異動すると誰も手順を知らない状態になります。47日周期では、属人的な手順のまま回し続けること自体が難しくなります。短縮を「作業が増える」と捉えるより、「人が覚えておく前提をやめる」きっかけと捉えるほうが、対策の方向を誤りません。

最初に証明書を棚卸しする#

自動化の前に、どこにどの証明書があるかを把握します。期限切れ障害の多くは、存在を忘れていた証明書で起きます。公開Webサーバの証明書は気づきやすい一方、ロードバランサやCDN、ネットワーク機器の管理画面に入れた証明書は、導入時の担当者しか知らないことがよくあります。

棚卸しでは、置き場所ごとに更新方法が違う点を意識して分類します。

一覧には、証明書ごとにドメイン名(SAN)、発行元、有効期限、配置先、更新方法、担当者を記録します。調べ方は、社内の構成管理台帳だけに頼らず、実際に外から見える証明書と突き合わせるのが確実です。後述するCTログを検索すると、自社ドメイン向けに発行された公開証明書の一覧が得られるため、台帳の漏れを見つける手がかりになります。

ACMEで更新を自動化する設計#

ACME(Automatic Certificate Management Environment)は、証明書の申請、ドメイン検証、発行、更新を機械的なやり取りで行うためのプロトコルで、2019年にRFC 8555として標準化されました。Let's Encryptが採用していることで広く知られていますが、商用CAの多くもACMEでの発行に対応しています。商用CAでは、ACMEのアカウントを契約中の顧客アカウントに結び付けるExternal Account Binding(EAB)を使うのが一般的です。

ドメイン検証の方式(チャレンジ)は、構成に合わせて選びます。HTTP-01はWebサーバの決まったパスに応答ファイルを置く方式で、公開Webサーバでは最も手軽です。DNS-01はDNSにTXTレコードを書き込む方式で、外部から直接届かないサーバや、ワイルドカード証明書に使えます。ただし対象は公開DNSで管理権を示せるドメイン名に限られます。社内だけで通用する名前(内部名)には、ベースライン要件により公開CAの証明書は発行されません。DNS-01を自動化する場合は、DNSのAPIキーをACMEクライアントに持たせることになるため、そのキーで操作できる範囲を対象のゾーンやレコードに絞ります。

更新の時期は、固定の日付ではなく残り期間で決めます。Let's Encryptは、有効期間の3分の2ほどが過ぎた時点での更新を許容できる挙動として挙げています。さらに2025年にRFC 9773として標準化されたACME Renewal Information(ARI)を使うと、CAが証明書ごとに推奨する更新時期をクライアントが問い合わせられます。CAが誤発行などを理由に証明書を早めに失効させる必要が生じたとき、ARIに対応したクライアントなら推奨時期の前倒しを受けて自動で更新できます。ACMEクライアントを選ぶ際は、ARIへの対応も確かめておくとよいでしょう。

CA側の変更の例として、Let's Encryptは2026年5月13日から、オプトインで使うtlsserverプロファイルで45日の証明書を発行しています。既定のclassicプロファイルは、2027年2月10日に64日の証明書と10日の認可再利用期間へ、2028年2月16日に45日の証明書と7時間の認可再利用期間へ移る予定を公表しています。業界ルールの47日を待たずに、利用するCA側で短縮が先に進む場合がある点も、自動化を急ぐ理由になります。

DNSのAPIキーやACMEアカウントの認証情報のように、自動化のために機械へ持たせる秘密情報の管理は、別の記事で扱っています。

あわせて読みたい

シークレット管理の実務。APIキー・認証情報をハードコードせず、Vaultやマネージドサービスで守りローテーションする

ACMEに対応しない機器の扱い#

アプライアンスの管理画面や古い業務システムには、ACMEに対応せず、証明書を画面から手で登録するしかない製品があります。この種の機器は、次の順で扱いを検討します。

1. 製品側の対応を確かめる: 新しいファームウェアでACMEクライアントが組み込まれている場合や、証明書を登録するAPIが用意されている場合があります。APIがあれば、外部のACMEクライアントで取得した証明書をスクリプトで流し込めます。
2. TLSの終端を前に出す: 利用者から見える接続を、ACMEに対応したリバースプロキシやロードバランサで受け、機器本体はその背後に置きます。公開証明書の更新はプロキシ側だけで完結します。
3. 公開証明書が要らない用途を切り分ける: 社内の管理者だけが使う管理画面なら、社内CAの証明書で足りる場合があります。社内CAはベースライン要件の短縮の対象外ですが、社内端末への信頼の配布と、社内CA自体の期限管理が別途必要になります。
4. 残るものは台帳で管理する: どうしても手動が残る機器は、更新手順を文書にし、期限の監視対象に必ず加えます。更新が年に8回以上になることを前提に、製品の置き換え計画にも載せておきます。

47日周期で手作業を続ける機器が多いほど、運用負荷と障害の機会は増えます。2027年3月の100日上限の時点で、手動の機器が何台残っているかを確かめ、2029年3月までに減らす計画を立てるのが現実的です。

期限監視と障害時の切り戻し#

自動更新を入れても、監視は外せません。ACMEクライアントの設定ミス、DNSのAPIキーの失効、ファイアウォールの変更によるHTTP-01の到達不能など、自動更新が黙って止まる原因はいくつもあります。CAからの期限通知メールに頼る運用も成り立たなくなっています。Let's Encryptは2025年6月4日に有効期限の通知メールの提供を終えました。

監視は、サーバ上の証明書ファイルではなく、利用者に実際に配信されている証明書を外から確かめる形にします。ファイルは更新されていても、サービスの再読み込みが漏れていれば古い証明書が配信され続けるからです。確認の例として、opensslで配信中の証明書の有効期限を取得できます。

# 配信中の証明書の有効期限を表示する(example.com は自社のドメインに置き換える)
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -enddate

警告の閾値は有効期間に合わせて見直します。398日の証明書で使っていた「残り30日で通知」は、47日の証明書では発行直後から17日後に鳴る計算になり、正常な更新待ちと区別できません。有効期間の3分の2で更新する運用なら、更新予定を過ぎても差し替わっていない状態、たとえば残り期間が3分の1を切った時点を異常として通知するほうが、実際の失敗を拾えます。

切り戻しは2つの場面に分けて準備します。1つめは、新しい証明書の配備で障害が起きた場合です。中間証明書の不足や鍵の取り違えで接続に失敗したら、直前まで使っていた証明書に戻します。有効期間の3分の2で更新していれば、直前の証明書にはまだ期間が残っています。失効しておらず秘密鍵の漏えいも疑われないことを確かめたうえで、一時的な戻し先として使えます。そのために、直前の証明書と秘密鍵を安全な場所に保管しておきます。

2つめは、CAが証明書を失効させた場合です。ベースライン要件は、有効期間がごく短い一部の証明書を除き、秘密鍵の漏えいや誤発行などの理由に応じて、CAに24時間または5日以内の失効を求めています。この場合は直前の証明書も同じ理由で失効していることがあり、戻し先になりません。失効の理由を確かめたうえで再発行します。理由が秘密鍵の漏えいであれば、新しい鍵を作ってから再発行します。ACMEで自動化していれば、再発行は通常の更新と同じ手順で進められます。発行元のCAそのものに障害が起きた場合に備えて、別のCAのACMEエンドポイントを予備として設定し、平時に発行を試しておく方法もあります。

CTログで自社ドメインへの証明書発行を監視する#

Certificate Transparency(CT)は、公開CAが発行した証明書を、誰でも検索できる追記専用のログに記録させる仕組みで、RFC 6962で定められています。後継のバージョン2.0はRFC 9162として公開されています。主要なブラウザはCTログへの記録を前提にしており、公開証明書の多くはCTログから確認できます。

CTログは2つの用途に使えます。1つは、前述の棚卸しの補助です。crt.shなどの検索サービスで自社ドメインを検索すると、過去に発行された公開証明書が並び、台帳に載っていない証明書やサブドメインが見つかります。検索結果には、CAが発行前にログへ登録する事前証明書(プレ証明書)も含まれるため、同じ内容の証明書が2件並ぶことがあります。もう1つは、見覚えのない発行の検知です。自社が依頼していないCAから証明書が発行されていれば、ドメインの乗っ取りやDNSの設定を悪用された可能性を疑う手がかりになります。

有効期間が短くなると、CTログに現れる自社ドメインの証明書の件数も増えます。すべてを目で追うのは難しいため、発行を通知する監視サービスやスクリプトを使い、発行元が想定したCAか、対象のドメイン名が台帳に載っているかで自動的にふるい分けます。あわせてDNSにCAAレコードを設定し、自社のドメインに証明書を発行してよいCAを限定しておくと、想定外の発行そのものを減らせます。

移行に向けた確認項目#

2027年3月15日の100日上限までに自動化の土台を作り、2029年3月15日の47日上限までに手動の更新を例外に減らす、という2段階で計画すると進めやすくなります。

有効期間の短縮は、証明書の運用を「期限を覚えておく作業」から「自動で回る仕組みの保守」へ移す変更です。更新の回数が増えるほど、手作業が残る箇所に障害が集まります。棚卸しで全体を見える状態にし、自動化できるものから順に人の手を外していくことが、期限切れ障害を防ぐ近道になります。

証明書とHTTPSが何を守り、ブラウザがどのように証明書を検証しているかは、別の記事で基礎から説明しています。

あわせて読みたい

HTTPSと電子証明書が守る範囲と、鍵マークが示さないこと