証明書が有効なのに評価が F になる理由

鍵アイコンはとても狭い約束

ブラウザが鍵アイコンを出すのは 3 つの条件が満たされたときだけです。証明書が信頼されたルートまでつながる、訪問中のホスト名をカバーしている、期限切れでない。それだけです。どのプロトコルバージョンを提示しているか、どのスイートを受け付けるか、ダウングレード攻撃に弱いか、については何も語りません。

TLS 評価は別の問いを立てます。このエンドポイントがどれだけ適切に設定されているか、という問いです。単に暗号化接続を確立できるかどうかではありません。

低評価を生む 6 つの不備

私たちが追跡している 2 万サイトで最もよく見る原因を、おおよそ減点の大きい順に挙げます。

• •証明書の期限切れ、または未発効。他がどれだけ良くても自動的に 0 点。
• •ホスト名の不一致。証明書は有効だが別の名前宛。ドメイン移行後や、CDN が SNI 非対応で共有証明書を返すときによく起きます。
• •不完全なチェーン。中間証明書が欠け、一部のクライアントがルートまでの経路を構築できません。ブラウザは往々にして隠しますが、API クライアントやモバイルスタックは隠しません。
• •レガシープロトコルが有効なまま。TLS 1.0 / 1.1 を現行版と併存させると、誰も使っていなくてもスコアを押し下げます。
• •弱いスイート、または前方秘匿性なし。静的 RSA 鍵交換は、秘密鍵が盗まれると記録済みの通信が復号されることを意味します。
• •ハンドシェイク失敗。サーバーがプローブ自体を拒否します。SNI の厳格な要求や、非ブラウザクライアントを遮断するファイアウォール規則が原因のことが多いです。

順番に切り分ける

まず証明書の問題と設定の問題を分けます。証明書が期限切れや不一致なら、それが直るまで他は見ません。証明書が問題なければ次はプロトコル一覧です。証明書の有効性に次いで、低評価の最大の要因です。

CertH のドメインレポートは 5 つの評価領域のどれで点を落としたか、具体的な減点と直し方まで表示します。フルスキャンを手で読むよりたいてい速いです。

# What does the certificate actually cover?
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName -dates

# Which protocols does the server accept?
for v in tls1 tls1_1 tls1_2 tls1_3; do
  printf '%s: ' "$v"
  echo | openssl s_client -connect example.com:443 -$v -servername example.com 2>/dev/null | grep -q "Protocol" && echo yes || echo no
done

SNI の罠

多数のドメインを載せるサーバーは SNI で証明書を選びます。なかには SNI を必須にして、付けないクライアントを拒否する構成があります。ブラウザには問題ありませんが、監視ツール、古い Java クライアント、一部の API ライブラリが壊れます。スキャナがハンドシェイク失敗を報告するのにブラウザは正常な場合、まずこれを疑ってください。

FAQ