概要
長年運用してきた HTTPS サイトにおいて、Chrome のみで証明書検証エラーが発生する事象が確認されました。他の主要ブラウザ（Firefox、Safari 等）では同様のエラーは発生していませんでした。
本事象は、サーバー側の証明書チェーン設定と、各ブラウザが実装している AIA（Authority Information Access）補完機能の挙動差が原因で顕在化したものです。本稿では、事実関係と技術的な因果関係のみを整理します。
システム構成
- リバースプロキシ: Apache（SSL 終端）
- サーバー証明書: JPRS 発行（ドメイン認証型 DV）
- サーバー証明書（leaf）の issuer: JPRS Domain Validation Authority – G4
発生していた状態
障害発生時、Apache がクライアントへ提示していた証明書チェーンは以下の構成でした。
- サーバー証明書（issuer = G4）
- 中間証明書: JPRS Domain Validation Authority – G3
本来、issuer が G4 のサーバー証明書に対しては G4 の中間証明書を明示的に提示する必要があります。しかし実際には G4 が含まれておらず、代わりに既に失効している G3（2021-03-15 失効） が設定されていました。
この構成は、仕様上正しい証明書チェーンとは言えません。
なぜ長期間問題にならなかったのか
多くのブラウザは、以下のような補完的な動作を実装しています。
- AIA 情報を用いた中間証明書の自動取得
- 過去に取得した中間証明書のキャッシュ利用
- OS 依存の証明書ストアや検証ロジック
これらの機能により、サーバーが不完全な証明書チェーンを返していても、表面的には問題なく通信できているように見える状態が成立していました。
その結果、
- 稀に証明書エラーが発生する
- キャッシュ削除や時間経過で自然に復旧する
といった不安定な挙動が断続的に発生していましたが、恒常的な障害としては認識されにくい状態でした。
なぜ Chrome のみで問題が顕在化したのか
Chrome では近年、証明書検証の実装と運用方針が段階的に変更されています。
主なポイントは以下の通りです。
- サーバーが提示する証明書チェーンの完全性をより重視する方向へ移行
- AIA（Authority Information Access）による中間証明書の自動補完に対する依存度の低下
- 中間証明書の不整合や失効に対する検証条件の厳格化
これらの変更により、従来はクライアント側の補完機能によって成立していた不完全な証明書チェーンが、Chrome では検証エラーとして扱われるようになったと考えられます。
一方で、Firefox や Safari などの他ブラウザでは、引き続き中間証明書のキャッシュや OS 依存の補完処理が有効であったため、結果として Chrome のみで問題が先行して顕在化する状況となりました。
なお、この挙動の変化は単一のバージョンで突然発生したものではなく、Chrome の更新に伴って徐々に進行してきたものと考えられます。そのため、特定の時点でのみ不安定な挙動が観測されるなど、再現性の低い状態が長期間続いていた可能性があります。
実施した対応
Apache の証明書設定を見直し、以下の順序で完全な証明書チェーンを明示的に提示するよう修正しました。
- サーバー証明書（leaf）
- JPRS Domain Validation Authority – G4（中間証明書）
修正後、以下のコマンドで検証を行い、正常性を確認しています。
openssl s_client -connect example.com:443 -servername example.com -verify_return_errorVerify return code: 0 (ok)これにより、Chrome を含むすべての主要ブラウザで正常に通信できることを確認しました。
教訓
本件から得られる教訓は以下の通りです。
- サーバー証明書の有効期限だけでなく、中間証明書の有効期限およびチェーン構成を正しく管理する必要がある
- ブラウザや OS の補完機能に依存した構成は、挙動変更により突然問題が顕在化する
- サーバー側で常に完全かつ正しい証明書チェーンを提示することが前提である
証明書検証における補完的な動作は、設定不備を一時的に覆い隠すことはできますが、問題を解消するものではありません。運用上は、明示的かつ仕様通りの設定を維持することが重要です。
