ERR_SSL_VERSION_OR_CIPHER_MISMATCH 解決方法｜Chrome・Edge

ERR_SSL_VERSION_OR_CIPHER_MISMATCH とは？

ERR_SSL_VERSION_OR_CIPHER_MISMATCH は、ブラウザとWebサイトが接続の暗号化方式で合意できなかったことを示すエラーです。 Chromeでは「このサイトは安全に接続できません」「example.com ではサポートされていないプロトコルが使用されています。」と表示され、詳細には「クライアントとサーバーで、共通の SSL プロトコル バージョンまたは暗号スイートがサポートされていません。」と出ます。Chromiumではエラー -113 として定義されています（net_error_list.h）。

このエラーはTLSハンドシェイクの最初の段階で起きます。ブラウザは自分が使えるTLSバージョンと暗号スイートの一覧を送り、サーバーはそれぞれから1つずつ選ばなければなりません。一覧に共通のものがない、ブラウザがもう受け付けないバージョンで応答してくる、あるいは入力されたドメイン名に対応する証明書がなく処理を続けられない場合、ハンドシェイクはそこで止まります。

証明書の検査より前に失敗するため、期限切れ、ドメイン名の不一致、チェーンの不備のある証明書では別のエラーが表示されます（末尾の表を参照）。Firefoxでは、暗号や証明書を理由に拒否された場合は SSL_ERROR_NO_CYPHER_OVERLAP、TLS 1.0/1.1にしか対応していないサーバーでは SSL_ERROR_UNSUPPORTED_VERSION と表示されます。

各ブラウザでのエラー表示

Chromiumベースのブラウザ（Chrome、Edge、Brave、Opera）はすべて同じコードを表示します。次の表示を探してください。

ERR_SSL_VERSION_OR_CIPHER_MISMATCH の原因

エラーが1つのサイトだけに出る場合、原因はそのサイトのサーバーかCDNです。多くのサイトで出る場合は、お使いの端末やネットワークの途中に何かがあります。原因は次のとおりです。

• サーバーがTLS 1.0/1.1にしか対応していない。 Chrome、Edge、Firefoxは2020年に両方のブロックを開始し（Firefox 78、ChromeとEdge 84）、Chrome 98（2022年）以降は回避する方法がありません。Chromiumはこうしたサーバーをこのエラーとして報告します（net_error_list.h）。
• サーバーが古い暗号しか提供していない。 RC4、3DES、輸出グレードの暗号スイートなどです。ChromeのTLSコードは3DESを完全に無効にしているため、ほかに何も提供しないサーバーには接続できません。
• 入力したドメイン名に対応する証明書がない（一部のCDN）。 CloudflareとCloudFrontでは、証明書のないホスト名はハンドシェイクの最初で拒否されます。Cloudflareではこれが最も多い原因で、証明書がまだ有効化されていない、レコードがプロキシ経由になっていない、カスタム証明書が期限切れで代わりになるものがない、ドメインがマルチレベルのサブドメインである、のいずれかです（Cloudflare）。通常のnginxやApacheのサーバーは代わりにデフォルトの証明書を返すため、ドメイン名の不一致の警告が表示されます。
• 途中にあるもの。 ウイルス対策ソフトのHTTPSスキャン、社内プロキシ、通信を古いTLS設定で暗号化し直すVPNなどです。
• とても古い端末やブラウザ。 Windows XP、Android 4.x、何年も更新していないブラウザには、サーバーが現在要求するTLS 1.2や暗号スイートがありません。

実際に試してみました：古いTLSのサーバーと最新のクライアント

このエラーが何で起きるかを示すため、2026年10月27日に最新のTLSクライアント（OpenSSL 3.6）でbadssl.comの公開テストサーバーに接続しました。TLS 1.0と1.1のサーバーはクライアントがもう受け付けないバージョンで応答し、RC4と3DESのサーバーは handshake_failure アラートで拒否しました。Chromeでは4つともERR_SSL_VERSION_OR_CIPHER_MISMATCHと表示されます。

https://tls-v1-0.badssl.com:1010/ をChromeで開くと、まさにこのエラーページが表示されます。ご自身のサイトが最初の4行と同じ状態なら、下のWebサイト管理者向けの修正が当てはまります。

