2025年4月、CA/Bフォーラム（The Certification Authority/Browser Forum）よりSSL/TLSサーバ証明書（以下、サーバ証明書）の有効期間の段階的な短縮が投票（SC-081v3）により決定されました^[1]。これにより、2029年3月15日以降に発行されるサーバ証明書の最大有効期間が47日になります^[2]。2025年4月時点でサーバ証明書の有効期間は最大398日のため、2029年には約8分の1に短縮されることになります。このコラムの1章ではサーバ証明書の有効期間を短縮する目的と課題を歴史も交えて解説します。2章でサーバ証明書の運用コスト増加に対する解決策であるサーバ証明書更新自動化の重要性についてお伝えし、当社が提供するサーバ証明書更新自動化ソリューションもご紹介します。

1. サーバ証明書の有効期間短縮の歴史と現状の課題

1-1. 有効期間短縮の決定とその歴史

有効期間短縮を主導するCA/Bフォーラムの役割

CA/Bフォーラムがサーバ証明書の有効期間短縮を決定した背景を理解するために、まずCA/Bフォーラムの役割について説明します。
CA/Bフォーラム（The Certification Authority/Browser Forum）とは、サーバ証明書を発行する認証局（CA：Certificate Authority）と、Chromeの提供元であるGoogleをはじめ、Safariを提供しているAppleやEdgeの提供元であるMicrosoftといった主要なブラウザベンダなどで構成される団体であり、ブラウザを介してパブリックなインターネットで通信を行う際のセキュリティに関する取り決めを行っています^[3]。つまり、CA/Bフォーラムが決定したサーバ証明書の要件に従って、主要ブラウザベンダがブラウザの動作を変更しているため、今回の有効期間短縮の決定は実質的に強い拘束力を持っています。

有効期間短縮の決定プロセスとこれまでの経緯

これまで何度もCA/Bフォーラムによってサーバ証明書の有効期間は短縮されていきました。かつてはサーバ証明書の有効期間が最大5年に設定されていた時代もありました^[4]。しかし、CA/Bフォーラムでの決定により、その有効期間は段階的に短縮されていきました^[5]。有効期間の変更については、フォーラム参加者がCA/Bフォーラムに提案し、その提案が投票で可決されることで正式に決定されます。このような流れで年々有効期間が短縮されていき、冒頭にも書いた通り、2025年4月に更なるサーバ証明書の有効期間の段階的な短縮が決定しました。具体的には2026年3月15日以降に発行されるサーバ証明書の有効期間は最大で200日、2027年3月15日以降に発行されるサーバ証明書の有効期間は最大で100日、2029年3月15日以降に発行される場合最大で47日に決定されました。またドメイン名の認証も段階的に短縮され、2029年3月15日以降は10日に短縮されます^[2]。この決定にいたるまでにも歴史があり、2023年にはGoogleがサーバ証明書の有効期間を90日に短縮する提案を行い^[6]、2024年にはAppleが200日、100日と段階的に短縮し、2029年までには最大47日にすることを提案しました^[7]。しかし、2020年に有効期間が最大398日に短縮された際には例外が発生しました。Appleが先行してサーバ証明書の有効期間を13か月に短縮するルールを発表し、それに従ってSafariも同様の短縮を宣言しました。その結果、2020年9月以降に発行されたサーバ証明書で有効期間が13か月を超えるものは、Safariによって信頼されなくなり、その後、CA/Bフォーラムでもこの有効期間が正式に採択されました^[8]。このように正式に採択されていないケースでも一部のブラウザベンダ主導で有効期間の短縮が実施された経緯があることから、今後も短縮化の流れが覆る可能性は低いと考えられます。

図1

1-2. 有効期間短縮の背景

秘密鍵漏えいに対する対策

有効期間を短縮する背景の一つに、サーバ証明書の要ともいえる秘密鍵の漏えい対策が挙げられます。
秘密鍵の利用期間を短くすることはセキュリティの強化に繋がります。例として有効期間が1年のサーバ証明書と有効期間が3か月のサーバ証明書を比較してみます（図2）。

図2

この二種類のサーバ証明書を2024年4月に発行しましたが、半年後の2024年10月にそのサーバ証明書の秘密鍵が流出してしまったとします。この場合、有効期間が1年のサーバ証明書①はまだ有効であるため、万が一秘密鍵が流出した場合、第三者に悪用されるリスクが残ります。一方、有効期間が3か月のサーバ証明書②の場合、すでに期限が切れているため、たとえ秘密鍵が流出しても悪用されるリスクは下がります。

このように、有効期間が短いほど秘密鍵流出時におけるリスクの持続期間を限定できるため、セキュリティの観点から有効期間を短くすることは有効な対策となります。また、過去より Heartbleed^[10], BEAST^[11]などのTLSやOpen SSLの脆弱性により、緊急でサーバ証明書を入れ替える必要性なども度々発生しています。これらの被害を最低限に抑えるためにも、サーバ証明書有効期間を短くすることが求められています。

CA/Bフォーラムの仕様変更への素早い対応

