証明書チェーンが不完全なのはなぜ？中間証明書を確認して直す方法

ブラウザでは開けるのに、curl、Java のサービス、モバイルアプリでは信頼チェーンを構築できないと言われる。そこで証明書を再発行しても、たいていは解決しません。サーバーが中間証明書を送っていないか、配備したつもりのものとは別のチェーンを返していることが多いためです。

証明書は単独のファイルではありません。クライアントはサイトのリーフ証明書から中間 CA を経て、自分の信頼ストアにあるルート証明書までの経路を作る必要があります。途中が欠けている、チェーン内の証明書が期限切れ、公開入口が私設 CA を返している、といった状態はいずれも経路を壊します。PEM を見る前に、公開ハンドシェイクを確認してください。

実際のホスト名、ポート、SNI を指定して SSL チェッカーを使います。これは「サーバーがチェーンを完全に送ったか」と「公開クライアントがそのチェーンを信頼できるか」を別々に示します。似ていますが、同じ判定ではありません。

不完全な証明書チェーンとは何が欠けた状態か

公開 HTTPS の一般的なチェーンでは、サイトの証明書は中間 CA によって発行され、中間 CA は信頼済みルート CA につながっています。ルート証明書は通常、OS やブラウザの信頼ストアに入っているため、サーバーが送るのはリーフと必要な中間証明書です。ルートまで送る必要はありません。

チェーンが不完全とは、クライアントが経路を作るために必要な中間証明書をサーバーが送っていない状態を指すことがほとんどです。リーフだけから完全な経路を確実に推測することはできません。ある環境には必要な中間証明書がキャッシュされていて、別の環境にはないことがあります。端末ごとに結果が違う理由の一つです。

「送られていない」と「信頼できない」を分ける

この二つは関連しますが、診断は別です。

したがって、fullchain を配備すればすべてのチェーンエラーが直るわけではありません。中間証明書の欠落には有効ですが、私設 CA を公開信頼に変えたり、チェーン内の期限切れを直したりはできません。

ディスク上のファイルを公開ハンドシェイクの代わりにしない

アプリケーションサーバーに正しい fullchain.pem があっても、利用者がそれを受け取っているとは限りません。TLS は CDN、ロードバランサー、Ingress、リバースプロキシ、ホスティング基盤で終端していることがあります。バックエンドだけを更新して、公開側を更新していないこともあります。

公開結果から、リーフのシリアル番号または SHA-256 フィンガープリント、返された中間証明書、解決先 IP、使われた SNI を控えます。書き出したチェーンは 証明書デコーダーに入れ、Subject、Issuer、有効期間、フィンガープリントを 1 枚ずつ見ます。前の証明書の Issuer と次の証明書の Subject がつながることは経路の手掛かりですが、最終的な信頼判定はクライアントまたはチェッカーに任せます。

公開先のリーフのフィンガープリントから違うなら、中間証明書を調べ続けないでください。違う入口を見ているか、古いノードに流れている可能性が高いです。

ブラウザだけ通り、curl、Java、アプリが失敗する理由

ブラウザで開けることは、配備が正しい証拠ではありません。ブラウザ環境には必要な中間証明書がすでにキャッシュされている、または独自の方針で補える場合があります。一方、コマンドラインのクライアント、ランタイム、組み込み機器、アプリはそうとは限りません。ルートストア、チェーン構築、ネットワーク制限も違います。

「自分の PC では開ける」で判断せず、失敗したクライアントで同じ公開ホスト名を再試行し、完全なエラーを残します。社内ネットワーク、ホテルの Wi-Fi、セキュリティソフトを入れた端末だけで失敗するなら、独自証明書を返す HTTPS 検査プロキシも疑います。

fullchain に含めるもの

製品によって certificate chain、bundle、full certificate chain など呼び方は違いますが、原則は同じです。実際に TLS を終端するコンポーネントに、サイト証明書と公開ルートへ到達するために必要な中間証明書を渡します。

• fullchain は通常、最初にリーフ証明書、その後に一つ以上の中間証明書を置きます。
• 秘密鍵は別に設定します。証明書チェーンへつなげず、オンラインサービスにも貼り付けません。チェーンの調査に必要なのは証明書だけで、本サイトのデコーダーもブラウザ内で動作します。
• 公開ルート証明書は通常サーバーから送る必要がありません。むやみに追加しても欠けた中間証明書の代わりにはなりません。
• 同じ CA に見えるというだけで別の中間証明書を使わないでください。発行チェーンと鍵識別子が対応している必要があります。

配備後は実際の TLS 終端を再読み込みし、公開先からもう一度確認します。ローカルポートや設定ファイルだけでは、前段プロキシや別ノードを見落とします。

もっともらしいが遠回りになる対処

ルート証明書を末尾に足す、リーフを何度も再発行する、ブラウザだけで試す、といった対処はよくある遠回りです。ルートは欠けた中間証明書の代わりにならず、再発行しても古い CDN やロードバランサーの設定は変わりません。ブラウザが通るのは、その端末の状態が偶然よいだけかもしれません。

複数のクロス署名された中間証明書を適当に連結するのも危険です。長いチェーンがよいチェーンとは限りません。CA または証明書基盤がそのリーフ用に示したチェーンを使い、ファイル名ではなく公開ハンドシェイクで検証してください。

更新後も断続的なら、すべての入口を確認する

一部の要求だけでチェーンエラーが出るなら、クライアントの運より構成を疑います。IPv4 と IPv6 が別サービスを指す、1 台だけ更新から漏れる、CDN エッジに古い設定が残る、ヘルスチェックに正しい SNI がない、といった原因があります。

一度のチェックで得たアドレスは一つの観測にすぎません。DNS ルックアップでそのホスト名の A と AAAA をすべて洗い出し、アドレス、ポート、ホスト名の組み合わせごとに確認し、可能なら意図した SNI の有無でも比較します。古いチェーンを返す入口は、修正するかトラフィックから外す必要があります。

短くても抜けない確認順序

1. SSL チェッカーで公開ホスト名を確認し、実際のポートと SNI を指定する。
2. 「チェーンが完全に送られたか」と「チェーンが信頼できるか」を別々に記録し、すべてを中間証明書の欠落と決めつけない。
3. 公開先のチェーンを取り出し、証明書デコーダーでリーフ、発行者、日付、フィンガープリントを確認する。
4. 実際の TLS 終端を見つけ、CA が示した fullchain を配備してサービスを再読み込みする。
5. IPv4、IPv6、CDN、すべての負荷分散ノードを確認し、どの入口でも期待するチェーンが返るようにする。
6. 最初に失敗したクライアントで再試行する。チェーンが完全でも信頼できないなら、私設 CA、チェーン内の期限切れ、ローカルの HTTPS 検査を調べる。

チェーンが通っているのにホスト名不一致が出るなら、中間証明書を変え続ける必要はありません。次は SAN、SNI、経路の問題です。SSL 証明書とドメインが一致しない理由を参照してください。全体の判断順序はSSL 証明書が無効になる理由にあります。