NET::ERR_CERT_COMMON_NAME_INVALID

このエラーの意味と見分け方

• ChromeまたはEdgeに「接続はプライベートではありません」と表示され、NET::ERR_CERT_COMMON_NAME_INVALIDが示される。
• 証明書の詳細に、別のホスト名のCommon NameまたはSubject Alternative Nameが表示される。
• ベアドメインは動作するが、特定のサブドメインで失敗する。
• サブドメインの追加、DNSの変更、ホスティングの移行、CDNまたはロードバランサーの有効化後にエラーが発生する。
• 共有サーバーまたはCDNが、デフォルト、プレースホルダー、または無関係な証明書を提示する。
• IPv4、IPv6、DNS、またはエッジルーティングの経路が異なることを示すように、一部のユーザーまたはネットワークだけでエラーが発生する。

可能性の高い順の主な原因

1. 証明書にリクエストされたホスト名が含まれていない。 失敗しているホスト名が、証明書のSANリストに存在しない可能性があります。ワイルドカードで一部のサブドメインをカバーできますが、スコープがリクエストされた名前と一致している必要があります。
2. サーバーがデフォルト証明書を配信している。 共有ホスティングでドメインに証明書が割り当てられていないか、SNIまたはHTTPSのバーチャルホスト選択が正しくない可能性があります。
3. CDNまたはロードバランサーに誤ったエッジ証明書が設定されている。 ホスト名がサービスに設定されていないか、リクエストがデフォルトのリスナーまたはエッジ設定に到達している可能性があります。
4. DNSが誤ったエンドポイントを指している。 誤ったA、AAAA、またはCNAMEレコードにより、別サイト用の証明書を提示するサーバーへリクエストが送られることがあります。誤ったAAAAレコードは、IPv4では動作していてもIPv6ユーザーに影響する可能性があります。
5. 移行またはドメイン変更後もサービス間の設定が同期されていない。 DNS、CDN、オリジンサーバー、証明書が、それぞれ異なるホスト名またはエンドポイント用に設定されている可能性があります。

修正方法

1. 正確なホスト名と証明書の不一致を特定する

アドレスバーに表示されている完全なホスト名を確認します。すべてのサブドメインを含めてください。ブラウザの証明書詳細を開き、Common NameとSubject Alternative Names（SAN）を確認します。リクエストされたホスト名がSANリストに含まれているか、適用可能なワイルドカードパターンと一致している必要があります。

コマンドラインで確認する場合は、テスト対象のホスト名を変数に設定します。

HOSTNAME='[your hostname]'
openssl s_client -connect "$HOSTNAME:443" -servername "$HOSTNAME" </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

-servernameオプションは、SNIを使用してホスト名を送信します。共有HTTPSインフラでは重要です。設定を変更する前に診断コマンドを実行してください。

2. 証明書にホスト名を追加する

証明書がベアドメインをカバーしているものの、エラーが発生しているサブドメインをカバーしていない場合は、必要なホスト名をSANとして含む証明書を再発行または置き換えます。ワイルドカード証明書で複数の1階層サブドメインをカバーできる場合がありますが、ベアドメインと、さらに深い階層のサブドメインについては、個別にカバー範囲を確認してください。

Certbotを使用する場合は、まず、そのドメインの証明書をリクエストしてデプロイする権限があること、webrootが正しいこと、検証方法がサーバーに適していることを確認します。発行リクエストには必要なすべての名前を含めてください。

DOMAIN='[your bare domain]'
SUBDOMAIN='[your subdomain]'
certbot certonly --webroot -w '[your webroot]' -d "$DOMAIN" -d "$SUBDOMAIN"

これは証明書を取得するだけで、証明書を自動的にインストールまたは有効化するものではありません。サーバーに適した発行方法とwebrootを使用し、HTTPSを終端するエンドポイントに証明書をインストールして、正しいホスト名に割り当ててください。

3. 共有ホスティングとオリジンサーバーの設定を確認する

ホスティングのコントロールパネルで、正確なドメインまたはサブドメインに証明書がインストールされ、割り当てられていることを確認します。共有サーバーでは、SNIベースの証明書選択とHTTPSバーチャルホストの設定をプロバイダーに確認してもらいます。

証明書ファイル、権限、設定が正しいことを確認してから、Webサーバーをリロードまたは再起動します。リロードや再起動によってサービスが中断する可能性があるため、プロバイダーの変更手順に従い、適用に必要な承認を得てください。

4. CDNとロードバランサーの証明書カバレッジを確認する

正確なホスト名がCDNまたはロードバランサーに設定され、そのエッジ証明書に含まれていることを確認します。また、そのホスト名が意図したオリジンにルーティングされていることも確認してください。

CDNがHTTPSを終端する場合、オリジンの証明書だけではブラウザの不一致は解消されません。公開エンドポイントのエッジで配信される証明書が、そのホスト名をカバーしている必要があります。CDNがHTTPSをパススルーする場合は、オリジンで配信される証明書を確認してください。

5. IPv4とIPv6のDNSを確認する

ホスト名のA、AAAA、CNAMEレコードを、ホスティングまたはCDNプロバイダーが指定したエンドポイントまたはターゲットと比較します。エラーが発生するネットワークがIPv4とIPv6のどちらを使用しているか、また両方の経路が意図したサービスに到達しているかを確認してください。

意図したエンドポイントと適切なDNS変更手順を確認してから、古いレコードや意図しないレコードを修正します。キャッシュされたDNS応答はTTLが切れるまで残る可能性があるため、影響を受けたネットワークから結果を確認してください。

6. 同じHTTPSホスト名で再テストする

証明書の割り当て、ルーティング、またはDNSを変更した後、失敗した正確なURLをテストします。返された証明書を再度確認し、SANリスト、発行者、有効期限を確認してください。影響を受けたネットワークだけでなく、ホスティング、CDN、またはサーバー環境からもテストし、伝播やリゾルバーの違いと、現在も続いている設定ミスを切り分けます。

予防と修正確認

• サブドメインの追加、DNSの変更、ホスティングの移行、またはCDNの追加時には、証明書のカバレッジを必ず含めて確認します。
• ベアドメイン、1階層のサブドメイン、サービスが実際に使用するさらに深い階層の名前を確認したうえで、SANによるカバレッジまたは適切なスコープのワイルドカードを使用します。
• DNSレコード、CDNのホスト名、ロードバランサーのリスナー、オリジンのバーチャルホスト、証明書の割り当てを一致させます。
• DNS変更後は、AとAAAAの両方の経路をテストします。
• ブラウザの警告が表示されないことだけに頼らず、公開エンドポイントが配信する証明書を確認します。
• HTTPSを終端するサービスを記録し、正しいレイヤーで証明書を変更できるようにします。
• 必要なすべてのホスト名を含む証明書の更新およびデプロイ手順を維持します。

よくある質問