SSL 証明書が無効になる理由と、順序立てた切り分け方
ブラウザの証明書警告は、証明書ファイルだけの問題とは限りません。有効期限、SAN、信頼チェーン、中間証明書、SNI、TLS、DNS を順に確認して原因を切り分けます。
ブラウザが「接続はプライベートではありません」と表示したり、監視が証明書エラーを出したりすると、すぐに証明書を再発行したくなります。しかし、再発行しても直らないことは少なくありません。
HTTPS では、正しい名前に対して正しい証明書を返すこと、有効期間内であること、クライアントが信頼できるまでの中間証明書を送ること、互換性のある TLS 接続を確立することがすべて必要です。サーバー上のファイルが新しくても、公開エンドポイントが古い証明書や別サイトの証明書を返していることがあります。
まず SSL チェッカーで公開ホストを確認してください。有効期限、名前の一致、信頼、送信された証明書チェーン、TLS バージョンを別々に示します。「証明書が無効」という一つの言葉にまとめないことが、最短の切り分けになります。
最初に、クライアントが実際に接続する先を見る
サーバー上の PEM ファイルではなく、公開ホスト名を入力します。443 以外なら実際のポートも指定します。IP に直接接続して仮想ホストを調べるときは、期待するホスト名を SNI に指定してください。
設定を変える前に、次の四点を控えます。
| 確認項目 | 分かること | 失敗が示しやすいこと |
|---|---|---|
| 有効期間 | 今日この証明書を使えるか | 期限切れ、まだ有効でない、端末時計の異常 |
| 名前の一致 | 要求した名前を証明書がカバーするか | SAN の不足、別の仮想ホストへの到達 |
| チェーンの信頼 | 公開クライアントが信頼済みルートまでたどれるか | 中間証明書不足、私設 CA、通信の介入、未信頼の発行者 |
| チェーンの送信 | サーバーが必要な中間証明書を送ったか | 中間証明書の不足、またはチェーン上の信頼・有効期間の問題で構築できない |
有効期限、名前、信頼は別問題です。期限切れの証明書でも名前は正しく一致し得ますし、有効な証明書が別ドメイン用であることも、ブラウザだけがキャッシュ済み中間証明書で不足を補っていることもあります。
エラー名から、最初に見る場所を決める
表記はブラウザごとに違いますが、次は役に立つ入口です。
| エラーの例 | まず疑う層 | 最初の確認 |
|---|---|---|
NET::ERR_CERT_DATE_INVALID | 有効期間または端末時計 | notBefore、notAfter、端末時刻 |
NET::ERR_CERT_COMMON_NAME_INVALID | 名前のカバー範囲または SNI | SAN と実際のホスト名 |
NET::ERR_CERT_AUTHORITY_INVALID | 信頼チェーンまたは端末側の介入 | 発行者・中間証明書・別ネットワークでの再現 |
NET::ERR_CERT_REVOKED | 失効状態 | シリアル番号に対する CA の失効状態と、新しい証明書の配備状況 |
ERR_SSL_VERSION_OR_CIPHER_MISMATCH | TLS のネゴシエーション | TLS バージョン、プロキシ、サーバー設定 |
これは断定ではありません。ERR_CERT_AUTHORITY_INVALID は中間証明書の不足だけでなく、社内の TLS 検査プロキシ、セキュリティソフト、ホテル Wi‑Fi の認証ポータルでも起こります。まず別の独立したネットワークから試し、全体障害か端末固有かを分けます。
なお mixed content は別問題です。HTTPS のページが HTTP の素材を読み込んでいるだけなら、証明書を差し替えても直りません。
期限切れは、更新失敗と同義ではない
公開ホストが期限切れ証明書を返しているなら、まず notAfter を読み、シリアル番号か SHA-256 フィンガープリントを、配備したつもりの証明書と比べます。認証局での更新が成功しても、稼働中の入口が古いファイルを返し続けることはよくあります。
よくある原因は次のとおりです。
- TLS を実際に終端しているのがアプリではなく CDN、ロードバランサー、Ingress、リバースプロキシである。
- 複数ノードの一部だけがリロードされず、症状が断続的に出る。
- 更新ジョブは新しいファイルを書いたが、Web サーバーを再読み込みしていない。
- IPv4 は更新済みでも IPv6、旧 IP、ステージング環境へまだ名前が向いている。
チェッカーの解決先 IP を控え、DNS ルックアップで A と AAAA、TTL を確認します。両方のアドレス族を見るのが重要です。自分だけ正常なのは、更新済み IPv4 を優先しただけかもしれません。
失効と期限切れは別の問題
有効期間内の証明書でも失効していることがあります。NET::ERR_CERT_REVOKED は、クライアントが得た失効情報に基づき証明書を信頼しなくなったことを示し、notAfter の誤りとは別です。SSL チェッカーは OCSP stapling の提示を表示できますが、失効状態そのものは検証しません。失効情報の取得方法やキャッシュの扱いはクライアントごとに異なります。
まずシリアル番号で CA の状態を確認します。CA が失効を確認したなら、直ちに証明書を再発行して実際の TLS 終端へ配備し、秘密鍵漏えい、誤発行、ドメイン管理の変更など原因を調べます。CA が失効を確認していないのに特定のクライアントだけが警告する場合に限り、その端末環境と OCSP stapling 設定を確認します。
ホスト名の対象は Common Name ではなく SAN
現代のクライアントは Subject Alternative Name（SAN）で名前を検証します。Common Name は表示されても、対象範囲の判断には使わないでください。
公開先から得たリーフ証明書を 証明書デコーダーで開き、DNS SAN を要求名と一つずつ照合します。
example.comとwww.example.comは別の名前です。*.example.comはapi.example.comをカバーしますが、example.comやv2.api.example.comはカバーしません。- IP アドレスでアクセスするなら、DNS SAN ではなく対応する IP SAN が必要です。
- 内部名向けの証明書を、そのまま公開名に使えるわけではありません。
SAN が正しいのに不一致なら、経路を疑います。IP 直結時に期待する SNI を渡さなければ、サーバーは既定サイトの証明書を返すことがあります。名前で振り分けるプロキシでも、想定と違う SNI を受ければ同じことが起きます。
中間証明書の不足と、ルート不信頼を混同しない
通常サーバーが送るのはリーフ証明書と一枚以上の中間証明書です。ルート証明書は送らず、クライアント側の信頼ストアにあるルートまで中間証明書をたどります。
CA から渡された fullchain.pem ではなく cert.pem だけを設定するのは典型的な事故です。ブラウザが AIA から中間証明書を取得したり、キャッシュを使ったりして開ける場合がありますが、CLI、モバイルアプリ、古い端末、制限された企業環境は補完しないことがあります。これが「自分のブラウザでは開けるのに顧客は開けない」理由です。
SSL チェッカーは、チェーンが信頼されるかと、サーバーが完全なチェーンを送ったかを分けて表示します。後者の失敗は中間証明書不足が多い一方、チェーン内の別の証明書が期限切れ、または未信頼でも起こり得ます。何かを追加する前に、送られた各証明書を確認してください。リーフが正しく中間証明書だけが足りなければ、実際の TLS 終端に完全なチェーンを設定します。適当なルート証明書を追加するのは解決になりません。
証明書より先に SNI を疑う場面がある
一つの IP で多数の HTTPS 名を扱えます。TLS ハンドシェイクの SNI は、クライアントがどの名前の証明書を期待するかを知らせる値です。正しい SNI がなければ、サーバーは既定の証明書を返します。それはプロトコル上は正しくても、訪れたい名前には間違っています。
CDN、共有ロードバランサー、Kubernetes Ingress へ移した直後や、IP だけへ接続する監視で起きやすい問題です。IP だけにつなぐ監視は、ブラウザとは別の要求を試していることになります。
同じ IP に対し、SNI なしと本番ホスト名を入れた場合を比較してください。証明書が変わるなら、要求や到達したノードによって証明書の選択が変わっています。仮想ホストがよくある理由ですが、負荷分散でもこの差は起こり得ます。SNI を付けたときだけ誤った証明書なら、その名前のルーティング設定を調べます。
DNS は、誤った TLS 入口へ利用者を送る
DNS は証明書を検証しませんが、誰に証明書を尋ねるかを決めます。移行時は A、AAAA、CNAME を確認し、CDN やホスティングへ続く CNAME も追います。TTL が低くても、すべてのキャッシュの古い答えが即座に消えるわけではありません。
CAA は発行・更新には関係しますが、ブラウザによる既発行証明書の検証には関係しません。更新できないなら CAA を、名前不一致なら A、AAAA、CNAME、CDN の向き先、SNI を先に調べます。
一台だけで起きるなら、端末側も調べる
外部からの確認が正常で、一人だけが警告を見るなら、その端末やネットワークの差を確認します。
- 時刻とタイムゾーンが大きくずれていないか。
- 別ネットワークでも再現するか。認証ポータル、企業の TLS 検査、セキュリティ製品が別の証明書を返すことがあります。
- 古い OS や組み込み機器のルートストアが新しいチェーンを信頼できるか。
- IP、旧ホスト名、内部別名を入力していないか。
ログイン、決済、管理画面の警告を「そのまま進む」で回避させないでください。なぜそのクライアントだけが別の証明書や未信頼の証明書を見ているのかを先に確かめます。
迷わない確認順序
- SSL チェッカーで公開ホストを確認し、必要ならポートと SNI を指定する。
- 日付、名前、信頼、送信チェーン、TLS のどこが失敗しているかを分ける。失効はブラウザのエラーと CA の状態で判断し、SSL チェッカーだけでは判定しない。
- 証明書デコーダーで公開先から得た証明書チェーンをデコードし、SAN、発行者、日付、シリアル番号、フィンガープリントを配備予定のものと比べる。
- 移行や更新が絡むなら DNS ルックアップで A、AAAA、CNAME、CAA を確認する。
- 誤った証明書を送っている TLS 終端を直し、再読み込みまたは再配備する。
- 公開先で再確認し、複数ノードならすべてのアドレスが期待どおりかを見る。
この順序なら、証明書を何度も作り直して偶然直るのを待つ必要はありません。原因が証明書そのもの、チェーン、名前、経路、クライアントのどこにあるのかを、先に確定できます。
公開チェックでチェーンの問題が見つかったら、証明書チェーンが不完全な理由へ進んでください。証明書は信頼できるのに要求名をカバーしない場合は、SSL 証明書とドメインが一致しない理由を確認します。