SSL証明書の期限切れ対策|2026年の200日化・47日化と更新管理・自動化のポイント

更新日:2026-05-01 公開日:2025-10-07 by アツシバ

目次

SSL証明書の期限切れ対策|更新管理・47日問題・自動化まで解説

SSL証明書の有効期限は、今後段階的に短縮されることが決まっています。特に2026年には有効期間の上限が200日に短縮され、その後さらに短期化が進み、将来的には47日まで短くなる見込みです。

これにより、証明書更新の頻度はこれまでより大幅に増加します。手動で管理している場合、更新漏れによるサイト停止やセキュリティリスクが現実的な課題になります。

この変化により、「更新忘れを防ぐ」だけでなく、「更新作業そのものを減らす」運用設計が求められています。本記事では、SSL証明書の期限切れを防ぐための基本対策と、短期化に対応するための運用の考え方を整理します。

SSL証明書の期限切れはなぜ問題になるのか

SSL/TLS証明書の期限切れは、見落とされがちな運用課題の一つです。更新漏れが発生すると、Webサイトの閲覧不能や警告表示につながり、サービス停止や機会損失を招く可能性があります。

期限切れは単なる設定ミスではなく、サービス継続性や信頼性を損なう運用事故です。ECサイトや会員サイト、企業サイトでは、ユーザー離脱や問い合わせ増加、ブランド毀損にもつながります。

主な影響は以下の通りです。

・Webサイトに警告が表示される
・ユーザーが離脱しやすくなる
・問い合わせやクレームが増える
・復旧対応に工数がかかる

SSL/TLS証明書の基本

SSL/TLS証明書は、Webサーバーとブラウザ間の通信を暗号化し、第三者による盗聴や改ざんを防ぐために使われます。また、接続先が正規の運営者であることを証明する役割もあります。

現在はTLSが主流ですが、「SSL」という名称が一般的に使われ続けています。

ただし実務では、仕組みの理解以上に、期限管理と更新運用をどう回すかが重要になります。

SSL証明書の有効期間短縮(200日化・47日化)とは

近年、SSL/TLS証明書の有効期間は短縮される方向で見直しが進んでいます。

現時点で実務に影響が大きいのは、将来の47日化ではなく、2026年の200日化です。本セクションでは、将来の短期化も含めて全体像を整理します。

SSL証明書の有効期限短縮は、いきなり47日になるわけではなく、段階的に進みます。まずは2026年に200日へ短縮され、その後さらに短期化が進む見込みです。

有効期間の短縮により、証明書更新の頻度は増加し、運用負荷が大きくなっています。特に複数のドメインやサービスを運用している場合、手作業での管理では更新漏れが発生しやすくなります。

SSL/TLS証明書の最大有効期間が段階的に短縮

SSL証明書の有効期間は、以下のスケジュールで段階的に短縮されます。特に2026年の200日化は、運用に直接影響する重要な変更です。(※1)。

・SSL/TLS証明書の有効期間

期間 最大有効期間
現在~2026年3月14日 398日(約13か月)
2026年3月15日~2027年3月14日 200日(約6.5か月)
2027年3月15日~2029年3月14日 100日(約3か月)
2029年3月15日以降 47日(約1.5か月)

重要な注意点として、証明書の有効期間は「1日=86,400秒」で計算されます。これを1秒でも超えると翌日扱いになるため、実際の運用では余裕を持った期限設計が必要です(※1、参考:※2)

ドメイン認証の有効期間も大幅短縮

証明書を発行する際に必要な「ドメイン認証」(DCV:Domain Control Validation)の有効期間も同様に短縮されます(※2)

・ドメイン認証の有効期間

期間 再利用可能期間
現在~2026年3月14日 398日(約13か月)
2026年3月15日~2027年3月14日 200日(約6.5か月)
2027年3月15日~2029年3月14日 100日(約3か月)
2029年3月15日以降

10日

最終的には、一度実施したドメイン認証の結果を再利用できるのはたった10日間になります。これは証明書の発行・更新と認証を自動的に連動させる仕組みが必須になることを意味します。

