本文へスキップ

SSL証明書チェック

SSL Certificate Checker

ホストに接続して配信されている証明書チェーン・有効期限・対応プロトコルと暗号を表示し、チェーンの欠けを指摘します。

ホストへTLSで接続して、実際に配られたものをそのまま報告します。リーフからルートまでの証明書チェーン、それぞれの残り日数、サーバーが受け入れるプロトコル版と受け入れない版、そして合意された暗号スイート。すべてデータベースではなく、その場のハンドシェイクから出た結果です。

☁️ サーバーを使いますssltlscertificatesecurity

このリクエストは、こちらのサーバーが代わりに送ります。サーバーに渡るのはホスト名だけで、ブラウザの Cookie やログイン状態は一緒に送られません。サーバーは公開アドレスにしか接続せず、プライベートアドレスや内部アドレスへの接続は拒否します。

既定は 443 番です。TLS で接続が始まる他のポート — 8443・465・993・995・636・853 — は受け付けますが、それ以外は受け付けません。ホスト名は SNI で送るので、IP を共有していても正しい証明書が返ってきます。

使い方

  1. ホストを入れます(443以外ならポートも)

    example.com、またはexample.com:8443です。接続した直後からTLSで始まるポート(8443・465・993・995・636・853)は使えます。587のようにSTARTTLSで上げるポートは使えません。

  2. 判定を見てから、個々の項目を読みます

    判定は下に並ぶ項目の要約で、項目ごとに良好・参考・注意・問題のいずれかが付きます。実務でいちばん効いてくるのは、30日以内の期限切れと、欠けたチェーンの2つです。

  3. リーフだけでなくチェーンの並びを見ます

    サーバーが送ってきた順序のまま表示します。中間証明書を省いたサーバーはChromeでは動き(Chromeが足りない分を取りに行きます)、curlや古いAndroidでは失敗します。何週間も「自分の環境では動く」で居座る種類の不具合です。

  4. どのプロトコル版を受け入れるかを見ます

    版ごとに別の接続で試すので、その行は推論ではなくサーバーについての事実です。TLS 1.0と1.1を受け入れているなら手を打つ価値があります。RFC 8996で廃止された版です。

よくある質問

証明書は正常なのにブラウザが警告します

たいていはチェーン・名前・時計のどれかです。中間証明書をサーバーが一緒に送っているか、入力しているホストがSANの一覧にあるか(ブラウザはCNをまったく見ません)、端末の日付が合っているかを確かめてください。時計の狂った端末は、何の問題もない証明書を拒否します。

内部のサーバーも確認できますか

できません。接続はこちらのサーバーから出ていき、その経路はプライベートとループバックのアドレスを拒否します。内部のホストなら、openssl s_client -connect host:443 -servername host で同じチェーンを手元で見られます。

1つのIPに複数サイトなのに、なぜ正しい証明書が返るのですか

ハンドシェイクのときにホスト名をSNIとして送っているからです。サーバーはそれを見てどの証明書を出すかを決めます。IPアドレスだけでは確認できない理由も同じです。

失効も確認しますか

しません。OCSPもCRLも問い合わせないので、失効済みでも期限内の証明書はここでは正常に見えます。実際の限界です。このツールが見せるのは、サーバーが何を配ったかと、チェーンと日付が成立しているかまでです。

ここから渡せます

次の一手

このツールが出したものをそのまま受け取れる道具です。