データ分析

SSL証明書のプロフェッショナルサービス

47日時代の証明書運用を、実測と自動化で支えます

証明書は「買って終わり」ではなくなりました

CA/Browser Forumの決議により、SSL/TLS証明書の最大有効期間は2026年2月以降199日、2027年3月に100日、2029年3月には47日へと短縮されます。
1年に1回だった更新作業は、最終的に年8回程度まで増えます。
証明書を1,000枚管理している組織であれば、営業日ベースで毎日20件以上の更新処理が発生する計算になります。
詳しくはSSL/TLS証明書の有効期間短縮(いわゆる「47日問題」)についてをご覧ください。

この変化で問題になるのは、証明書の価格ではなく運用です。
Spelldataでは、DigiCert証明書の販売に加えて、以下の2つのプロフェッショナルサービスをご提供しています。

1. Catchpointによる証明書の実測監視
全国7都市の計測センターから、実際のユーザー環境で証明書が正しく配信されているかを継続監視します。
2. CDNでの証明書自動更新
CloudflareやGcore CDN上で、DigiCert証明書の発行から配置までを自動化するパイプラインを構築します。

1. Catchpointによる証明書の実測監視

管理画面が正常でも、ユーザーから見えているとは限りません

証明書の有効期限は、認証局の管理画面やCLMツールでも確認できます。
しかし、それらが確認しているのは「発行された証明書のデータ」であり、「利用者のブラウザに実際に届いている証明書」ではありません。

特にCDNを経由している構成では、以下のような事象が起こり得ます。

これらは、発行元の管理画面からは見えません。
実際にユーザーがいる場所から、ユーザーと同じ回線で接続して初めて検知できます。

Spelldataの計測環境

Spelldataは、日本国内7都市に自社の計測センターを保有しています。
NTT回線とKDDI回線、および4キャリアの5G回線を用いて、実ユーザーと同じ経路からの計測を行っています。
この環境は、証明書の配信状態を地域別・回線別に検証できる、日本で唯一の計測基盤です。

監視項目

証明書の有効期限
実際に配信されている証明書の有効期限を監視し、期限が近づいた段階でアラートを通知します。
更新したはずの証明書が反映されていない場合も、この監視で検知できます。
証明書チェーンの構成
中間証明書が正しく設定されているか、チェーンの段数が適切かを検証します。
チェーンが不完全な場合、一部のクライアントでのみ接続エラーが発生することがあります。
地域別・回線別の配信状態
7都市の計測センターから、それぞれ異なる回線で接続し、配信されている証明書が全拠点で一致しているかを確認します。
CDNのPoPごとの反映漏れを検知できます。
TLSハンドシェイクの所要時間
証明書の鍵アルゴリズム(RSA / ECC)やチェーンのサイズが、接続時間にどの程度影響しているかを実測します。
表示速度の改善余地を、証明書の観点から定量的に把握できます。
OCSPステープリングの動作
OCSPステープリングが有効に機能しているかを確認します。
設定漏れがあると、クライアント側で失効確認の通信が追加で発生し、初回接続が遅くなります。

PQC移行に向けた事前検証

NISTが標準化したPQC(耐量子暗号)のアルゴリズムでは、署名と公開鍵のサイズが従来のRSAやECCと比べて大きくなります。
証明書のサイズが増えれば、TLSハンドシェイクで転送されるデータ量も増加します。
この影響は、光回線では体感されにくい一方、モバイル回線や電波状況の悪い環境では表示速度の差として現れる可能性があります。

Spelldataの計測環境では、4キャリアの5G回線を用いて、この影響を移行前に定量評価できます。
PQC対応をいつ、どの範囲で進めるべきかを、推測ではなく実測データに基づいて判断していただけます。

2. CDNでの証明書自動更新

CDNのカスタム証明書は、自動更新されません

CloudflareやGcore CDNでは、CDN側が発行する無償のLet's Encrypt証明書であれば、自動的に更新されます。
しかし、DigiCertなど特定の認証局の証明書を使いたい場合は、「カスタム証明書」としてアップロードする形になります。

Cloudflareの公式ドキュメントには、カスタム証明書についてCloudflare側で発行・更新の管理は行わず、有効期限までの更新は利用者の責任であると明記されています。
Gcore CDNの「ご自身のSSL証明書」機能も同様です。
また、CloudflareのAdvanced Certificate Managerでは、以前は発行元CAとしてDigiCertを選択できましたが、Cloudflareはこの選択肢からDigiCertを段階的に外す方針を示しています。

つまり、CDNを利用しながらDigiCertの証明書を使い続ける場合、47日サイクルでの手作業アップロードが必要になります。
年8回、対象ドメインの数だけこの作業が発生することになり、現実的な運用とは言えません。

Spelldataが構築する自動更新パイプライン

Spelldataでは、DigiCertのACME連携とCDNのAPIを組み合わせ、手作業を介さない更新の仕組みを構築します。

DigiCertのACME連携設定
CertCentralまたはTrust Lifecycle ManagerでACME用の認証情報(EAB)を発行し、ACMEクライアントからDigiCertに対して証明書を自動発行・更新できるようにします。
DigiCertのACMEは、DV・OV・EVのいずれの証明書にも対応しています。
DNS-01方式によるドメイン検証の自動化
ドメイン検証にDNS-01方式を採用し、DNSプロバイダーのAPIと連携してTXTレコードの登録・削除を自動化します。
HTTP-01方式はCDNの背後にあるオリジンサーバーへ検証リクエストが届かないことがあるため、CDN構成ではDNS-01が適しています。
ワイルドカード証明書に対応できるのも、DNS-01方式のみです。
CDNへの自動配置
更新された証明書と秘密鍵を、CloudflareのCustom Certificates APIまたはGcoreのSSL証明書APIを通じて、有効期限前に自動でアップロードします。
Cloudflareの場合、既存証明書をPATCHで更新することで、証明書枠を消費せず、切り替え時のダウンタイムも回避できます。
オリジンサーバー側の証明書対応
CDNエッジからオリジンサーバーへの通信で使う証明書も、パブリックな認証局が発行したものであれば同じく短縮ルールの対象です。
この部分も含めて、自動更新の対象に組み込みます。
オリジン証明書は棚卸しの際に見落とされやすく、更新漏れによる障害の原因になりやすい箇所です。
更新の実測監視
自動更新が正しく反映されたかを、前述のCatchpointによる実測監視で確認します。
自動化と監視を組み合わせることで、更新処理が失敗しても、障害になる前に検知できます。

まずは証明書の棚卸しから

47日対応の第一歩は、現在どこにどの証明書があるかを正確に把握することです。
社内サーバー、CDN、ロードバランサー、外部SaaSなど、証明書は組織の様々な場所に分散しています。
存在を忘れられていた証明書ほど、更新漏れによる障害の原因になります。

Spelldataでは、対象ドメインの証明書を外形から調査し、発行元の認証局、有効期限、鍵アルゴリズム、証明書チェーンの構成、CDN配下かどうかを一覧化するアセスメントをご提供しています。
現状を把握した上で、どこから自動化を進めるべきかをご提案します。

お問い合わせフォーム

証明書の運用監視や自動更新のご相談、お見積り、事例についてなど、お気軽にお問い合わせ下さい。

➡ サービス、製品に関するお問い合わせ