ERR_SSL_VERSION_OR_CIPHER_MISMATCH の直し方（ユーザー向け）

Webサイトのサーバーは利用者には変えられないので、まずどちらの問題かを切り分けます。1つのサイトだけ開けない場合は、管理者にしか直せないため、Webサイト管理者向けの修正へ進んでください。多くのサイトで開けない場合は、次の方法を試します。（古い対処法の「QUICを無効にする」はここでは効果がありません。QUICの失敗では ERR_QUIC_PROTOCOL_ERROR が表示されます。）

修正方法1：サイトの問題かどうかを確認する

同じサイトを別の端末やモバイルデータ通信で開いてみてください。そこでも開けないなら、問題はサーバー側です。

確実に調べるには、DNS RobotのSSL Checkerにサイトを入力します。ほとんどのサーバーについて、対応しているTLSバージョンが一覧で表示され、Cloudflare上のサイトではそのドメイン名の証明書が発行済みかどうかも分かります。TLS 1.0/1.1にしか対応していないサイトは、Chrome、Edge、Firefoxでは開けず、クリックして進める方法もありません。Chromeにはこのエラーで「このまま続行」するリンクが表示されないのです。

修正方法2：ブラウザとオペレーティングシステムを更新する

とても古いブラウザやシステムには、TLS 1.2、TLS 1.3、またはサーバーが現在使っている暗号スイートがありません。Chromeは chrome://settings/help、Edgeは edge://settings/help で更新し、そのあとオペレーティングシステムも更新してください。

Windows XPとVistaのInternet Explorer、およびAndroid 4.0〜4.3の標準ブラウザは、現在の暗号スイートでTLS 1.2を使えず、ほとんどのHTTPSサイトで失敗します。

修正方法3：ウイルス対策ソフトのHTTPSスキャンを確認する

HTTPSをスキャンするウイルス対策ソフト（Avast、Kaspersky、Bitdefender、ESET、Norton）はすべての接続の途中に入り、Webサイトとの間に独自のTLS接続を作ります。そのTLS設定が古いと、最新のTLSを要求するサイトで失敗します。

無効にするのはHTTPSスキャンの部分だけです。名前は製品ごとに異なります（AvastのWeb ShieldのHTTPSスキャン、ESETのSSL/TLSプロトコルフィルタリング、Bitdefenderの暗号化Webスキャン、Kasperskyの暗号化された接続のスキャン）。無効にしたら再読み込みしてください。エラーが消えたら、スキャンを切ったままにせず、ウイルス対策ソフトを更新するか、そのサイトを例外に追加します。

修正方法4：VPNまたはプロキシを切断する

社内プロキシや、Webプロテクション機能やHTTPS検査機能を持つVPNは、サイトとの間に独自のTLS接続を作ります（通常のVPNトンネルは作りません）。切断して再読み込みしてください。サイトが開けたら、その機能をオフにするか、プロバイダー（または社内のIT担当）にTLS設定の更新を依頼してください。

ERR_SSL_VERSION_OR_CIPHER_MISMATCH の直し方（Webサイト管理者向け）

訪問者からこのエラーが報告されるなら、ポート443で応答しているサーバーまたはCDNが、最新のブラウザとTLSで合意できていません。SSL Checkerで確認してから、次の手順に進んでください。

修正方法1：すべてのドメイン名に証明書があることを確認する

Cloudflare、CloudFront、その他一部のCDNでは、証明書のないホスト名はハンドシェイクが拒否され、ブラウザには証明書の警告ではなくこのエラーが表示されます。通常のnginxやApacheのサーバーでは、代わりにデフォルトの証明書が返されて（ERR_CERT_COMMON_NAME_INVALID）、nginxの ssl_reject_handshake を使っている場合は unrecognized_name アラート（ERR_SSL_UNRECOGNIZED_NAME_ALERT）になるのが一般的です。訪問者が使うすべてのドメイン名、つまり example.com、www.example.com、各サブドメインを確認してください。

各ドメイン名をSSL Checkerで調べるか、ターミナルから確認します（OpenSSL 1.1.1以降。「Could not find certificate」と表示されたら、そのドメイン名についてサーバーがハンドシェイクを拒否しています）。

# Does the server present a certificate for this exact name?
openssl s_client -connect example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

