近年、インターネット通信に必要不可欠なサーバ証明書は大きな転換期を迎えようとしています。証明書の有効期限短縮や次世代暗号技術への移行など、セキュリティ強化を目的とした動きが加速しています。その一方で、サーバ証明書の運用負荷の増大といった課題への対応も迫られており、運用者はこれまで以上に計画的かつ柔軟な対応が求められています。
本稿では、サーバ証明書を取り巻く動向や、それらに対応するポイントを整理するとともに、当社での取り組みについてご紹介します。
インターネット上の通信では、TLS（Transport Layer Security）を用いて通信内容を暗号化し、安全な通信を提供しています。このTLSに欠かせないのが、サーバの正当性を保証する「サーバ証明書」です。
サーバ証明書には有効期限が設定されており、継続利用には定期的な更新が必要となります。従来は毎年、認証局へ申請し更新する運用でしたが、現在この更新プロセスそのものを見直すことが求められています。
本章では、サーバ証明書を取り巻く動向と今後のサーバ証明書運用に求められる要素を解説していきます。
CA/Browser Forum（認証局および主要ブラウザベンダーで構成される組織）は、サーバ証明書の有効期限を段階的に短縮する方針[i]を決定しました。2026年3月15日から有効期限の短縮措置が行われ、最終的には47日まで短縮される予定です。
この変更により、証明書ごとに年1回行っていた更新作業が、年8回以上必要となります。従来の手動運用では、作業負担が大幅に増えるだけでなく、作業漏れや人的ミス増加によるサービスへの影響も懸念されます。そのため、証明書更新作業の自動化による、作業品質向上や運用工数削減が求められています。
|
日付 |
証明書の最大有効期間 |
|
現在 ～ 2026年3月14日 |
398日 |
|
2026年3月15日 ～ 2027年3月14日 |
200日 |
|
2027年3月15日 ～ 2029年3月14日 |
100日 |
|
2029年3月15日 ～ |
47日 |
サーバ証明書の有効期限の短縮に至るまでには、次のような背景があります。
証明書は発行時点の情報を保証しますが、時間経過とともに実際の状況と乖離する可能性があります。証明書の更新間隔を短くすることで、情報の鮮度が保たれ証明書の信頼性も高まります。
ドメイン失効や秘密鍵の漏洩により、第三者が正規の証明書所有者になりすましたり、利用者とサーバの通信に介入し、盗聴や改ざんを行うリスクがあります。証明書の有効期限を短縮化することにより、これらによるインシデント発生時の影響を最小限に抑えられます。
証明書の失効情報を確認する方法としてCRL（Certificate Revocation List）やOCSP（Online Certificate Status Protocol）が利用されています。しかし、これらの手法については、信頼性に関する課題が指摘されています。CRLは、失効状況の反映に遅延が生じるためリアルタイム性に欠けることが問題視されます。一方、OCSPでは、主要ブラウザの多くがOCSPレスポンダへ接続できない場合に可用性を優先する仕様[ii]となっており、失効検証が必ずしも実行されるとは限りません。これらの課題から失効確認メカニズムに依存するのではなく、証明書自体の有効期間を短縮することで、失効情報が反映されないリスクを低減できます。
従来の人手での更新運用は上記のとおり運用負荷増加により困難となるため、自動更新の導入が促進されると考えられます。また、危殆化した暗号方式を利用している証明書の場合でも、迅速に新暗号方式へ置き換えることが可能です。詳細については次の章で解説します。
前述のとおり、自動化の背景の一つとして、既存の暗号方式が危殆化した場合に迅速に新暗号技術へ移行する能力（クリプトアジリティ）が求められます。特に近年では量子コンピュータの実用化が急速に進展しており、計算効率の大幅な向上が期待されています。その結果、古典コンピュータでは解読が困難とされていた従来の暗号方式は危殆化する可能性が指摘されています。これを受けてNIST（米国国立標準技術研究所）では、これらの脅威に対抗しうる耐量子計算機暗号（PQC: Post-Quantum Cryptography）の標準化を推進しています。[iii]サーバ証明書もこの影響を免れず、クリプトアジリティが求められます。証明書の自動更新に加えて、以下の要素が必要です。
可視化によって、サーバ証明書ごとの暗号方式や有効期限を把握できます。更新漏れや運用ミスのリスクを低減するとともに、新暗号技術への移行対象の特定が容易となります。
証明書管理と同様に、暗号鍵の管理も重要です。HSM（Hardware Security Module）など安全な場所に集約して保管することで、漏洩リスクを低減できます。さらに、管理を集中させることで鍵の利用状況を把握しやすくなり、暗号アルゴリズムやシステム移行計画時に役立ちます。
これらのサーバ証明書を取り巻く変化に対応するためには、まずは証明書運用そのものを自動化する仕組みが不可欠です。本章ではその中核となるACMEについて解説します。
ACME（Automatic Certificate Management Environment）とは、証明書の発行プロセスを自動化するプロトコルです。RFC 8555[iv]にて策定されており、HTTPSリクエストを介して利用者（ACMEクライアント）と認証局（ACMEサーバ）が通信することで証明書の自動取得、更新、無効化を実現します。
ACMEではドメイン所有権を検証し、利用者のドメイン所有権を確認できた場合にACMEサーバから証明書を発行します。証明書の発行は以下のような流れで進みます。
また、エンタープライズ用途で使用されることが多いOV/EV証明書については、ドメイン所有権の検証に加えて組織や団体の実在確認が必要となります。この実在確認はACMEによる自動化の対象外です。したがってOV/EV証明書を自動更新する場合は、組織や団体の実在確認の検証方法及びACMEへの対応状況を各プロバイダへ事前に確認する必要があります。
ACMEにおけるドメイン所有権にはいくつかのチャレンジ方式[v]があります。ここでは代表的な2つの方式について解説します。
ACMEサーバから発行されたトークンをWebサーバの特定のURLに設定する方式です。
（http://<DOMAIN>/.well-known/acme-challenge/<TOKEN>）
HTTP-01方式の利点は、導入が容易である点です。ACMEサーバから所定のURLへのアクセスを許可し、ACMEクライアントを導入するだけで実装可能です。一方で、対象サーバが外部からhttp（80番ポート）でのアクセス可能であることや、ワイルドカード証明書の発行には対応していないといった制限があります。これらの条件を満たせない場合は、DNS-01チャレンジ方式の利用が推奨されます。
ACMEクライアントがトークンをDNSのTXTレコードに設定する方式です。以下の形式でトークンを設定します。
_acme-challenge.<DOMAIN> TXT <TOKEN>
DNS-01方式の利点として、汎用性が高く様々な環境の要件に適用しやすいことがあげられます。HTTP-01方式では対応していないワイルドカード証明書や外部非公開環境でも導入が可能です。ただし、ACMEの処理中にDNSレコードを動的に更新する必要があるため、DNS プロバイダがAPIに対応している必要があります。
HTTP‑01チャレンジ方式は導入の容易性という観点で優れています。一方、DNS‑01チャレンジ方式は要件適合性の面でより優れています。チャレンジ方式の選択は、環境ごとに求められる要件に基づきご検討ください。また、チャレンジ方式の比較は、下記に詳細を記載しておりますのでご参照ください。
|
比較項目 |
HTTP-01 |
DNS-01 |
|
チャレンジ方法 |
Webサーバの所定のURLを確認 |
DNSのTXTレコードを確認 |
|
導入の容易さ |
容易 |
やや複雑 |
|
証明書の対応範囲 |
シングルドメイン証明書 |
シングルドメイン証明書 |
|
通信要件 |
HTTP（80番ポート）許可 |
DNSプロバイダ側でAPI対応 |
|
用途 |
Webサイト証明書や簡単なシングルドメイン向けの証明書 |
メールサーバや外部非公開サーバ、ワイルドカード証明書向け |
これまでの話を踏まえて、当社の取り組みについて解説します。当社では、オンプレミス型およびクラウド型のセキュリティ製品を対象としたマネージド・サービス（SPRO：SecurePROtecht[vi]）を提供しています。サービスの一環として、ロードバランサーやWAFなど、TLS終端デバイスの管理も含まれており、デバイスに設定されている証明書の更新を行っています。
これまでは証明書更新を手作業で行ってきましたが、現在はACMEを活用し、証明書更新を自動化するオプションサービスの開発に取り組んでいます。
本サービスでは、マネージド・サービスとしての運用を含めた証明書の自動更新を実現いたします。また、お客様の環境や運用状況に応じて、柔軟に対応できる仕組みを整えています。
本サービスでは、ACME/DNS-01チャレンジ方式による自動化を採用しております。外部からアクセスできない環境やワイルドカード証明書の更新に対応しています。また、証明書の発行元としてAPIによるレコード更新に対応している場合は、本サービスの対象とする予定です。
自動化により人手での更新運用は不要となりますが、更新時にエラーが発生した場合には迅速に検知する運用体制は重要です。本サービスでは、自動処理の各フェーズで正常性の確認を実施し、想定外の事象があればSPRO担当者が確認・対応します。自動化だけでなく“運用”までマネージドすることで、更新失敗時の影響を最小化します。
証明書の有効期限を継続的に監視することで、更新漏れによるサービス停止リスクを抑えます。
証明書の更新間隔が最終的に47日になると、頻繁に更新作業が必要となるため、デバイスへの反映タイミングの制御が難しくなると予想されます。一方で、お客様のサービス特性によっては、夜間に証明書の反映を実施したいといった要件もあると考えています。本サービスでは、お客様のサービス運用に合わせて反映時刻を指定できる設計としています。 ※あらかじめ設定された範囲内で指定可能です。
まずは本サービスを使用した証明書更新の自動化を実現していきます。今後は、PQC対応を見据え、クリプトアジリティ向上に向けた施策として、証明書の可視化・鍵管理を含むCLM（Certificate Lifecycle Management）として統合的に扱えるサービスの展開を進めていく予定です。
また、サーバ証明書を活用したサービスはWebサービスだけではございません。メールサービスをはじめとした製品のデバイス展開も進めていきます。
本稿では、今後サーバ証明書の運用に求められるポイントや当社の取り組みについて解説しました。サーバ証明書に関連する最新動向や技術は急速に進歩していますが、来たる日には大きな変化が求められると予想されます。その変化に適応するためには、先んじた対策が重要です 。また、単に対策を講じるだけではなく、安全・安心なサービス提供が第一です。障害発生時には迅速に対応できる体制づくりなど運用者の観点からも考慮し、将来的な変化に備える必要があります。本稿が、各サービスやシステムにおける証明書運用について、現状を整理し見直すきっかけとなれば幸いです。
[i] Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods | CA/Browser Forum, https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods
[ii]Intent to End OCSP Service, https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls
[iii] Post-Quantum Cryptography | CSRC, https://csrc.nist.gov/projects/post-quantum-cryptography
[iv] RFC 8555: Automatic Certificate Management Environment（ACME）, https://www.rfc-editor.org/rfc/rfc8555
[v] Challenge Types - Let's Encrypt, https://letsencrypt.org/docs/challenge-types/
[vi] マネージドセキュリティサービス｜SecurePROtecht, https://www.nri-secure.co.jp/service/mss/secureprotecht