SSLセキュリティ証明書のインストール後も「安全ではありません」と表示されるのはなぜですか？

SSLセキュリティ証明書のインストール完了後も、ブラウザに「接続は安全ではありません」「証明書が無効です」と表示されたり、アドレスバーに鍵アイコンが表示されなかったりする場合、通常は証明書ファイル自体の失効ではなく、デプロイチェーンが不完全である、アクセスするドメイン名が一致しない、ページが依然としてHTTPリソースを読み込んでいる、またはサーバーでHTTPSが正しく有効化されていないことが原因です。この種の問題は訪問者のWebサイトへの信頼に影響するだけでなく、ログイン、フォーム送信、決済ページへの遷移などがブラウザによってブロックされたり、リスク警告が表示されたりする可能性があります。

調査時には、「証明書を購入済みか、アップロード済みか」だけを確認してはいけません。ブラウザが実際に取得している証明書、アクセス経路、ページリソースを基準に、まずエラーの種類を確認し、次にドメイン名、証明書チェーン、ポート、リダイレクトルールを検証し、最後に混在コンテンツを処理します。これにより、証明書を何度も差し替えても問題が解決しない事態を回避できます。

まずブラウザの表示を確認し、問題の発生層を判断する

ブラウザのアドレスバーにある「安全ではありません」の表示または鍵アイコンをクリックし、証明書の詳細と具体的なエラーメッセージを確認します。現象によって確認すべき方向は異なります。

ブラウザのコンソールも重要です。コンソールに「Mixed Content」と表示される場合は、メインページはHTTPSで開かれているものの、一部のリソースが依然としてHTTPでリクエストされていることを示します。証明書名のエラーや証明書チェーンの検証失敗が表示される場合は、サーバーのデプロイ層に戻って確認する必要があります。

ドメイン名の不一致は、SSLセキュリティ証明書のインストール後に最も見落とされやすい問題です

証明書は記載されているドメイン名に対してのみ有効であり、すべてのバリエーションを自動的にカバーするわけではありません。たとえば、証明書がwww.example.comのみに発行されている場合、example.comへ直接アクセスすると、依然としてエラーになる可能性があります。メインドメイン用に発行された通常の単一ドメイン証明書も、通常はshop.example.comやen.example.comなどのサブドメインをカバーできません。

証明書詳細の「Subject Alternative Name（SAN）」または「サブジェクト代替名」を確認し、実際のアクセス入口と一つずつ照合してください。少なくとも以下を確認します。

• wwwあり・なしのドメイン名がいずれもカバーされているか、または統一してリダイレクトされているか。
• 多言語サイト、ECサイトのサブサイト、ダウンロードサイト、管理画面などで、独立したサブドメインを使用しているか。
• ユーザーが旧ドメイン名、テスト用ドメイン名、またはIPアドレスから直接アクセスする可能性があるか。
• 証明書が、現在外部向けにサービスを提供しているドメインバインディングまたは仮想ホスト設定にデプロイされているか。

「すべてのドメインをHTTPSへリダイレクトする」ことで、名前の不一致を隠そうとしないでください。リダイレクトはTLSハンドシェイク後に発生するため、ブラウザはまず現在のドメイン名の証明書を検証します。証明書名が一致しない場合は、先に警告が表示されます。適切な方法は、実際のアクセス入口に対して証明書の対象範囲を追加するか、DNS、サイト入口、プロモーションリンクのレベルでドメイン名を統一・標準化することです。

証明書チェーンが欠落すると、サーバー上では正しくインストールされているように見えても、クライアントは検証できません

SSL証明書は通常、サーバー証明書1枚だけではありません。ブラウザは中間証明書を通じて、信頼されたルート証明書までの検証パスを構築する必要があります。デプロイ時にドメイン証明書のみをアップロードし、CAが提供する中間証明書バンドルを設定していない場合、一部のブラウザまたは旧型デバイスでは証明書が信頼できないという警告が表示されます。

Nginx環境では、よくある問題としてssl_certificateが、サーバー証明書と中間証明書を含む完全なチェーンファイルではなく、単独の証明書ファイルを参照しているケースがあります。Apacheでは、対応する証明書チェーン設定が現在のバージョン要件に合致しているか確認する必要があります。コントロールパネル環境では、最初の証明書内容だけを貼り付けるのではなく、認証局が提供する「完全な証明書チェーン」「fullchain」または「CA Bundle」ファイルを使用してください。

チェーンの順序ミスも防止する必要があります。通常は、サイト証明書を先に配置し、その後に中間証明書を順に追加します。ルート証明書は通常、サーバーから積極的に配信する必要はありません。ファイルを置き換えた後は、Webサービスの設定を再読み込みし、サーバー上でファイルの存在を確認するだけでなく、外部ネットワークから再確認してください。

