証明書の期限切れリスクとは？一覧取得・棚卸し・監視の進め方

証明書期限切れで何が起きるか

証明書期限切れが起きると、ユーザーはまずブラウザ警告に直面します。B2B サービスでは、それだけで問い合わせが急増し、社内では『障害なのか設定ミスなのか』の切り分けが始まります。認証情報そのものが漏れるわけではなくても、顧客は正規サイトかどうか判断できなくなり、ブランド信頼は大きく傷つきます。

OWASP TLS Cheat Sheet は、全ページで TLS を使うこと、正しいドメイン名を使うこと、wildcard 証明書の扱いを慎重に考えることを求めています。これは裏を返すと、証明書運用が止まると公開面全体の信頼性が落ちるということです。証明書期限切れはインフラ担当だけの問題ではなく、事業継続の問題 として扱うべきです。

証明書棚卸しのやり方

期限日だけでなく SAN と管理責任者も見る

棚卸しで最初に見るのは expiry ですが、それだけでは不十分です。SAN に不要なサブドメインが残っていないか、wildcard でどこまでカバーしているか、誰がその証明書の管理責任者なのかを合わせて持つ必要があります。期限日だけを管理すると、『更新はしたが不要資産が残る』という別の問題を見落とします。

一覧取得は外部観点で確認する

証明書棚卸しは CA の管理画面だけでは完結しません。実際にインターネットへ出ている公開面に、どの証明書が提示されているかを外部観点で確認する必要があります。Cloudflare が CT Monitoring を提供しているのも、証明書発行が外部露出の重要な手掛かりだからです。

証明書期限切れ監視を自動化しないと危ない理由

2025 年 1 月、Let's Encrypt は有効期限通知メールの提供終了を案内しました。つまり『CA がメールで教えてくれる』前提は、もう安全策として弱いです。実際の運用では、担当交代、共有メールボックスの放置、委託先任せなどで通知は簡単に見落とされます。

だからこそ、自動監視が必要です。証明書は一定期間ごとに必ず問題になるため、運用ルールで人の注意に依存しない形へ寄せるべきです。外部観点の監視と内部の更新計画を両方持つことで、通知漏れと露出漏れの両面を抑えられます。

証明書の期限切れを何日前から監視するか

実務では「30日前に担当確認」、「14日前に更新作業」、「7日前に再確認」、「3日前にエスカレーション」のように複数の閾値を持つと安定します。期限切れリスクは「前日まで大丈夫」ではなく、管理責任者不明や委託先調整が必要になった時点で急に重くなるためです。

wildcard や SAN が多い証明書は影響範囲が広いので、単一ドメイン証明書より早めに追う方が安全です。期限監視の設計は、「何日前から気づくか」と「誰に戻すか」の2つで決まります。

SAN / wildcard での注意点

wildcard 証明書は便利ですが、影響範囲が広いため、失効や更新漏れの被害も広がります。SAN にも同じことが言えます。便利だからまとめるのではなく、運用責任と更新責任が同じ単位でまとまっているかを確認してください。用途も管理責任者も違う資産を一枚の証明書へ詰め込むと、更新時の判断が難しくなります。

また、SAN に残る古い名前は、サブドメイン棚卸し の重要なヒントです。台帳にないサブドメインが証明書に残っていれば、公開面の整理が追いついていないサインです。証明書棚卸しは、公開資産棚卸しの一部として扱うのが自然です。

自動更新でも油断できないケース

自動更新があっても、DNS 検証に失敗する、ロードバランサへ新証明書が反映されない、古いサブドメインだけ別証明書のまま残る、といった理由で事故は起きます。つまり「自動更新がある = 監視不要」ではありません。

さらに、委託先が証明書更新を担っている場合は、管理責任者と連絡経路が曖昧だと自動更新失敗に気づきにくくなります。証明書管理は仕組みだけでなく、責任分界も含めて設計してください。

証明書棚卸しの月次レビュー

月次レビューでは、「30日以内に期限が来る証明書」、「管理責任者不明の証明書」、「SAN に台帳未登録の名前がある証明書」、「自動更新失敗の兆候がある証明書」を固定項目にすると運用しやすくなります。証明書の件数より、誰が引き取るかが曖昧なものを先に潰す方が事故を減らせます。

ここで見つかった差分は、外部公開資産台帳 や 月次レポート に戻してください。証明書棚卸しを単独タスクにせず、公開資産レビューの一部として回すと続きやすくなります。

ASM診断 PRO での確認ポイント

ASM診断 PRO は外部観点に DNS、HTTP、TLS を確認するため、証明書期限切れや関連露出を見直す入口として使いやすくなっています。証明書の情報を単独で見るだけでなく、どのドメイン・サブドメインが現実に外へ出ているかを合わせて追うことで、更新対象の優先順位付けがしやすくなります。

まずは重要ドメインを無料診断し、証明書まわりの露出と台帳の差分を確認してください。運用イメージは 機能解説 も参照すると掴みやすくなります。そのうえで管理責任者と更新ルールを整えれば、期限切れは『たまたま起きる事故』ではなく、『防げる運用課題』へ変わります。

よくある質問（FAQ）

証明書は何日前から追えばよいですか

目安は 30 日前からです。影響範囲が広い証明書や委託先依存の証明書は、さらに前倒しで確認した方が安全です。

Let's Encrypt を使っていれば安心ですか

安心とは言えません。自動更新やメール通知に依存せず、実際に外へ提示されている証明書を継続確認する必要があります。

証明書棚卸しとサブドメイン棚卸しは別でやるべきですか

別作業でも構いませんが、SAN や wildcard の観点で重なるため、同じ月次レビューで扱う方が効率的です。

wildcard 証明書は効率的ならまとめるべきですか

安易にまとめるべきではありません。wildcard は更新漏れや失効時の影響範囲が広く、用途や管理責任者が違う公開面を一枚へ詰め込むと判断が難しくなります。運用責任が同じ単位でまとまっているかを先に確認してください。

期限切れ通知メールだけで運用してもよいですか

不十分です。2025 年以降は CA の通知メールへ依存しにくくなっており、共有メールボックスや委託先任せの体制では見落としも起きやすいです。外部観点の監視と更新ルールを組み合わせて、人の注意力だけに頼らない運用へ寄せてください。

まとめ

証明書の期限切れは、単なる更新漏れではなく、公開面の信頼性と業務継続を同時に揺らす事故です。expiry だけでなく、SAN、wildcard、管理責任者、外部観点で見た提示状態まで含めて棚卸しすると、実害に直結する差分を早く見つけられます。

まずは 30 日前からの監視ルールを決め、管理責任者不明の証明書を月次レビューで潰してください。通知メールに依存せず、公開面の TLS 状態を継続監視できれば、証明書期限切れはかなり防ぎやすくなります。