SSL証明書の期限切れは、ブラウザに警告が出るだけの小さな表示問題ではありません。ECサイトの決済、会員ログイン、モバイルアプリのAPI、取引先との接続が同時に失敗することがあります。自動更新を設定していても、DNS検証の失敗、権限の変更、ジョブの停止、ロードバランサーへの反映漏れ、別ホストの見落としが起きます。日本の企業サイトでは、本番、検証、問い合わせ、採用、自治体向け連携など複数のホスト名を持つことが多く、代表ドメインだけを見ても十分ではありません。監視の目的は「期限が近い」と知らせることだけでなく、正しいホストに正しい証明書が返っているかを、担当者が行動できる形で知らせることです。
有効期限以外に見るべき項目
まずnotBeforeとnotAfterを確認し、残り日数を計算します。しかし期限内でも、証明書の名前が対象ホストと一致しなければ利用者は警告を受けます。SANに必要なwww、API、サブドメインが含まれているか、ワイルドカードの範囲が意図どおりかを確認してください。発行者、署名アルゴリズム、公開鍵、失効情報、サーバーが返す中間証明書も重要です。証明書そのものが有効でも、サーバーがチェーンを正しく返さないと一部のクライアントだけが接続に失敗することがあります。監視結果では、期限切れ、名前不一致、チェーン不備、接続失敗を別の状態にします。ひとつの「SSLエラー」にまとめると、修正担当者が判断できません。
- 対象ホスト名とポート
- 有効開始日と有効期限
- SANとワイルドカードの範囲
- 発行者と公開鍵の情報
- 中間証明書を含むチェーン
- TLS接続と失効確認の状態
- 確認時刻と前回との差分
監視対象を漏れなく作る
監視台帳の起点はドメイン名だけにしません。DNSのA、AAAA、CNAME、MX、アプリの設定、API仕様書、証明書のSAN、外部サービスのコールバックURLからホスト名を集めます。対象ごとに本番か検証か、社外公開か、事業影響が高いか、担当チームはどこかを記録します。検証環境の証明書も、取引先や開発者が使うなら期限切れが作業を止めます。一方、使われていない古い名前を永遠に監視すると通知が増えます。最初に発見したホストをすべて本番扱いせず、所有者に確認して優先度を決めてください。日本語ドメインでは表示名とASCII表現を両方台帳に残し、同じ対象の重複監視を避けます。
通知しきい値を運用に合わせる
通知は30日前だけに頼らず、計画、警告、緊急の段階を設定します。たとえば90日前に所有者と更新方法を確認し、30日前に作業チケットを作り、14日前に責任者へ知らせ、7日前に未対応ならエスカレーションする設計です。実際のしきい値は証明書の種類、承認プロセス、リリース頻度によって変わります。毎回同じ通知を送るのではなく、状態が変わったとき、残り日数がしきい値を下回ったとき、更新後に新しい期限を確認できたときに通知します。通知には対象ホスト、現在の期限、残り日数、検出状態、担当者、チケット番号、次の行動を含めます。期限切れだけでなく、名前不一致やチェーン不備は即時に扱うことがあります。
自動更新を過信しない
Let's Encryptなどの自動更新は便利ですが、更新ジョブが成功したことと、利用者が新しい証明書を受け取ることは別です。ロードバランサーの片方だけが古い証明書を返す、CDNの設定が更新されない、検証用DNSレコードを消してしまう、証明書を置き換えた後にプロセスを再読み込みしていない、といった問題が起きます。更新処理のログだけで完了とせず、外部から対象ホストに接続して期限とSANを確認します。更新前後で証明書のフィンガープリントが変わる場合は、予定された変更かを記録します。自動更新の権限や秘密情報を監視レポートに出さず、担当者が安全に再実行できる手順を別に管理してください。
日本の法人運用で起きやすい抜け
本社サイトだけを管理し、子会社、採用、問い合わせ、会員ページ、取引先接続用のサブドメインを別チームが持っているケースは珍しくありません。合併やサービス終了でDNSだけ残り、証明書の更新担当が不明になることもあります。証明書の期限監視を資産管理や変更管理と結び付け、ドメイン、ホスト、業務責任者、技術担当を一つの台帳に整理します。外部委託先が更新する場合も、期限切れ時の連絡先と復旧手順を契約や運用資料で確認します。検証環境の変更が本番証明書に影響しないか、ワイルドカードを広く使いすぎていないかもレビューします。監視結果を日本語で表示するだけでなく、担当者が実際に対応できる役割分担を決めることが重要です。
APIで複数ドメインを管理する
数十以上のホストを手作業で確認するなら、APIで結果を台帳やチケットに取り込みます。入力には対象ホスト、ポート、環境、担当者IDを持たせ、出力には期限、残り日数、名前一致、チェーン、ステータス、確認時刻を保存します。DNS障害や接続タイムアウトを期限切れと同じ扱いにしないでください。部分的な結果やunknownをそのまま残し、再確認の対象にします。DomScanのSSLチェッカーとSSL Gradeで単一ホストを確認し、SSL有効期限APIで複数対象を扱う流れが実務的です。導入前にレスポンス項目、利用上限、クレジット、キャッシュの有効期間を確認し、監視そのものが止まったときの運用も決めておきます。
{
"hostname": "api.example.jp",
"checked_at": "2026-09-14T09:00:00Z",
"days_remaining": 42,
"name_match": true,
"chain": "valid",
"status": "warning",
"owner": "platform-team"
}期限監視の成功は、アラートを出した数ではなく、障害になる前に更新または修正できたかで判断します。毎月、監視対象の棚卸し、所有者の確認、誤検知、通知の到達性をレビューしてください。証明書が交換された後に新しい期限が取得できたかを確認し、古い警告を閉じる条件も決めます。ドメインの有効期限、DNS変更、証明書期限を別々の観測として管理すれば、原因を誤りにくくなります。期限切れを完全に予測する魔法ではなく、公開サービスの状態を繰り返し確認し、担当者が早く動ける仕組みとして設計するのが現実的です。