HTTPSが有効なのに、なぜページは依然として安全ではないと表示されるのか

この状況は多くの場合、混在コンテンツに関連します。ページのHTMLはHTTPSで送信されていても、画像、JavaScript、CSS、動画、フォント、アクセス解析コード、iframe、またはAPIアドレスが依然としてhttp://で記述されています。最新のブラウザは、スクリプトやXHRリクエストなどの一部のアクティブコンテンツを直接ブロックします。一部の画像やメディアリソースについては、読み込みを許可する一方でセキュリティ状態を低下させることがあります。

対処はページのソースコードとブラウザコンソールから始め、具体的なリソースアドレスを特定したうえで、リソースの提供元を確認する順序で行います。

1. サイト内の静的リソースはHTTPSの絶対URLに変更するか、現在のサイトに適した相対パスを使用します。
2. テンプレート、リッチテキストコンテンツ、商品詳細、過去の記事内にハードコーディングされたHTTPリンクを一括で調査します。
3. サードパーティ製スクリプト、地図、カスタマーサポートウィンドウ、動画埋め込み、フォームコンポーネントがHTTPSに対応していることを必ず確認します。
4. APIドメイン名、ファイルストレージドメイン名、画像CDNにも有効な証明書をデプロイする必要があり、トップページのドメイン名だけを変更してはいけません。
5. 変更後は、サイトキャッシュ、CDNキャッシュ、ブラウザキャッシュをクリアしてから再テストします。

ブラウザの「安全でないリクエストを自動アップグレードする」ポリシーだけに依存することは推奨しません。これは暫定的な対策として利用できますが、すべてのリソースが正しく読み込まれるとは限りません。サードパーティリソースがHTTPSに対応していない場合は、スタイルの欠落、機能不全、データリクエストの失敗を招く可能性があります。

サーバーのリスニング、リダイレクト、マルチノード構成を確認する

証明書が正しいからといって、443ポートが正しいサイトによって処理されているとは限りません。サーバーファイアウォール、セキュリティグループ、Webサービスのすべてで443ポートへのアクセスが許可されており、そのポートに対象ドメイン名に対応する証明書がバインドされていることを確認してください。共有IPや複数サイトの環境では、SNI設定の異常によりサーバーが別サイトの証明書を返し、ドメイン名の不一致が発生する可能性があります。

HTTPからHTTPSへのリダイレクトも確認が必要です。理想的には、http://バージョンへのアクセス後、1回の301または308リダイレクトで正規のHTTPSアドレスへ移行します。HTTPからHTTPSへ移動した後にHTTPSからHTTPへ戻るループが発生しないようにし、また異なるページでwwwあり・なしの間を繰り返しリダイレクトしないでください。ログインページ、フォーム送信ページ、決済コールバックページ、管理画面の入口は、特に個別に検証する必要があります。

サイトの前段にCDN、ロードバランサー、またはリバースプロキシが配置されている場合は、エッジノード証明書とオリジン証明書をそれぞれ確認する必要があります。エッジノードが正常でもオリジンに異常がある場合、一部のオリジンフェッチのシナリオは失敗します。オリジンが更新済みでもCDNに古い証明書が残っている場合、外部からのアクセスで表示されるのは新しい証明書ではない可能性があります。IPv4とIPv6のデュアルスタック解析がある場合は、両方のアドレスに対応するノードをテストしてください。

「更新直後に再びエラーになる」再発問題を回避する

証明書更新後も古い証明書が表示される場合は、多くの場合、設定の参照パスが更新されていない、サービスが再読み込みされていない、または一部のノードに新しいファイルが同期されていないことが原因です。証明書変更記録を作成する際には、証明書の対象ドメイン名、有効期限、秘密鍵の保存場所、完全なチェーンファイルの場所、デプロイノード、再読み込み操作を同時に記録してください。更新前後にそれぞれ外部ネットワークからシリアル番号と有効期限を確認し、ブラウザが実際に取得している証明書が新しいものであることを確認します。

マーケティング用ランディングページ、独立系サイト、多言語ページでは、HTTPSチェックも公開プロセスに組み込む必要があります。新しいページを公開する前に外部リソースのプロトコルを確認し、新たに追加したサブドメインが証明書の対象に含まれていることを確認し、新たに導入したサードパーティツールの埋め込みコードを検証します。これにより、「安全ではありません」という表示を公開前に抑え、訪問者からのフィードバック後に項目ごとに修正する事態を防げます。