## この記事でわかること

- 「chain incomplete（証明書チェーンが不完全）」エラーが起きる本当の原因
- fullchain（リーフ証明書 + 中間証明書を連結したファイル）を使った修復の考え方
- Nginx / Apache での直し方の方針と、SSL Labs での検証手順

## 「証明書は入れたのに不完全と言われる」のはなぜか

SSL 証明書を正しくインストールしたはずなのに、SSL Labs などのチェックツールで「Chain issues: Incomplete（証明書チェーンが不完全）」と表示される。自分の PC のブラウザでは問題なく開けるのに、一部のお客様から「サイトが安全でないと出る」「アプリからつながらない」と連絡が来る。中小企業のサイト運用でよくあるトラブルです。

原因のほとんどは、サーバが**中間証明書（リーフ証明書と root 認証局をつなぐ中継の証明書）を送り出していない**ことです。証明書ファイル自体は有効でも、サーバの設定が中間証明書を含んでいないと、受信側は信頼の連鎖をたどれず「不完全」と判定します。

中間証明書そのものの役割は[中間証明書とは何か](/blog/ssl-intermediate-certificate)で解説しています。本記事はその知識を前提に、エラーの原因から修復の考え方、検証までに絞って進めます。

## チェーンが「完全」と「不完全」の違い

証明書の検証は、サーバの証明書（リーフ）から中間証明書を経由して、受信側が最初から持っている root 認証局まで、署名の連鎖をたどることで成立します。この連鎖のどこか 1 つでも欠けると、受信側は信頼できる root までたどり着けません。

![チェーンが完全な場合と中間証明書が欠けて不完全になる場合の比較](/blog/ssl-chain-incomplete-troubleshoot/chain-complete-vs-incomplete.svg)

ポイントは、サーバが送るべきなのは「リーフ証明書 + 中間証明書」であって、**root 証明書は含めない**ということです。受信側の OS やブラウザは root を最初から内蔵しているため、サーバが root まで送ると SSL Labs では「Chain issues: Contains anchor（root を含んでいる）」という別の指摘が出ます。送るのはリーフと中間まで、と覚えておくと安全です。

### 「自分のブラウザでは見えるのに」が一番危ない

中小企業のサイトで見落とされやすい落とし穴がここです。中間証明書が欠けていても、**PC 版の主要ブラウザの多くは欠けた中間証明書を自動で取りに行って表示できてしまう**ことがあります。AIA（Authority Information Access、証明書に書かれた取得先情報）という仕組みを使い、足りない中間証明書を裏で補完するためです。

問題は、この自動補完をしない受信側が一定数あることです。スマートフォンの一部環境、各種アプリやプログラムからの通信、決済やメール配信の連携、外部の監視ツールなどは、サーバが中間証明書を送らないと**その場で接続を拒否**します。「担当者の PC では見えているから大丈夫」と判断すると、モバイルからアクセスするお客様や、API でつながる取引先システムだけが静かに弾かれ、問い合わせや受注の取りこぼし、決済連携の失敗としてビジネスに直結します。

## fullchain で直す考え方（Nginx / Apache）

修復の本質は「サーバがリーフ証明書に続けて中間証明書も送るようにする」ことです。多くの場合、これは **fullchain（リーフ証明書と中間証明書を順番に連結した 1 つのファイル）をサーバに読ませる**ことで実現します。

![エラー検出から fullchain 設定、再検証までの修復フロー](/blog/ssl-chain-incomplete-troubleshoot/repair-flow.svg)

### 並び順と root の扱い

連結の順番は「先頭にリーフ証明書、続いて中間証明書」です。中間証明書が複数ある場合も、リーフに近い側から順に並べます。root 証明書は前述のとおり含めません。

### Nginx の場合

Nginx は証明書を指定する設定項目に、**リーフと中間を連結した fullchain ファイル**を指すのが基本です。Let's Encrypt を使っている場合、リーフのみの `cert.pem` ではなく、中間まで含む `fullchain.pem` を指していないことが「不完全」の典型的な原因になります。正確な設定項目名やファイルパスは[Nginx の公式ドキュメント](https://nginx.org/en/docs/)と利用中の認証局の手順を確認してください。

