【ITニュース解説】Catch an Expired Certificate Before Your Client Hears “Your Website Is Unsafe”

ウェブサイトを訪れた時、「接続はプライベートではありません」という警告画面が表示された経験はないだろうか。この警告は、そのウェブサイトが安全ではない可能性を示唆しており、利用者に不安を与える。システムエンジニアとして、このような事態は絶対に避けたいものだ。なぜなら、これはウェブサイトの信頼性を損ない、顧客に多大な不利益をもたらすからだ。

この警告の主な原因は、ウェブサイトが利用しているSSL/TLS証明書が期限切れになっていることにある。SSL/TLS証明書は、ウェブサイトと訪問者の間の通信を暗号化し、第三者による盗聴や改ざんを防ぐ役割を果たす。さらに、そのウェブサイトが本当に運営者によって管理されていることを証明する、いわば「ウェブサイトの身分証明書」のようなものだ。この証明書が期限切れになると、ブラウザはウェブサイトの身元を確認できなくなり、安全な接続が保証できないと判断して警告を表示するのだ。

かつて、SSL/TLS証明書は比較的長い有効期間を持っていたが、これは変化しつつある。2026年3月15日以降、公開された認証局（Certificate Authority, CA）が発行するTLS証明書の有効期間は200日を超えることはなくなる。そして2027年3月には100日、2029年3月には47日へとさらに短縮される予定だ。これは、Apple、Google、Microsoft、Mozillaといった大手企業が参加するCA/Browser Forumという団体が、ウェブのセキュリティを強化するために決定したことだ。証明書の有効期間を短くすることで、もし証明書が盗まれたり、誤って発行されたりした場合でも、その悪用できる期間が短くなり、被害を最小限に抑えることができる。これは、ブラウザでの証明書失効機能が十分に機能していないという背景も踏まえている。

証明書の有効期間が短くなると、システムエンジニアにとって、これまで以上に頻繁な証明書の更新が必要になる。例えば、47日間の証明書であれば、1年に8回も更新作業が発生する計算だ。これほど頻繁な作業を手作業で行うのは現実的ではなく、ほとんどのシステムでは自動更新の仕組みが導入されているはずだ。しかし、この自動更新の仕組みが、静かに、そして気づかれないうちに失敗してしまうという問題が浮上してくる。

自動更新が失敗する典型的なケースはいくつか考えられる。まず、「自動化ジョブが動いていない」場合だ。サーバーを再構築した際に、証明書の更新を担当するプログラム（cronジョブやsystemdタイマーなど）の設定が引き継がれなかったり、コンテナイメージを再構築した際に証明書更新クライアント（ACMEクライアント）が組み込まれていなかったりすると、そもそも更新処理自体が実行されない。この場合、何もエラーログが出力されないため、システム管理者も問題に気づきにくい。

次に、「証明書は更新されたが、サーバーが古いものを表示し続けている」ケースだ。ACMEクライアントが新しい証明書ファイルをディスクに保存しても、ウェブサーバー（Nginx、Apacheなど）やロードバランサー、メールサーバー（Postfixなど）が、メモリ上に古い証明書を保持し、再起動されない限りそれを使い続けることがある。更新ログには「成功」と記録されるため、これも問題が見えにくい。

さらに、「間違ったマシンで更新された」という問題もある。例えば、ウェブサイトへのアクセスを分散させるロードバランサーやCDN（コンテンツデリバリーネットワーク）を利用している場合、アクセス元となるエッジサーバーやキャッシュサーバーにも証明書が必要となる。もし、元のサーバー（オリジンサーバー）でしか更新が行われず、これらの外部サービスや複数台のウェブサーバーに新しい証明書が配布されなかった場合、利用者は古い、あるいは期限切れの証明書を受け取ってしまうことになる。

「チャレンジ（認証）が失敗する」こともよくある。証明書を発行する認証局は、申請者が本当にそのドメインの所有者であることを確認するために、いくつかの「チャレンジ」を行う。例えば、特定のファイルをウェブサーバーに置かせたり、DNSレコードを変更させたりする。しかし、ファイアウォールの設定変更でポート80がブロックされたり、DNSのAPIトークンが変更されたり、あるいはCAAレコード（証明書の発行を許可する認証局を指定するDNSレコード）に誤りがあったりすると、認証局からの検証に失敗し、証明書が発行できなくなる。証明書有効期間が短くなると、こうしたDNS関連のミスがより頻繁に問題となる。

