TLSにおける証明書検証

証明書を検証しなければ、サーバーになりすました攻撃者との間にTLS接続が確立される可能性があります（中間者攻撃）。証明書の検証により、秘密鍵を管理する正規のサーバーと通信していることを確認できます。

主なフィールドは、Subject（証明書の所有者）、SubjectAltName（DNS名またはIPアドレス）、Issuer（署名したCA）、Validity（notBefore/notAfter）、Public Key、Signatureです。ブラウザーはこれらをすべて確認します。

サーバー証明書 → 中間CA証明書 → ルートCA証明書という構成になります。ルートCAは自己署名され、OSやブラウザーの信頼ストアにあらかじめインストールされています。サーバーはTLSハンドシェイクのCertificateメッセージで、自身の証明書と中間証明書を送信します。

各証明書は、その1つ上位の発行者によって署名されます。クライアントは、public_key(cert_{n+1})を使ってsignature(cert_n)を検証します。いずれかの署名が無効であれば、チェーンは拒否されます。ルートは署名によってではなく、事前にインストールされていることによって信頼されます。

クライアントは、サーバーのホスト名が証明書のSubjectまたはSubjectAltName（DNSエントリ）と一致するかを確認します。ワイルドカード（*.example.com）は1つのラベルに一致します。2000年以降、ホスト名の照合ではCNよりSANが優先されます。

クライアントは、チェーン内のすべての証明書について、notBefore ≤ now ≤ notAfterを確認します。署名が有効でも、期限切れの証明書は拒否されます。証明書の有効期間は短縮されており、現在のブラウザーでは約398日が上限です。

CAはCertificate Revocation List（CRL）を公開します。これは、失効した証明書のシリアル番号をまとめた署名付きリストです。クライアントは、証明書のCRL Distribution Points拡張からCRLのURLを取得し、その中にシリアル番号が含まれているかを確認します。

Online Certificate Status Protocol（OCSP）を使うと、クライアントはCAのOCSPレスポンダーに対して、1つの証明書の状態を問い合わせられます。CRLより高速ですが、遅延が追加されます。OCSP Staplingでは、サーバーが署名付きOCSP応答をTLSハンドシェイクに含めます。

CT（RFC 6962）は、CAに対して、発行したすべての証明書を公開された追記専用ログに記録するよう求めます。ブラウザーは、証明書またはTLS拡張に含まれるSigned Certificate Timestamps（SCT）を確認します。これにより、不正な証明書発行が発見されないままになることを防ぎます。

HTTP Public Key Pinning（HPKP、非推奨）やモバイルアプリの証明書ピンニングでは、特定の公開鍵または証明書ハッシュをピン留めします。サーバーが別の証明書を提示すると、たとえその証明書が有効でも接続は拒否されます。これにより、CAの侵害を利用した攻撃を防ぎます。

ERR_CERT_AUTHORITY_INVALID：ルートが信頼されていません。ERR_CERT_DATE_INVALID：期限切れです。ERR_CERT_COMMON_NAME_INVALID：ホスト名が一致しません。NET::ERR_CERT_REVOKED：OCSPまたはCRLで失効と判定されました。それぞれ、特定の検証手順の失敗に対応しています。

OCSP Staplingによって何が実現されますか。

TLSの証明書検証には、チェーンの検証、署名の確認、名前の照合、有効期間の確認、失効確認が含まれます。次は、TLSの歴史的な攻撃と、TLS 1.3がそれらをどのように軽減するかを学びます。