SSL証明書の有効期間が200日に短縮｜「来年まで大丈夫」が通用しなくなります

WebサイトやVPNなどで利用するSSL証明書について、「2029年には有効期間が47日になる」という話を目にした方もいるのではないでしょうか。正確には、ブラウザなどから一般に信頼されるTLSサーバー証明書（以前はSSL証明書と呼ばれていたもの。サイトのアドレスが https:// で始まるために必要な電子的な証明書です）の最大有効期間が、段階的に短縮されます。以降、本記事では「TLSサーバー証明書」に表記を統一します。

そして重要なのは、47日化はまだ先でも、2026年3月15日から最大200日への短縮はすでに始まっていることです。3月中旬以降に発行・更新した証明書は、従来なら約1年後だった期限が、最大でもおおむね6か月半後に来ます。つまり前回の更新から「1年後まで大丈夫」という感覚のままでいると、想定より早く期限日が来る会社があります。

情シス担当者にとっての本当の問題は、証明書の仕組みが変わることよりも、更新回数が増えて従来の運用が続けにくくなる点です。「毎年決まった月に担当者が更新する」という年次作業として管理していた環境では、2027年の100日化、さらに2029年の47日化を迎える前に運用を見直す必要があります。

そこで本記事では、有効期間の短縮を単なるセキュリティニュースではなく情シスの運用課題として考えます。いきなりすべてを自動化するのではなく、まずは「どこで証明書を使っているか」を把握し、更新方法を整理することから始めるのが現実的です。

※本記事は2026年8月時点の公表内容に基づいています。最新の状況は、ご利用の認証局（証明書を発行する会社）の案内でご確認ください。

TLSサーバー証明書の有効期間はすでに200日に短縮されている

この変更を決めているのは、CA/Browser Forum（証明書を発行する会社とブラウザを作る会社が集まって、共通ルールを決めている団体）です。一般に信頼されるTLSサーバー証明書の最大有効期間は、次のように段階的に短縮されます。2026年8月時点では、すでに最初の変更が適用されています。

つまり、「2029年になったら対策を考えればよい」という話ではありません。2026年3月15日以降に新規発行や更新を行った証明書から、すでに従来より短いサイクルへ移行しています。また、2027年3月15日まで約7か月しかない2026年8月時点では、次の100日化を前提に運用を確認しておく時期に入っています。

なお、このルールを社内で使うすべての証明書にそのまま当てはめる必要はありません。対象となるのは、一般に信頼されている認証局が発行する公開用の証明書です。社内で発行した証明書（社内向けの認証局によるもの）まで一律に200日になるわけではありません。一方、社内向けシステムであっても一般の認証局から購入した証明書を使っている場合は影響を受けます。自社のものがどちらか分からなければ、購入先やベンダーに確認してください。

今年の秋、前回より早く期限が来る会社があります

ここが、この変更でいちばん実務に効く部分です。2026年3月中旬以降に発行・更新した証明書は、従来なら約1年後だった期限が、最大でもおおむね6か月半後に来ます。3月中旬に更新した会社であれば、期限はおおむね今年の秋ごろです。

「前回更新したばかりだから、まだ先のはず」という感覚のままでいると、想定より早く期限日が来ることになります。実際に更新作業を業者へ依頼している場合でも、社内の予算処理や作業日程の調整が必要な会社では、期限の直前に気づくと慌てることになります。

確認方法は難しくありません。ブラウザでサイトを開き、アドレスバーのサイト情報から証明書の詳細を表示すれば、有効期限が確認できます。VPN機器や社内システムであれば、管理画面の証明書設定の欄に表示されています。まずは主要なものを数件、実際に開いてみてください。

なお、200日はあくまで上限です。認証局によっては余裕を見て199日で発行している場合もあります。日数から逆算して更新予定日を組む場合は、「おおむね」「前後」として数日の余裕を持たせてください。

なぜ有効期間が短くなるのか

背景には、証明書やドメインの状態が変化しても、古い情報を含んだ証明書が長期間使われ続けるリスクを小さくする、という考え方があります。証明書には、どのアドレス（ドメイン名）向けに発行されたものかといった情報が含まれています。有効期間が長いほど、その情報が実態とずれたまま使われる時間が長くなります。

