SSL証明書の名前不一致・信頼エラーの直し方｜古いTLSが出たときも

• 証明書の期限切れと期限が近い表示のうち、サイトの証明書そのものの期限は、この記事では扱いません。SSL証明書の期限切れの対処を読んでください。連鎖の途中の証明書の期限切れは、この記事の「SSL証明書が自己署名です」「発行元が信頼されていません」「中間証明書が不足しています」「信頼されていません」と出たときで扱います
• 下の表で診断に出た表示を探し、当てはまる行へ進んでください。当てはまる行が複数あるときは、1件ずつ直して診断をやり直してください
• ブラウザの警告画面で先へ進む操作や、証明書の検証を無効にする設定では直りません。証明書の中身と証明書を返している場所を確かめて直します
• サイトの訪問者として警告画面を見た方は、サイトの管理者に知らせてください。この記事は、サイトを運営している側の作業を書いています

診断の表示から読む場所を決めてください

まずSiteKensaの診断で、警告が出ているドメインを調べてください。ブラウザの警告画面から来た方は、画面のエラー番号を控えて診断を実行してください。番号と表の行の対応は次のとおりです。番号はChromeのヘルプの証明書の項目にあるものです。

NET::ERR_CERT_COMMON_NAME_INVALID → このドメイン名に対応していません
NET::ERR_CERT_AUTHORITY_INVALID → 下の表の信頼の4表示
NET::ERR_CERT_DATE_INVALID → SSL証明書の期限切れの対処
ERR_SSL_VERSION_OR_CIPHER_MISMATCH → 「古い暗号化方式が使われています」と出たとき

当てはまる行が複数あるときは、上から1件ずつ直して診断をやり直してください。診断は名前の不一致と信頼の問題と古い暗号化方式を同時に出すことがあります。

出てくる用語

「SSL証明書がこのドメイン名に対応していません」と出たとき

診断に「SSL証明書がこのドメイン名に対応していません」と出たときはこの節を読んでください。証明書自体は有効でも、書かれた名前と開こうとしたホスト名が違うとブラウザは警告を出します。証明書の取り直しを考える前に、実際に返っている証明書の中身を確かめてください。診断には次のように出ます。

実際に返っている証明書のSANを確かめてください

SiteKensaの診断で調べ、証明書の項目の「観測した内容を見る」を開くと発行者と対象の名前が出ます。「観測した内容を見る」は証明書の項目の中にあります。macOSかLinuxのターミナルでも、次のコマンドで指定したホスト名に返る証明書を読めます。wrong.host.badssl.com の2か所を自分のホスト名に置き換えて実行してください。

$ echo | openssl s_client -connect wrong.host.badssl.com:443 -servername wrong.host.badssl.com 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName
subject=CN=*.badssl.com
X509v3 Subject Alternative Name:
    DNS:*.badssl.com, DNS:badssl.com

一覧にある名前と開こうとしたホスト名を比べます。開こうとした名前に一致する項目が一覧にある必要があります。1つ目の出力の一覧には wrong.host.badssl.com に一致する項目がありません。

$ echo | openssl s_client -connect wrong.host.badssl.com:443 -servername wrong.host.badssl.com -verify_hostname wrong.host.badssl.com 2>&1 | grep "Verify return code"
    Verify return code: 62 (hostname mismatch)

どちらも2026年9月28日にOpenSSL 3.6.3で実行した出力です。-servername はSNIで送るホスト名を指定するもので、この指定だけでホスト名の検証が終わるわけではありません。照合の結果は -verify_hostname を付けたときの Verify return code で見ます。コマンドの結果を読めないときは、診断の証明書の項目で対象の名前を確かめてください。Windowsではコマンドを使わず、診断で確かめてください。

wwwあり・なしとワイルドカードの範囲を確かめてください

一覧に会社名のドメインが見えるだけでは足りず、開こうとした名前そのものが一覧にある必要があります。よくある行き違いは次の3つです。

証明書に書かれたワイルドカードの * が置き換えるのは1つの階層だけです（RFC 9525 セクション6.3）。現行の規格では、証明書のCommon Nameの欄は接続先の特定に使わないことになっています（RFC 9525 セクション2の「The Common Name RDN MUST NOT be used to identify a service」）。診断で一致と出た証明書でも、SANに開きたい名前があるか確かめてください。診断の照合はCommon Nameだけでも一致と判定することがあります（Node v26.7.0で実測）。

一覧に足りない名前があるときは、その名前を含む証明書を取り直して登録します。「wwwあり」と「wwwなし」の両方で開かれているなら両方を一覧に入れてください。取り直す場所が分からないときは、診断の証明書の項目で発行者を確かめ、その発行者の案内で探してください。自動で更新する仕組みを使っているときは、証明書を取ったときの手順の案内で、名前の一覧の変え方を確かめてください。