最後に、「ドメイン検証の有効期間が切れる」ケースも挙げられる。認証局がドメインの所有権を一度検証すると、その検証結果をしばらくの間再利用できる期間がある。しかし、この期間も2029年までに10日程度まで短縮される予定だ。これにより、ほぼ毎回の更新時にドメインの所有権を再検証する必要が生じ、これまでの設定に依存していたシステムでは新たな対応が求められることになる。

これらの自動更新の失敗パターンに共通しているのは、システムの内部、つまり証明書が保存されているディスク上のファイルや、更新処理のログだけを見ていると、問題がないように見えてしまうことだ。しかし、実際に訪問者がウェブサイトにアクセスしたときにブラウザが受け取る証明書は、すでに期限切れだったり、古かったりする。問題は常に「外部から見たとき」に初めて明らかになるのだ。

そこで、これらの問題を確実に検出するための唯一の方法は、実際にブラウザがウェブサイトに接続するのと同じ方法で外部から証明書をチェックすることだ。具体的な方法としては、openssl s_client コマンドを使うのが有効だ。このコマンドは、指定したウェブサイトにSSL/TLS接続を試み、実際に提供されている証明書の中身を表示できる。

例えば、echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -issuer -serial -enddate のようなコマンドを実行すれば、www.example.com から提供されている証明書の発行者、シリアル番号、有効期限を確認できる。ここで重要なのは -servername www.example.com という部分だ。これはSNI（Server Name Indication）という仕組みで、一つのIPアドレスで複数のウェブサイトをホストしているサーバーに対して、どのウェブサイトの証明書を取得したいかを正確に伝えるために必要だ。これを指定しないと、サーバーがデフォルトの証明書を返してしまい、意図した証明書をチェックできない可能性がある。

このチェックは、証明書を更新しているマシンとは別の場所から、定期的に実行することが重要だ。また、example.com と www.example.com のように異なるホスト名や、api.、mail. といったサブドメイン、CDNの背後にあるサービスなど、HTTPSでサービスを提供している全てのホスト名に対して個別に確認する必要がある。それぞれのホスト名が異なる証明書を提供している可能性があるからだ。

警告を出すタイミングも重要になる。一般的な「期限切れ30日前に警告」という設定では、47日間の有効期間を持つ証明書の場合、ほとんどの期間で警告が出続けることになり、通知が多すぎて見過ごされがちだ。これでは本当に問題が発生したときに気づけない。より効果的なのは、自動更新が行われるタイミングから逆算して警告を設定することだ。例えば、証明書の有効期間が残り3分の1になった時点で更新されると仮定すると、47日間の証明書は残り15日程度で更新されるはずだ。そこで、最初の警告を「残り14日」に設定すれば、「更新が行われるべきだったのに、まだ完了していない」という明確なサインとなる。その後は、7日、3日、1日と、より緊急性の高い警告を出すように段階的に設定していくと良いだろう。

さらに、警告のノイズを減らす工夫もできる。新しいシリアル番号を持ち、有効期限が延長されている証明書が検出された場合は、それは正常な更新であるため、通知は行わない。一方で、新しいシリアル番号にもかかわらず有効期限が短くなっている場合は、誤った証明書がインストールされた可能性が高いので、すぐに通知するべきだ。

SSL/TLS証明書の期限切れ監視は、DNSレコードの監視やネームサーバーの監視、ドメイン登録情報の監視などと同様に、ウェブサイトの安定稼働とセキュリティ維持のために不可欠な要素だ。この監視は、ウェブサーバーが実際に提供している証明書の有効期限、発行者、キー、フィンガープリントなどを確認することに特化している。TLS設定の品質や証明書チェーンの検証については、他の専門ツールに任せるのが良い。

また、証明書の更新失敗の原因には、DNS設定の変更が関わることもある。例えば、特定の認証局からの証明書発行をブロックするCAAレコードが設定されたり、ACMEチャレンジ用のCNAMEレコードが壊れたりするケースだ。これらのDNS関連の問題も、外部からの監視によって早期に発見できる。

システムエンジニアを目指す皆さんにとって、ウェブサイトの安定稼働は最優先事項の一つだろう。今年のタスクとして、HTTPSで提供している全てのホスト名をリストアップし、それぞれの証明書が自動的に更新され、サーバーに正しく反映されているか、そして何よりも「外部から」その状態が適切に監視され、問題があればすぐに通知される仕組みを構築することをお勧めする。これが、ウェブサイトの信頼性を守り、顧客に安全なサービスを提供するための重要な一歩となるだろう。