何か攻撃を受けたから短くする、という話ではありません。ルールを決める側が、証明書の情報を確認し直す間隔を短くしていく方針を決めた、という理解で十分です。

情シスの立場では、暗号技術や認証局の細かな仕様まで理解することよりも、「証明書は長期間固定して使うものではなく、継続的に更新されるものへ変わる」と捉える方が実務につながります。実際、クラウドサービスの中には、人が操作しなくても期限前に証明書が入れ替わる仕組みを標準で備えているものがあります。

ただし、ここで注意したいのは「証明書が自動で更新できる」と「実際に利用中の機器へ新しい証明書が自動で入る」は必ずしも同じではないことです。認証局側で更新できても、Webサーバーやロードバランサー、VPN装置への設定変更が手作業なら、運用負荷は残ります。

したがって、確認すべき対象は証明書の購入先だけではありません。発行、更新、機器への設定、サービスの再読み込み、更新後の確認まで、一連の作業のどこに人手が残っているかを確認する必要があります。今後は「証明書を持っているか」だけでなく、更新の流れ全体を管理できているかが重要になります。

情シスにとって問題なのは「更新回数が増えること」

これまで最大398日の証明書であれば、実務上は「年に1回程度の更新作業」としてスケジュール管理していた企業も多いでしょう。例えば、毎年カレンダーへ更新予定日を登録し、期限の1か月前になると担当者が証明書を購入・発行し、WebサーバーやVPN機器へ手動で設定する、といった運用です。

しかし最大100日になると、単純計算では1年間に3〜4回程度の更新が発生します。さらに47日になれば、年1回という感覚では管理できません。証明書ごとに更新時期が異なる環境では、複数のシステムについて頻繁に期限を確認しなければならず、担当者の作業量だけでなく更新漏れのリスクも高まります。

私自身も、サーバーやシステムの証明書更新は「年に一度確認する作業」という感覚になりやすいものだと感じています。しかし100日まで短縮されると、年次作業という考え方そのものを変える必要があります。担当者の予定表や記憶に依存する方法では、担当変更や長期休暇が重なっただけでも更新を逃す可能性があります。

証明書が期限切れになると、Webブラウザに警告が表示されてサイトが開けなくなるだけでなく、システム間の連携やメールの送受信が止まる可能性もあります。したがって、有効期間短縮への対応は単なる作業効率化ではありません。サービス停止を防ぐための運用設計として考える必要があります。

まず「どこで証明書を使っているか」を棚卸しする

更新の自動化を検討する前に行いたいのが、証明書の棚卸しです。Webサイトの証明書は把握できていても、数年前に導入したネットワーク機器やアプライアンスの管理画面に設定された証明書までは一覧化されていない、という環境は珍しくありません。

例えば、次のような場所を確認します。

• 会社の公開Webサイト、採用サイト、問い合わせサイト
• 社内Webシステムやイントラネット
• VPN、UTM、ファイアウォールのSSL-VPN機能
• ロードバランサー、リバースプロキシ、WAF
• NASや各種サーバーの管理画面
• 複合機、監視カメラ、録画機、入退室管理機器
• ベンダーが管理するクラウドサービスやアプライアンス

ここでのポイントは、機器を見つけたらすべて「今回200日になる対象」と判断しないことです。例えば、複合機の管理画面が機器自身で作った証明書を使っていたり、社内で発行した証明書を設定していたりする場合、今回の短縮とは直接関係しません。その一方で、VPN装置に一般の認証局から購入した証明書を設定しているケースでは対象になります。

サーバーについては管理台帳に載っていても、VPN機器やアプライアンスなど「導入時に証明書を設定したまま」の場所は見落としやすいところです。また、ベンダーに運用を委託しているシステムでは、情シス側が証明書更新を意識していない場合もあります。そのため、棚卸しでは証明書の有無だけでなく、発行元と更新責任者までセットで確認すると、後の整理がしやすくなります。

棚卸し表には何を書けばよいか

証明書を見つけても、「○○サーバーで証明書を使用」とだけ記録していては、実際の更新時に再調査が必要になります。最低限、ホスト名、有効期限、発行元、更新方法、担当者、自動更新の可否まで一覧にしておくと、その後の運用改善につなげやすくなります。