近年、インターネット利用の広がりを受けて、IETF（The Internet Engineering Task Force）が公開するインターネット規格であるRFC、そして暗号の規格・ベストプラクティスを定めるNIST（The National Institute of Standards and Technology）などの団体が、攻撃への耐性を強めるため様々な規格を出しています。CA/Bフォーラムはそのルールに従い、迅速にセキュリティの強化を図ろうとしています。しかし、サーバ証明書の有効期間が長いと古い規格のサーバ証明書が市場に長く残ってしまう問題点があります。さらに、サーバ証明書の有効期間だけではなく、認証局（CA）に対する運用ルールはセキュリティ強化の観点から厳格化が進んでおり、CA/Bフォーラムでもサーバ証明書の仕様変更が頻繁に議論されています^[4]。このような背景の中、サーバ証明書の有効期間を短縮することは大きなメリットとなります。たとえ仕様が変更されたとしても、既に発行されているサーバ証明書に関しては有効期限が切れるまでは使えてしまいます。しかし、有効期間が短いと、仕様が変更され、セキュリティが強化されたサーバ証明書を短時間で市場に浸透させることができます。

1-3. 有効期間短縮の影響

毎年、サーバ証明書の更新には多くの作業が発生しており、運用するサーバ証明書の数が増えれば増えるほど運用工数は増大していきます。また、更新の度に手順忘れや、担当者変更による引継ぎ不足等が原因で、更新作業がスムーズにいかず更に担当者の手を煩わせることもあります。このような状況下で年々サーバ証明書の有効期間が短縮され、認証確認が頻繁に行われるため、サーバ証明書更新の回数が増えます。その結果、ますます作業工数は増え、ミスの発生リスクも高まり、必要な人員も増加し、サーバ証明書の運用コストは増大します。このような背景から、サーバ証明書の更新自動化の有効性が高まっています。次の章でそのメリットおよび具体的なソリューションである証明書更新自動化プラットフォーム（Trust Lifecycle Manager：TLM）についてご紹介します。

2. サーバ証明書の有効期間短縮に効率的に対応するには

2-1. サーバ証明書更新自動化のメリット

これまでの作業を自動化することによって享受されるメリットを三つご紹介します。

運用コストの削減が可能

一番大きいメリットとしては、更新を自動化することで今後も増え続ける運用コストを最小限に抑えることができます。デジサート社の調査では、一つのサーバ証明書の更新に平均約3時間かかることがわかっていますが、その作業を自動化することによって作業工数の大部分を抑えることができます。これが複数のサーバ証明書になればさらに多くの作業工数を短縮できるようになります。

作業ミスの減少

また、これまで手作業で行っていた煩雑な作業を自動化することにより、人的ミスを減少させることができます。これにより、サーバ証明書の更新漏れや誤設定などのリスクを軽減できます。

暗号技術に対する新しい脅威への素早い対応の準備

最後に、サーバ証明書の更新を自動化しておくことが、将来的なセキュリティリスクへの備えとしても有効である点に触れておきます。近年、量子コンピュータの進展により、現在広く使われている暗号技術が10年以内に解読可能になるという見方が出てきています^[12]。これに対抗するための新たな暗号方式として、「耐量子暗号（PQC）」の標準化が進められていますが、2025年5月時点ではまだPQCに対応したパブリックサーバ証明書は一般には提供されていません。しかし、今後PQCサーバ証明書の導入が進められる段階になれば、ハイブリッドサーバ証明書（RSA＋PQC）など新しい形式への切り替えが必要になる可能性があります。その際に、ベンダサービスによってサーバ証明書更新の自動化が導入されていれば、仕様が整い次第、PQC非対応の既存サーバ証明書から自動でハイブリッドサーバ証明書へ更新できることが期待できます。したがって、新形式への対応も比較的スムーズに行える環境が整っていると言えるでしょう。更新作業の手間やエラーのリスクを減らすことにより、IT部門は将来的なPQC対応に向けた準備や実証実験（PoC）に集中できるようになります。現在の運用負荷を軽減しつつ、将来のセキュリティ要件にも柔軟に対応していくために、サーバ証明書更新の自動化は有効な基盤となります。

2-2. 証明書更新自動化ソリューションの紹介

当社では、デジサート社の正規販売代理店として、サーバ証明書更新自動化サービス「Trust Lifecycle Manager（以下、TLM）」を取り扱っています。また、TLMの導入支援も提供しています。
導入に際しては、まず当社で用意した導入可否確認表を用いて当該サービスが導入可能か確認し、必要に応じて当社より検証支援も実施します（図3：①）。

図3

TLMの構成には大きく二種類あり、エージェントを用いた方法と、センサーを用いた方法があります。エージェント型に関しては、以下の図4のようにWebサーバにエージェントをインストールして、そのWebサーバ内のサーバ証明書を管理します。

図4

センサー型に関しては、以下の図5のようにセンサーをインストールしたサーバをお客様の環境内に構築いただき、センサーによってロードバランサ等のアプライアンス内のサーバ証明書を管理します^[13]。

図5

