TLS証明書インスペクター

証明書は何のためにあるのか

ブラウザがhttps://example.comに接続すると、何かが応答します。その何かが本当にexample.comのものかどうかは、別の問題です。途中のネットワークにいる誰かが代わりに応答した可能性もあります。

そこでサーバーは身分証を見せる必要があります。証明書は小さなファイルで、公開鍵、その鍵が代表してよいホスト名の一覧、開始日、終了日、そしてそれらの名前を誰が管理しているか確認した認証局（CA）の署名が入っています。ブラウザは順番に確認します。アドレスバーの名前が証明書に載っていること。今日が2つの日付の間にあること。署名をたどると、端末がすでに信頼している認証局に行き着くこと。そしてサーバーが対応する秘密鍵を持っていると証明すること。どれか1つでも欠ければ、訪問者には全画面の警告が表示されます。

暗号化が始まるのは、そのすべてが確認できてからです。鍵マークは、サーバーが身元を証明したことを意味し、暗号化はその証明の上に成り立っています。

インスペクターがテストする項目

443番ポートに2回接続します。1回目はどんな証明書でも受け入れ、状態にかかわらず証明書を読み取ります。2回目は、厳格なクライアントと同じように、標準の信頼済みルート証明書の一覧に照らしてすべてを検証します。

そのあと、アドレスの4つの形（httpとhttps、wwwありとなし）をリクエストし、それぞれの最終的な行き先と、サイトがHSTSヘッダーを送っているかを表示します。この部分を1ステップずつ見たい場合は、リダイレクト追跡を使ってください。

Chromeでは動くのに、ほかでは失敗する

認証局はルート鍵で直接あなたの証明書に署名するわけではありません。中間証明書で署名し、その中間証明書にルートが署名しています。端末が保存しているのはルートだけなので、サーバーは自分の証明書と一緒に中間証明書も送る必要があります。この2つを合わせたものがチェーンです。

サーバーが自分の証明書しか送らない場合でも、デスクトップ版のChromeとEdgeは寛容です。足りない中間証明書をダウンロードしたり、別のサイトで見たものを再利用したりすることがよくあります。新しいプロファイルのFirefox、古いAndroidスマートフォン、curl、決済のWebhook、メールサーバー、ほとんどのプログラミングライブラリは、そこまでしてくれません。こうして、持ち主には完璧に見えるのにAPIクライアントでは失敗するサイトができあがります。インスペクターはこれを不完全なチェーンと呼び、検証に失敗して証明書が1枚しか送られていない場合に報告します。

よくある失敗の直し方

• 期限切れ。自動発行の証明書は期限の約30日前に更新されます。期限が切れたなら、更新処理は何週間も失敗し続けていたということです。Certbotならcertbot renew --dry-runを実行してエラーを読んでください。原因はたいてい、移動したDNSレコード、80番ポートを閉じているファイアウォール、/.well-known/acme-challenge/を飲み込んでしまうリダイレクトです。
• 名前が対象外。すべてのホスト名を並べて証明書を取り直します：certbot -d example.com -d www.example.com。ワイルドカードの*.example.comがカバーするのはサブドメイン1階層だけです。example.com自体はカバーされず、多くの人がここでつまずきます。
• 不完全なチェーン。サーバーにフルチェーンのファイルを指定します。nginxならssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;。Apache 2.4.8以降では、SSLCertificateFileに同じファイルを指定します。
• 自己署名。公的な認証局の証明書に置き換えます。Let’s Encrypt、ZeroSSL、Google Trust Servicesは無料で発行しています。
• 古いプロトコル。TLS 1.2と1.3を有効にします。nginxならssl_protocols TLSv1.2 TLSv1.3;

ターミナルからもopenssl s_client -connect example.com:443 -servername example.comで同じ内容を確認できます。