特に「担当者」は個人名だけではなく、「情シス基盤担当」「Web運用チーム」など組織としての責任範囲も残しておくと、異動時の引き継ぎがしやすくなります。また、自動更新の可否が分からなければ無理にその場で調査せず、まず「要確認」として一覧化する方法でも構いません。

最初から完璧な台帳を作ろうとすると棚卸し自体が進まなくなるため、まず証明書の存在と期限を把握し、その後に更新方法やベンダーの仕様を埋めていく方が現実的です。小規模な環境であれば、ExcelやGoogleスプレッドシートから始めても十分です。

100日になる前に「手動更新」と「自動更新」を分ける

棚卸しができたら、次に証明書を「自動で更新できるもの」と「手作業が残るもの」に分けます。この切り分けをしておくと、2027年の100日化で運用負荷が増える場所を早めに特定できます。

クラウド上のサービスや、標準で自動更新の仕組みを持つ環境であれば、証明書の有効期間が短くなっても、人が毎回ファイルをダウンロードして入れ替える必要はありません。一方、古いVPN装置やUTM、アプライアンスでは、更新のたびに管理画面から証明書と鍵を手作業で読み込ませる必要がある場合があります。さらに再起動やサービスの再読み込みが必要であれば、夜間作業や利用部門との調整も発生します。年1回であれば許容できた作業でも、100日や47日のサイクルでは負担が大きくなります。

自動化できないからといって、すぐに機器を交換する必要はありません。ただし、証明書更新のたびに作業が発生する機器は、今後の保守コストが増える資産として把握しておくべきです。機器更改のタイミングでは、性能や価格だけでなく証明書の自動更新に対応しているかどうかも選定項目に加えると、将来の運用負荷を減らせます。

費用はどうなるのか、上司にはどう説明するか

読者の方からよくいただく質問が「更新回数が増えるなら、費用も3倍になるのか」というものです。ここは断定できません。認証局や販売事業者によっては、契約期間中に短い証明書を複数回発行する方式を採っている場合があります。ただし扱いは事業者ごとに異なるため、費用の考え方は購入先に確認してください。次回更新の見積もり依頼と一緒に聞いておくのが確実です。

むしろ増えるのは、お金よりも作業です。上司や経営層へ説明するときは、技術的な背景から入ると話が通りにくくなります。次のように、作業量と業務影響で説明するのが現実的です。

証明書の期限切れは、原因が分かりにくい割に影響が目に見える形で出ます。経営層にも被害が想像しやすいため、予算や工数の相談は比較的通しやすい題材です。

情シスが今やることは、いきなり自動化ではなく「まず棚卸し」

有効期間の短縮を知ると、「すぐにすべての証明書を自動化しなければ」と考えたくなります。しかし、現状を把握せずに自動化を始めると、一部のサーバーだけ対応できても、VPN装置や外部ベンダー管理のシステムが残る可能性があります。

まず取り組みたいのは、次の3点です。

1. 現在使っている証明書を洗い出す
   公開Webサイトだけでなく、VPN、ロードバランサー、アプライアンス、外部委託システムまで確認します。
2. 有効期限と更新方法を一覧化する
   期限は推測せず、実際に画面で確認した日付を記録します。誰が、どの手順で、どこへ設定しているかも残します。
3. 自動更新できないものを確認する
   手作業が残る機器を特定し、100日・47日になった場合の作業量を想定します。

加えて、期限切れを検知する監視も確認しておくと安心です。外部の監視サービスや社内の監視ツールで残日数を監視し、30日前、14日前、7日前と段階的に通知する仕組みがあれば、担当者個人のカレンダーだけに依存せずに済みます。自動更新を導入した環境でも、「自動だから確認不要」ではなく、更新に失敗していないことを確認できる仕組みは必要です。

2026年3月15日から最大200日への短縮はすでに始まっており、3月15日以降に発行・更新した証明書は、従来より早く期限を迎えます。3月中旬ごろに更新した会社であれば、今年の秋ごろがその最初の期限です。そして2027年3月15日には100日、2029年3月15日には47日へとさらに短縮されます。これまで証明書更新を年次作業として扱っていた企業ほど、早めに運用を見直す意味があります。まずは主要な証明書の期限を1件、実際に画面で確認するところから始めてみてはいかがでしょうか。