前者のエージェント型はSSL/TLS暗号化の終端場所がWebサーバ、後者のセンサー型は終端場所がWebサーバの手前のロードバランサになります。
エージェントやセンサーの導入が完了したら（図6：②）、事前に洗い出している更新自動化対象のサーバ証明書を確認します。必要であればお客様のネットワーク環境をTLMの機能でスキャンし、対象のサーバ証明書を一覧として洗い出すことも可能です（図6：③）。そしてTLMでサーバ証明書情報の入力等の初期設定を行うことにより、サーバ証明書の更新業務が自動化されます（図6：④）。

図6

2-3. サーバ証明書の更新の流れ

サーバ証明書の自動更新には「手動でトリガーを引く実行方式」と、より工数の少ない「スケジュールによってトリガーを引く実行方式」があります。前者の手動実行の場合、CSRの作成、サーバ証明書発行情報の入力をはじめとした申請作業の大部分、サーバ証明書の発行・インストールが自動化されます。後者のスケジュールによる実行の場合は組織・ドメイン認証作業を事前に完了させていれば、更新のタイミングでは完全に自動化することができます（図7）。またどちらの発行方式でも更新時間を大幅に短縮することが可能です。

図7

2-4. 運用の流れ

手動更新における運用の流れ

TLMによってサーバ証明書の運用がどう変わるかを説明するために、手動更新の場合の運用例を見てみます。下のシーケンス図（図8）はある企業のサーバ証明書を手動更新する際の運用の流れを表しています。図からも分かるように、CSR取得の際とサーバ証明書をインストールする両方で手順書の作成やリリース判定などが必要となります。

図8

自動更新における運用の流れ

一方で、TLMを用いた自動更新の場合は、手動でCSR作成コマンドをサーバに実行することなくCSRの発行から証明書インストールまで実行できるため、手順書の作成やリリース判定をまとめて一度に行うことも可能になります。また、作業自体もTLM上でサーバ証明書更新に必要な項目を入力するだけです（図9）。

図9

次にお見せするのが、当社の検証環境におけるTLMの操作画面です。上記の運用の中でTLMをどのように操作してサーバ証明書を更新するのかをご説明します。

TLMの操作画面

図10がベースとなるTLMの最初のダッシュボード画面になります。概要を説明すると、ここではサーバ証明書の有効期限の状態や管理しているサーバ証明書の発行元の情報などがわかります。

図10

ダッシュボード画面の左ペインの【Inventory】を選択すると、図11のように管理しているサーバ証明書の情報を一覧で確認することができます。また表示されている列はカスタム可能でさまざまなサーバ証明書のステータスを表示することができます。ステータスを確認することで各サーバ証明書の有効期限や自動化の対象であるかどうかなども一目で見てわかるようにできます。

図11

図11のインベントリ画面上でフィルタをかけることによって、更新したいサーバ証明書を選択することができます。図12ではTLMによる自動化対象のサーバ証明書だけが表示されるようにフィルタリングしています。

図12

サーバ証明書を選択するとその詳細が図13のように表示されます。更新対象であることを確認して右上の更新ボタンの押下により更新情報入力画面に移ります。

図13

図14ではサーバ証明書更新のための情報を入力します。事前に手順書などが用意されている場合なら、5分以内に入力作業は完了します。なお、今回お見せするのは手動による自動更新であり、スケジュールによる実行方式であればこの入力作業も省略することが可能です。そして一番下までスクロールし、左下の【Submit】ボタンを押下すると更新が開始されます。

図14

更新ボタンを押下すると図15のような画面に遷移します。右側にサーバ証明書の更新作業状態が映し出されます。作業者は何もせずにインストールまで完了となります。更新は1,2分で完了します。

図15

このように、TLMを用いることによって簡単にサーバ証明書を更新することができます。

2-5. 当社サービスとTLMの強み

当社が証明書更新自動化サービスのプラットフォームにTLMを選んだ理由として、多種多様なサーバやアプライアンスに対応できることが挙げられます。WebサーバならLinux（CentOS, RHEL, Ubuntu）とWindows（2016,2019,2022）に対応しており、ロードバランサのようなアプライアンスであればF5 BIG-IP LTM, Citrix ADC, A10, AWSに対応しています。また、ドメイン名の認証の自動化にも対応しています。
さらに、Tenable、Qualysなどのスキャンサービスを導入済みの環境であればTLMとの統合が可能です。さらに、ServiceNowによる社内承認フローとの統合やAWSやMicrosoft Azureといった外部クラウドサービスとの統合、そして社内で利用してきた自社PKIとの統合により企業が利用するPKI証明書を一元管理、運用を行うこともできます。また、将来的にはPQCを用いたサーバ証明書の更新にも、サーバ証明書の仕様が整い次第対応予定です。

3. 最後に

本コラムでここまで述べたとおり、サーバ証明書の有効期間の短縮が決定したため、今後に向けてサーバ証明書の更新自動化が急務です。サーバ証明書の更新自動化を検討している場合、またはこれらの技術に関する質問がある場合はぜひ当社にお問い合わせください。当社は、お客様のサーバ証明書運用の負担を低減させるための最適なソリューションをご提供します。