違う証明書を返す入口を探してください

一覧が正しいのに警告が出るときは、見ている証明書のファイルではなく、実際に返っている証明書が別物の可能性があります。TLS終端が複数ある構成で起きます。

• 同じIPで複数のホスト名を公開していて、SNIごとの証明書の割り当てがずれている
• CDNや負荷分散装置やプロキシがTLS終端になっていて、そちらが古い証明書や別サイトの証明書を返している
• 移行やDNS変更の途中で、一部の接続だけが古いサーバーへ届いている（IPv4とIPv6で向き先が違う場合を含みます）

確かめ方は、公開先から返った証明書の連番か指紋を控え、TLS終端を1つずつ当たることです。どれに当たるかは、返る証明書を比べると分かります。-servername を付けたときと付けないときで連番か指紋が違うときは、要求する名前で証明書の選択が変わっています。同じときは、DNSの向き先かTLS終端を疑ってください。連番と指紋は次のコマンドで出ます。wrong.host.badssl.com の2か所を確かめたいホスト名に置き換えて実行してください。

$ echo | openssl s_client -connect wrong.host.badssl.com:443 -servername wrong.host.badssl.com 2>/dev/null | openssl x509 -noout -serial -fingerprint -sha256
serial=065BE17B359D30FCA59459F9893231C1D87D
sha256 Fingerprint=68:8F:99:18:5E:12:A4:94:D3:91:0C:E0:60:53:28:26:A3:5F:E0:24:76:E1:7E:9B:AD:2F:68:E9:23:84:7C:A3

2026年9月28日にOpenSSL 3.6.3で実行した出力です。診断が転送先を見たときは、そのホスト名で確かめてください。見つけた場所に正しい証明書を登録し、公開先からもう一度確かめます。サイトの管理を任せている会社に依頼するときは、公開先で返る証明書と登録した証明書が同じかを確かめてもらってください。

「SSL証明書が自己署名です」「発行元が信頼されていません」「中間証明書が不足しています」「信頼されていません」と出たとき

名前が合っていても証明書を信頼できるところまでたどれなければブラウザは警告を出します。対象の表示は「自己署名」「発行元が信頼されていません」「中間証明書が不足しています」「信頼されていません」の4つです。原因は主に3つに分かれるので、表示に合う項目へ進んでください。汎用の表示のときは上から順に疑ってください。診断には次のように出ます。

自己署名の証明書を使っていないか

診断に「SSL証明書が自己署名です」と出たときは、認証局ではなく自己署名された証明書を使っています。opensslでは次のように出ます。

$ echo | openssl s_client -connect self-signed.badssl.com:443 -servername self-signed.badssl.com 2>/dev/null | openssl x509 -noout -subject -issuer
subject=C=US, ST=California, L=San Francisco, O=BadSSL, CN=*.badssl.com
issuer=C=US, ST=California, L=San Francisco, O=BadSSL, CN=*.badssl.com

発行者と対象が同じで、有効期間内でも警告が出ます（2026年9月28日にOpenSSL 3.6.3で実行した出力です。Verify return code は 18 (self-signed certificate) でした）。

公開しているサイトでは、認証局が発行した証明書に置き換えてください。契約しているレンタルサーバーの案内で、無料の証明書の発行手順を確かめてください。

中間証明書を送っているか

診断に「SSL証明書の中間証明書が不足しています」と出たときは、サーバーがサイトの証明書だけを送り、中間証明書を送っていません。opensslでは次のように出ます。

$ echo | openssl s_client -connect incomplete-chain.badssl.com:443 -servername incomplete-chain.badssl.com 2>&1 | grep "Verify return code"
    Verify return code: 21 (unable to verify the first certificate)

2026年9月28日にOpenSSL 3.6.3で実行した出力です。ブラウザでは開けるのにスマートフォンのアプリや別の仕組みからの接続で失敗することがあります。サーバーに中間証明書を設定し、サイトの証明書と一緒に送るようにしてください。設定の場所は、TLS終端になっているサーバーや装置の説明書で確かめてください。自分で設定できないときは、契約している事業者かサイトの管理を任せている会社に依頼してください。

診断に発行元や信頼の表示が出て、opensslに 19 (self-signed certificate in certificate chain) と出たときは、この環境で連鎖を検証できていません。連鎖を作っている証明書を発行元が現在配っているものに入れ替えてください。19以外の番号が出たときは、その番号を控えてください。診断の表示とあわせて、証明書を入れた事業者かサイトの管理を任せている会社に確かめてください。

