SSL/TLS チェッカー

SSL/TLS チェッカーでできること

対象ホストへ実際に TLS 接続し、ネゴシエートされたプロトコル、暗号スイート、証明書の Subject、 Issuer、SAN、有効期限、指紋を確認します。RFC 8446 は TLS が盗聴、改ざん、メッセージ偽造を防ぐ ための安全なチャネルを提供する仕様として TLS 1.3 を定義しています。

プロトコル/暗号スイート別の確認ポイント

TLS 1.0/1.1 脆弱性と現行設定

RFC 8996 は TLS 1.0 / 1.1（および DTLS 1.0）の使用を禁止（MUST NOT be used）しています。 「非推奨」ではなく規範的な禁止である点が重要です。主な理由は、古い暗号スイート、 TLS 1.2 より前の AEAD 不足、SHA-1 を使う古いハンドシェイクや署名の問題、そして設定ミスを 招きやすい互換性維持です。

よくある場面

• 証明書更新後に実際の公開 endpoint が新しい証明書を返しているか確認する。
• ロードバランサ、CDN、オリジンサーバーで SNI ごとに証明書が一致しているか確認する。
• 監査前に TLS 1.0 / 1.1 が接続可能なまま残っていないか確認する。
• 任意ポートの SMTP STARTTLS 前段や管理画面など、443 以外の TLS を確認する。

結果の読み方／次の一手

• TLS 1.0 / 1.1 または SSLv3 が表示されたら、サーバーやロードバランサの protocol 設定を見直します。
• 証明書の SAN に検査ホスト名がない場合は、SNI、証明書選択、DNS の向き先を確認します。
• 残り日数が短い場合は更新だけでなく、反映先すべてで新証明書が返るかを再チェックします。
• 暗号スイートが想定と違う場合は、TLS 終端箇所が CDN かオリジンかを切り分けます。

よくある質問

TLS 1.0 / 1.1 に対応していると危険ですか？

RFC 8996 は TLS 1.0 / TLS 1.1 の使用を禁止しています（MUST NOT be used）。単なる非推奨ではなく規範的な禁止で、古い暗号スイート・AEAD の不足・SHA-1 依存などの問題があるため、公開サービスでは TLS 1.2 以上だけに絞ります。

cipher suite は何を見ればよいですか？

TLS 1.3 では AEAD 暗号スイートだけが使われます。TLS 1.2 では ECDHE などの前方秘匿性、AEAD の AES-GCM や ChaCha20-Poly1305、証明書の署名アルゴリズムを確認します。

SNI を指定する必要はありますか？

同じ IP アドレスで複数証明書を出し分けるサーバーでは SNI が必要です。通常はホスト名と同じ値を使いますが、IP 直打ち検証や別名検証では SNI 欄で明示できます。

証明書の残り日数だけで十分ですか？

有効期限だけでは不十分です。Subject Alternative Name、発行者、鍵種別、指紋、SNI で返る証明書の一致も確認し、更新後は実際の接続結果で反映を確認してください。