### Apache の場合

Apache は 2.4.8 以降、証明書ファイルを指定する項目（`SSLCertificateFile`）に中間証明書も一緒に含める方式が標準です。中間証明書を別指定する古い項目（`SSLCertificateChainFile`）は廃止扱いになっています。バージョンや構成により記述が変わるため、設定の詳細は[Apache mod_ssl の公式ドキュメント](https://httpd.apache.org/docs/2.4/mod/mod_ssl.html)で確認してください。

サーバの種類やマネージドサービスごとに反映方法は異なります。本記事では具体的なコマンド列までは踏み込まず、「リーフ + 中間を連結したものを読ませ、root は含めない」という方針だけ押さえてください。実際の手順は各サーバ・各認証局の公式ドキュメントが最優先です。

## 修復できたかの検証方法

設定変更後は、必ず「サーバが実際に何を送っているか」を外部から確認します。設定を直したつもりでも、サービスの再起動忘れや反映遅れで送出内容が変わっていないことがあるためです。

検証の中心になるのが SSL Labs による外部チェックです。チェック結果の「Chain issues」が「None」になっていれば、中間証明書が正しく送られています。「Incomplete」が残っていれば中間が欠けたまま、「Contains anchor」が出ていれば root を入れすぎ、という具合に何を直すべきかが切り分けられます。スコアの読み方は[SSL Labs で A+ を取得する方法](/blog/ssl-labs-a-plus-shutoku)を参照してください。

SSL Labs 以外にも複数のチェック手段を併用すると安心です。手元のコマンドでサーバが返す証明書の一覧を確認する方法や、各種オンラインツールの使い分けは[SSL チェックツールの比較](/blog/ssl-check-tool-comparison)にまとめています。検証時のチェックポイントは次の 3 つです。

- チェック結果の Chain issues が「None」になっているか
- 送出されている証明書が「リーフ + 中間」で、root を含んでいないか
- PC のブラウザだけでなく、外部ツール（自動補完をしない経路）で確認したか

## よくある質問

### 証明書を再発行すれば直りますか

多くの場合、再発行は不要です。証明書ファイル自体は有効で、サーバが中間証明書を送っていないだけのことがほとんどです。まずは fullchain を読ませる設定に直すことを先に試してください。

### 中間証明書はどこで入手しますか

利用している認証局が配布しています。Let's Encrypt なら証明書発行時に中間まで含むファイルが自動で用意されます。商用認証局の場合は管理画面やメールで中間証明書（または CA バンドル）が提供されます。入手元は認証局ごとに異なるため、推測せず公式の案内に従ってください。

### 直したのにまだ不完全と出ます

サーバやサービスの再起動・再読み込みが済んでいない、複数台構成の一部だけ反映されていない、別の設定ファイルを編集していた、といった原因が典型です。再度 SSL Labs でキャッシュを使わず確認し、送出内容が変わっているかを見てください。

## まとめ

- 「chain incomplete」の主因は、サーバが中間証明書を送っていないこと
- 修復は「リーフ + 中間を連結した fullchain を読ませる」のが基本。root は含めない
- PC ブラウザは欠けた中間を自動補完することがあり、見た目では気づけない
- Nginx は fullchain を指す、Apache 2.4.8 以降は証明書ファイルに中間を含める。詳細は各サーバの公式ドキュメントへ
- 設定後は SSL Labs などの外部ツールで Chain issues が「None」になったか必ず検証する

## 自社サイトのチェーン状態を確認しませんか

自社サイトの証明書チェーンが完全に送られているか、有効期限とあわせて、ドメイン番人の[無料診断](/diagnose)で数秒で確認できます。「不完全と出るが原因が分からない」「直したつもりだが本当に直ったか不安」という場合は、[お問い合わせフォーム](/contact)から状況をお知らせください。専門家が一緒に確認いたします。