連鎖の途中の証明書が切れていないか

診断に「SSL証明書の連鎖の中に有効期限の切れた証明書があります」と出たときは、サイトの証明書そのものは期限内です。一緒に送っている中間証明書などの有効期限が切れています。サーバーに設定している中間証明書を発行元が現在配っているものに差し替えてください。サイトの証明書そのものの期限切れは、SSL証明書の期限切れの対処を読んでください。

「古い暗号化方式が使われています」と出たとき

診断に「古い暗号化方式が使われています」と出たときはTLS 1.2以上では接続できず、古い版を許して接続し直すとつながった状態です。TLS 1.0、TLS 1.1は使ってはならないことになっています（RFC 8996 セクション4、セクション5の「TLS 1.0 MUST NOT be used」「TLS 1.1 MUST NOT be used」）。古い版だけに対応しているとその版を使えない訪問者は開けなくなります。この項目はサーバーが使えるTLSの版についてのもので、証明書を替えても消えません。サーバーの設定でTLS 1.2以上を有効にしてください。国内の目安として、IPAのTLS暗号設定ガイドラインがあります。選ぶ設定の型は、同ガイドラインで確かめてください。設定の場所は、レンタルサーバーやCDNなら事業者の案内で、自分のサーバーならWebサーバーのソフトの説明書で確かめてください。

診断が読めるのは接続に使った版で、サーバーが許している版の全部ではありません。TLS 1.2以上と古い版を両方許しているサーバーではこの項目は出ません。設定が見つからないときや自分で変えられないときは、診断したホスト名と診断の結果を添えて、事業者かサイトの管理を任せている会社に依頼してください。変えたあとは同じホスト名をもう一度診断し、この項目が出なくなったことを確かめてください。

「証明書の問題でサイトが開けません」と出たとき

診断に「証明書の問題でサイトが開けません」と出たときは、証明書の不具合のためにHTTPSの接続自体が作れず、訪問者はサイトを開けません。サーバー自体は動いている可能性が高いので、サーバーの障害として調べ直す前に証明書を直してください。原因になった表示は、同じ診断結果の証明書の項目に、開けない表示と一緒に出ます。その表示から診断の表示から読む場所を決めてくださいの表へ戻り、該当する行へ進んでください。

一部の端末だけで警告が出るとき

診断が問題なしと出すのに特定の端末や社内の回線だけで警告が出るときは、まず端末や接続経路を切り分けてください。別の端末や別の回線で同じURLを開き、再現する範囲を先に確かめます。

• 端末の日付と時刻を確かめる。大きくずれていると証明書の日付のエラーが出ることがある（Chromeのヘルプ）
• OSを更新する（同じヘルプ）
• 会社のプロキシやセキュリティソフトを切り分ける。社内の管理者に確かめる（同じヘルプ）

端末側の問題と分かったら、その端末の時刻合わせと更新、社内の管理者への確認へ進んでください。サイトの証明書の作り直しは要りません。

直した後も警告が残るとき

証明書を登録し直したのに警告が消えないときは、直した場所が実際に証明書を返している場所と違う可能性があります。TLS終端がCDNや負荷分散装置やプロキシにある構成で起きます。

公開先から返った証明書の連番か指紋を控え、登録し直した証明書と比べてください。違うものが返っている場所が、直す場所です。その場所で新しい証明書に替えて読み込ませ、公開先からもう一度確かめます。向き先の確かめ方は次の順です。

1. DNSの向き先が古いサーバーを向いたままなら、証明書の前に向き先を直します
2. 向き先が新しいのに古い証明書が返るときは、TLS終端が古い証明書を返している可能性があります。接続した先と証明書の割り当てを確かめてください
3. 診断でも同じホスト名を調べ直し、対象の問題の表示が消えて「SSL証明書は有効です (残り○日)」と出たことを確かめてください

「証明書は転送先の○○を確認しました」と出たとき

診断に「証明書は転送先の ○○ を確認しました」と出たときは、入力したドメインが別のホストへ転送されるため、訪問者が実際に見る証明書として転送先のものを読んだお知らせです。直す対象ではありません。転送先の証明書に問題があるときは、その問題の表示が別に出ます。

ドメイン名だけでは開けずwwwだけで公開しているときは転送ではないので、この表示は出ません。

直したあとは診断で確かめてください

SiteKensaの診断をもう一度実行し、対象の問題の表示が消えて「SSL証明書は有効です (残り○日)」と出たことを確かめます。使うホスト名（「wwwあり」と「wwwなし」など）ごとに確かめてください。どのホスト名で開かれても同じ証明書が届くとは限りません。