先に結論
有効期限だけでなく、閲覧hostnameを証明書が覆っているか、SNIで正しい証明書を返すか、利用者とエッジに共通のTLS version／cipherがあるかを確認します。CDN利用時はedgeとoriginのTLSを分けます。
最初の5分でhostnameとTLS終端を特定する
- エラーが出る完全なhostname、時刻、端末・ブラウザーを保存する。
- apex、www、追加サブドメイン、IPv4／IPv6で結果を分ける。
- 実際に返された証明書のSAN、issuer、有効期間、fingerprintを記録する。
- CDN／LB／Webサーバーのどこが利用者向けTLSを終端するか確認する。
- 対応TLS version、cipher、SNI設定と直前の証明書・DNS変更を確認する。
切り分け：期限・信頼・チェーン・hostname全般はSSL証明書エラー、更新後に古い証明書が混ざる場合はTLS終端ごとの配布確認へ進みます。
症状の範囲から優先候補を絞る
| 観測 | 優先候補 | 次の確認 |
|---|---|---|
| 特定サブドメインだけ | SAN coverage・edge certificate | hostnameが証明書に含まれるか |
| 古い端末だけ | TLS／cipher互換 | 利用環境とサービスの対応範囲 |
| 一部IPだけ | 終端ごとの設定差 | IPv4／IPv6、region、LB listener |
| CDNを有効化した直後 | edge証明書の発行・coverage | certificate status、DNS record、hostname |
| origin直アクセスだけ失敗 | origin certificate・SNI | 用途、hostname、virtual host |
CDN利用時はedgeとoriginを混同しない
利用者→CDN edgeと、CDN edge→originは別のTLS接続です。Cloudflareは、proxied hostnameがedge証明書に含まれない場合にERR_SSL_VERSION_OR_CIPHER_MISMATCHを避けるため専用のエラーを表示すると説明しています。
- 対象DNSレコードがproxiedかDNS-onlyか確認する。
- edge certificateのstatusとhostname coverageを確認する。
- 利用者が実際に到達するIPv4／IPv6・regionごとの証明書を比較する。
- origin側はCDNの暗号化modeと証明書の用途・hostnameを確認する。
- 正常化後もTLS安全性評価と期限監視を実施する。
避ける操作
- 互換性確認なしに古いTLS versionや弱いcipherを有効化する。
- CDNのOrigin CA証明書を一般ブラウザーへ直接提示する。
- 証明書、DNS、暗号化mode、redirectを同時変更する。
- エラー回避のためHTTPへ恒久的に戻す。
- 秘密鍵や証明書bundleを外部の入力フォームへ貼り付ける。
公式情報
よくある質問
証明書の期限が残っていても発生しますか？
発生します。対象hostnameが証明書に含まれない、SNIで別証明書が返る、エッジ証明書が未発行、共通のTLS versionやcipherがない場合があります。
古いTLSを有効にすれば直りますか？
一時的に表示できても安全性を下げます。利用者とサーバーの対応範囲、必要な互換性、サービスの公式要件を確認し、古いTLSや弱いcipherを安易に戻さないでください。
Cloudflareのorigin証明書をブラウザーへ直接見せてもよいですか？
Origin CA証明書は通常、Cloudflareとorigin間で使うものです。DNSをDNS-onlyへ変えるとブラウザーが信頼しない場合があるため、用途を混同しません。