# Which TLS versions and ciphers does it accept?
nmap --script ssl-enum-ciphers -p 443 example.com

修正方法2：TLS 1.2 と TLS 1.3 を有効にする

現在のブラウザはすべて、少なくとも TLS 1.2 を必要とします。TLS 1.2とTLS 1.3を有効にし、それより古いものは有効にしないでください。

# nginx (site config or nginx.conf)
ssl_protocols TLSv1.2 TLSv1.3;

# Apache (ssl.conf)
SSLProtocol -all +TLSv1.2 +TLSv1.3

# Then check the config and reload
sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

再読み込みしたら、SSL CheckerかQualys SSL Labsでもう一度テストし、TLS 1.2と1.3だけが提供されていることを確認してください。

修正方法3：最新の暗号スイートを提供する

TLS 1.2を有効にしたら、ブラウザがまだ受け付ける暗号をサーバーが提供する必要があります。AES-GCMまたはChaCha20-Poly1305を使ったECDHE（Mozillaの推奨セット）を提供してください。RC4、3DES、輸出グレード、NULL暗号は拒否されます。

# nginx (TLS 1.2 ciphers; TLS 1.3 ciphers are always on)
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

# Apache
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder off

修正方法4：Cloudflare固有の修正

Cloudflare自身のガイドによると、このエラーはホスト名が証明書でカバーされていないときに起きます（Cloudflare）。次の順に確認してください。

• 証明書は有効（Active）ですか？ 新しいドメインのUniversal SSL証明書は、15分から24時間で発行されます。SSL/TLS → Edge Certificates で、ステータスがActiveになっている必要があります。
• DNSレコードはプロキシ経由ですか？ 証明書が提示されるのは、プロキシ経由（オレンジの雲）のレコードだけです。プロキシ経由の名前をDNS Lookupで調べると、サーバーのアドレスではなくCloudflareのアドレスが返ります。
• カスタム証明書は期限切れになっていませんか？ Cloudflareは期限切れの証明書を削除します。そのドメイン名をカバーするほかの有効な証明書（Universal SSLなど）がない場合、訪問者には証明書の警告ではなくこのエラーが表示されます。
• マルチレベルのサブドメインですか？ フルセットアップでは、Universal SSLがカバーするのは example.com と *.example.com だけで、test.dev.example.com は対象外です。Advancedまたはカスタム証明書、あるいはTotal TLS（Advanced Certificate Managerが必要）を使ってください。

修正方法5：その他のCDNとロードバランサーを確認する

CDNやロードバランサー（CloudFront、Fastly、Akamai、クラウドのロードバランサー）がTLS接続を終端している場合、決め手になるのはサーバーではなくそちらの設定です。

• すべてのホスト名に証明書があり、正しいディストリビューションやリスナーに紐づいていること
• セキュリティポリシーの最小TLSバージョンが1.2で、最新の暗号が使われていること
• 複数のドメインが1つのIPアドレスを共有している場合はSNIに対応していること

SSL設定をテストする方法

変更したら、SSL設定が正しいことを確認してください。次のツールを使えば、訪問者より先に問題を見つけられます。

• DNS Robot SSL Checker — 証明書のステータス、有効期限、チェーンの完全性、発行元をすばやく確認できます。数秒で結果が出ます。
• Qualys SSL Labs — TLSバージョン、暗号スイート、プロトコル対応、既知の脆弱性を詳しくスキャンし、アルファベットで評価します（AまたはA+を目指しましょう）。
• OpenSSL CLI — コマンドラインから openssl s_client -connect domain.com:443 を実行すると、生のハンドシェイク、証明書チェーン、ネゴシエートされた暗号が分かります。
• Chrome DevTools — 読み込めるページなら、Security（またはPrivacy and security）パネルに使用中のTLSバージョンと暗号が表示されます。

# Quick check: protocol, cipher and certificate in a few lines
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -brief </dev/null

# Does it accept TLS 1.2? TLS 1.3?
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_2 -brief </dev/null
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_3 -brief </dev/null

関連するSSL/TLSエラー

ChromeにはTLSと証明書に関するエラーがいくつかあり、それぞれ別の段階で発生します。

関連エラーのガイド：ERR_SSL_PROTOCOL_ERROR、ERR_CERT_AUTHORITY_INVALID、この接続ではプライバシーが保護されません。