手動での証明書管理は限界に近づいている

2027年の100日段階でも年4回以上の更新が必要となり、手動での管理は限界に近づいています。
2029年の47日になれば、年8回の更新が必要となり、完全に自動化しなければ対応が難しくなります。

SSL証明書の運用でよくある課題(更新漏れ・属人化)

証明書の期限切れは、単純なミスではなく、運用体制の問題として発生するケースが多くあります。

よくある課題は以下の通りです。

・証明書の有効期限を一覧で管理できていない
・担当者依存で更新が管理されている
・更新手順が属人化している
・複数サービスの証明書を一元管理できていない
・退職・異動時の引き継ぎが不十分

SSL証明書の期限切れを防ぐ運用対策(更新管理・監視・自動化)

証明書失効を防ぐには、個人の注意ではなく、仕組みで管理することが重要です。

証明書台帳を整備する

どのドメインで、どの証明書を使っているかを一覧化します。有効期限、担当者、設置箇所などを整理しておくことで、抜け漏れを防げます。

期限監視とアラートを設定する

手作業での更新管理には限界があります。 有効期限前に通知が来る仕組みを導入し、余裕を持った更新対応を可能にします。

更新手順を標準化する

更新申請から反映、確認までの手順をドキュメント化し、誰でも同じ手順で対応できる状態にします。

自動更新を前提とした運用設計が必要になる

証明書の発行・更新・配信を一連の仕組みとして自動化することで、更新漏れや設定ミスのリスクを大幅に低減できます。

クラウド環境におけるSSL証明書管理の注意点

クラウド環境では、ロードバランサーやCDNなど、証明書が関係する箇所が増えやすくなります。

以下のようなミスが起きやすいため注意が必要です。

・ロードバランサー側の証明書更新を忘れる
・CDN側だけ古い証明書が残る
・本番と検証環境で更新タイミングがずれる

そのため、証明書の設置場所を可視化し、管理責任と確認手順を明確にすることが重要です。

SSL/TLS証明書短期化への実務対応チェックリスト

1.現状把握(棚卸し)

まず、以下の情報を整理しましょう。

  • 管理しているすべての公開SSL/TLS証明書
  • それぞれの証明書の発行元(認証局)
  • 証明書が設置されている場所(Webサーバー、ロードバランサー、CDN、WAFなど)

2.自動化システムの検討

