ブラウザーに「この接続ではプライバシーが保護されません」などの SSL 警告が出たとき、原因が証明書そのものではなく、DNS が別のサーバーを指していることにある場合は少なくありません。とくにサーバー移転、CDN の導入、ドメインの追加の直後に出た警告は、DNS の向け先から疑うのが近道です。この記事では、エラーの種類から原因を絞り込み、DNS の答えと実際に返ってくる証明書を突き合わせて、可能性の高い原因から順に確かめて直す手順を説明します。
まずエラーの種類を読む
警告画面の詳細やエラーコードで、原因の方向がある程度分かります。表示はブラウザーと版によって違いますが、代表的なものは次のとおりです（2026年10月現在）。
- 名前が合わない：Chrome 系で
NET::ERR_CERT_COMMON_NAME_INVALID、Firefox でSSL_ERROR_BAD_CERT_DOMAIN。返ってきた証明書に、開いたドメイン名が含まれていません。DNS が別のサーバーを指していると、まずこれが出ます。 - 発行元を信頼できない：
NET::ERR_CERT_AUTHORITY_INVALID、SEC_ERROR_UNKNOWN_ISSUER。自己署名の証明書や、サーバー会社の初期証明書が返っている、中間証明書が足りない、などが原因です。 - 期限切れ：
NET::ERR_CERT_DATE_INVALID、SEC_ERROR_EXPIRED_CERTIFICATE。証明書の更新が止まっているか、古いサーバーの古い証明書が返っています。端末の時計がずれていても出ます。
警告画面で証明書の詳細を開き、「発行先」の名前と「発行者」、有効期限をメモしておくと、この後の切り分けが速くなります。
手順1：DNS の答えが正しいサーバーを指しているか確かめる
いちばん多い原因は、ドメインが意図しないサーバーを指していることです。今の DNS の答えと、本来の向け先を比べます。
# 今の答え（キャッシュDNS経由）
dig example.com A +short
dig www.example.com A +short
dig example.com AAAA +short
dig www.example.com AAAA +short
# 権威DNSに直接聞いた答え
dig example.com NS +short
dig @ns1.example.net example.com A +shortここで確かめる点は次の3つです。
- A レコードが新しいサーバーのアドレスか：移転後に古いサーバーのアドレスが残っていると、古いサーバーの古い証明書（あるいは別のサイト用の証明書）が返ります。
- AAAA レコードが残っていないか：見落としやすいのが IPv6 です。A は新サーバーに変えたのに、古いサーバーの AAAA が残っていると、IPv6 で接続できる利用者だけ警告が出ます。「自分の環境では出ないのに、一部の人から報告がある」ときは、まずここを疑います。新しいサーバーが IPv6 に対応していなければ、古い AAAA は削除します。
- **
wwwあり・なしの両方が同じ向け先か**：片方だけ古いサーバーを指している場合があります。
権威DNSの答えは正しいのに、手元の結果だけ古い場合は、キャッシュが残っているだけです。TTL が切れるのを待つか、端末の DNS キャッシュを消して確かめ直します。
手順2：そのサーバーが返す証明書を直接確かめる
DNS の答えが正しいか分からないときは、アドレスを指定して、そのサーバーがどの証明書を返すかを直接見ます。-servername を付けるのは、1台のサーバーで複数のドメインを扱う場合に、どのドメインの証明書がほしいかを伝える（SNI）ためです。
# 特定のアドレスに接続して、返ってくる証明書の名前と期限を表示する
openssl s_client -connect 203.0.113.10:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltName-ext オプションが使えない古い OpenSSL では、-text で全体を表示して Subject Alternative Name の行を探してください。
ブラウザーと同じ条件で確かめるなら、curl の --resolve で、DNS を変えずに接続先だけを差し替えて試せます。
curl -sv --resolve example.com:443:203.0.113.10 https://example.com/ -o /dev/null 2>&1 \
| grep -E 'subject:|issuer:|expire date:|SSL certificate'新しいサーバーのアドレスで正しい証明書が返り、古いアドレスでは別の証明書が返るなら、原因は DNS の向け先だと確定できます。手順1に戻って、レコードを新しいアドレスにそろえます。
手順3：証明書の取得が DNS のせいで失敗していないか確かめる
新しいサーバーで、まだ正しい証明書が発行されていない場合もあります。Let's Encrypt などの自動発行は、認証局がドメインにアクセスして所有を確かめるため、DNS が古いサーバーを指している間は失敗します。
- HTTP で確かめる方式：ドメインが新しいサーバーを指していないと、認証局は古いサーバーにアクセスして失敗します。DNS の切り替えが行き渡ってから発行し直します。AAAA が古いまま残っていると、IPv6 経由の確認で失敗することもあります。
- DNS で確かめる方式：TXT レコードを使う方式では、レコードを追加したゾーンが、実際に委任されている権威DNSのものかを確かめます。事業者を移した直後は、旧事業者の管理画面に追加してしまう間違いが起きやすくなります。
発行を試す前に、certbot を使っている場合は certbot renew --dry-run で更新の手順が通るかを確かめられます。サーバー会社の管理画面で発行する場合は、画面に表示されるエラーの内容を控えます。
手順4：CAA レコードで発行が止められていないか確かめる
CAA レコードは、そのドメインの証明書を発行してよい認証局を指定するレコードです。以前の事業者向けの CAA が残っていて、新しいサーバーで使う認証局が含まれていないと、発行が拒否されます。
dig example.com CAA +short何も返らなければ制限はありません。値が返る場合は、使う認証局が含まれているかを確かめ、足りなければ追加します。CAA は親のドメインの値も参照されるため、サブドメインで発行に失敗する場合は、親のドメインの CAA も見ます。
手順5：CDN やプロキシの設定を確かめる
CDN を経由させている場合、利用者に証明書を返しているのは CDN です。次の点を確かめます。
- CDN の管理画面で、そのドメインの証明書が発行済みになっているか
- DNS のレコードが、CDN を経由する設定と経由しない設定のどちらになっているか（経由しない設定ならオリジンサーバーの証明書が返ります）
- CDN からオリジンへの接続の暗号化の設定と、オリジン側の証明書が合っているか
設定の名前は CDN の事業者によって違うため、事業者のドキュメントで「SSL/TLS」「証明書」の項目を確かめてください。
手順6：端末やネットワーク側の要因を除く
ここまでで原因が見つからず、特定の場所や端末だけで警告が出る場合は、端末側を疑います。端末の日時がずれていないか、公衆 Wi-Fi のログイン画面に誘導されていないか、セキュリティソフトや社内のプロキシが通信を検査していないかを確かめます。別の回線（スマートフォンのモバイル回線など）で同じ URL を開き、警告が出なければネットワーク側の要因です。
直したあとの確認
レコードを直したら、権威DNSの答え、主要な公開 DNS の答え、openssl s_client での証明書の3つを確かめ直します。WordPress では、「設定」→「一般」のサイトアドレスが https:// になっているかも見ておきます。移転時の作業なら、古いサーバーはすぐに止めず、TTL が切れて利用者がいなくなったことをアクセスログで確かめてから停止します。DNS の変更前には、元に戻せるように変更前のレコードを控えておきます。
まとめ
- エラーが「名前が合わない」なら、まず DNS が別のサーバーを指していないかを疑います。
digで A・AAAA・wwwの向け先を確かめ、とくに古い AAAA の残りに注意します。openssl s_clientやcurl --resolveで、アドレスごとに返る証明書を直接比べると、原因が DNS か証明書かを切り分けられます。- 証明書の発行が失敗する場合は、DNS の切り替えの完了と CAA の値、CDN の設定を順に確かめます。