以下の選択肢から、自社に適した方法を選びます。

  • ACME:証明書の自動発行・更新の標準プロトコル(Let's Encryptだけでなく、商用認証局も対応)(※4)
  • ARI:ACME Renewal Informationによる更新タイミングの最適化(※5)
  • CLM:証明書ライフサイクル管理製品による統合管理

3.更新タイミングの設計

  • 有効期間の3分の2が経過した時点で自動更新するよう設定(47日の場合、約30日目で更新開始)
  • 「1日=86,400秒」の規定による計算ミスを避けるため、常に期限に余裕を持たせる(※2)

4.鍵管理と配信の仕組み

  • 証明書と秘密鍵の管理システム(HSM/KMS)の準備
  • サービス停止なしで証明書を更新する仕組みの構築
  • 複数拠点(CDN、エッジサーバーなど)への証明書配信の自動化

5.監視とテスト体制

  • 証明書の有効期限を常時監視するシステムの導入
  • 証明書設定の不備を検出できる仕組みの構築
  • テスト環境での自動更新の動作確認

証明書管理はセキュリティ対策の一部

SSL証明書の期限切れは、サイバー攻撃ではありませんが、サービス停止や信頼低下を招くという点で重要な運用リスクです。

証明書管理は、認証・監視・バックアップと並ぶ重要な運用テーマです。

サイバー攻撃対策やセキュリティ全体の考え方については、以下の記事も参考になります。
サイバー攻撃対策の基本

ドメイン認証も頻繁に必要に

2029年以降は、ドメイン認証の結果を再利用できるのがわずか10日間となります。証明書の発行・更新のたびに、ほぼ新規で認証作業が必要になります。

運用ミスのリスクが増大

更新頻度が増えることで、更新忘れや設定ミスのリスクも増加します。証明書の期限切れは、Webサイトへのアクセス不能やブラウザでの警告表示につながり、企業の信頼性を大きく損なう可能性があります。

よくあるご質問(FAQ)

Q. OV証明書やEV証明書も47日に短縮されるのですか?

A. はい、すべての公開TLSサーバー証明書が対象です。組織認証(OV)や拡張認証(EV)証明書も同じ期限が適用されます。ただし、組織情報の再利用期間は825日から398日への短縮にとどまります(※1)

Q. なぜ段階的に短縮されるのですか?(200日・100日・47日)

A. 2023年にGoogleが90日を提案しましたが(※3)、最終的にAppleが提案した47日案が採用されました。「31日+15日+1日」という計算で、実運用に耐える期間として設計されています(※1)

Q. 段階を踏まず、いきなり47日になるのですか?

A. いいえ、2026年、2027年、2029年の3段階で徐々に短縮されます。段階的な移行により、企業が準備する時間を確保できます(※1)

Q. 証明書の料金は増えますか?

A. 契約内容によります。多くの認証局では年額契約で再発行が含まれているため、更新回数が増えても追加料金は発生しません。ただし、自動化ツールの導入には初期投資が必要です。

Q. 内部向けの証明書も対象ですか?

A. いいえ、今回の短縮は「公開」TLSサーバー証明書のみが対象です。社内システム用の証明書(プライベート証明書)は影響を受けません(※1)

まとめ―短期化をチャンスに変えるために

証明書の有効期間短縮はすでに始まっており、まずは2026年の200日化への対応が重要です。特に、従来の年1回更新を前提とした運用からの見直しが必要になります。
将来的な47日化を見据え、手動管理に依存しない運用体制への移行を進めましょう。

2027年(100日)の段階で手動管理は困難に
2029年(47日)では完全自動化が必須


今すぐ取り組むべきこと

・現状把握:証明書の棚卸しと管理体制の確認
・自動化の検討:ACME/CLMツールの選定と導入計画
・体制整備:更新フローの見直しと担当者のトレーニング


この変化を「負担」ではなく「セキュリティ強化と運用効率化の機会」と捉え、早期の対応を進めることが重要です。適切な自動化体制を整えることで、より安全かつ効率的な証明書管理を実現できます。

今回の有効期間短縮により、証明書の更新頻度が大幅に増加することは避けられません。しかし、この変更がお客様の運用負担増加につながらないよう、私たちは以下の取り組みを進めています。

  • サービス内容の拡充:自動化対応を含む新たなサービスメニューの準備
  • サポート体制の強化:段階的な短縮に合わせた適切なタイミングでの対応
  • お客様への情報提供:最新動向と対策に関する継続的な情報発信

証明書の更新頻度が増えるこれからの運用では、「人で管理する」から「仕組みで管理する」への転換が重要になります。

🔶証明書管理に関するご不安やご質問がある方へ

証明書管理や運用体制の見直しについてお困りの場合は、環境に応じた最適な方法をご提案可能です。
まずはお気軽にご相談ください。

証明書管理・自動化の無料相談はこちら

【脚注・参考文献】
本記事は2025年9月17日時点の情報に基づいています。最新の情報については、CA/Browser Forumおよび各認証局の公式サイトをご確認ください。

1.BR-SC081v3(改訂PDF・最大有効期間/46・47日/1日=86,400秒/データ再利用期間)
2.Apple Support:398日制限の案内(2020-09-01~)
3.Chromium Blog(Google):90日構想と自動化の文脈
4.IETF RFC 9773:ACME Renewal Information(ARI)
5.GlobalSign:ACMEでOV証明書をサポート発表

この記事をシェアする

  • 記事をnoteでシェアnote
  • 記事をメールでシェアメール
  • 記事のリンクをコピーリンクをコピー

関連記事