製品を見る
無料でお試し
jaja
Deutschドイツ語DEEnglish英語ENEspañolスペイン語ESSvenskaスウェーデン語SVSuomiフィンランド語FIDanskデンマーク語DA한국어韓国語KONederlandsオランダ語NLItalianoイタリア語ITÍslenskaアイスランド語ISNorskノルウェー語NO日本語日本語JA

英語で執筆し、Claude が翻訳しています。訳文に気になる点があればお知らせください。

証明書のユースケース

サーバーを検証し、証明書チェーンで信頼を築き、暗号化された安全な接続を実現するTLS証明書によって、Webサイトと利用者を保護します。

証明書のユースケース

Transport Layer Security（TLS）

クライアントがサーバーから証明書を受け取る際に確認すべき2つの問い

  1. その証明書は有効で信頼できるか。クライアントは、証明書が信頼された認証局（CA）によって発行され、期限切れでも失効済みでもないことを検証する必要があります。これには、証明書の有効期間の確認と、クライアントが信頼する認証局によって署名されていることの確認が含まれます。
  2. その証明書はサーバーの身元と一致するか。クライアントは、Common Name（CN）やSubject Alternative Name（SAN）といった証明書の内容が、サーバーのドメイン名と一致することを確かめる必要があります。これにより、その証明書が接続しようとしているサーバーのために発行されたものであることを確認できます。

クライアントによる証明書の信頼性の検証

  1. 証明書の信頼チェーンの確認：クライアントは、サーバーの証明書、中間証明書、ルート証明書からなる証明書チェーンを検証します。チェーン内の各証明書は、その1つ上位の機関によって署名されていなければならず、最終的に信頼されたルート証明書に行き着く必要があります。
  2. 証明書の有効期間の検証：クライアントは証明書の有効期間を確認し、期限切れでないこと、およびまだ有効になっていない状態でないことを確かめます。これには、証明書の「Not Before」と「Not After」の日付の確認が含まれます。
  3. 証明書とサーバーの身元の照合：クライアントは、証明書のCommon Name（CN）またはSubject Alternative Name（SAN）がサーバーのドメイン名と一致することを確かめます。これにより、その証明書が接続先のサーバーのために発行されたものであることが確認できます。
  4. 失効の確認：クライアントは、証明書失効リスト（CRL）への問い合わせ、またはOnline Certificate Status Protocol（OCSP）の利用によって、証明書が失効していないかを確認します。失効した証明書はもはや信頼されません。
  5. デジタル署名の検証：クライアントは証明書のデジタル署名を検証し、改ざんされていないことを確かめます。これには、発行元の認証局の公開鍵に照らして暗号署名を確認する作業が含まれます。

クライアントによるサーバーが証明書の真の所有者であることの検証

  1. 証明書チェーンの検証：クライアントは証明書チェーンを検証し、チェーン内の各証明書が信頼された認証局（CA）によって署名されていることを確かめます。このチェーンはサーバーの証明書から始まり、信頼されたルート証明書で終わります。
  2. ドメイン名の照合：クライアントは、証明書のCommon Name（CN）またはSubject Alternative Name（SAN）がサーバーのドメイン名と一致することを確認します。これにより、その証明書が接続先のサーバーのために発行されたものであることが保証されます。
  3. デジタル署名の検証：クライアントは、発行元の認証局の公開鍵を使って証明書のデジタル署名を検証します。これにより、証明書が改ざんされておらず、信頼された認証局から確かに発行されたものであることが保証されます。
  4. 証明書の有効期間：クライアントは証明書の有効期間を確認し、現時点で有効であり期限切れでないことを確かめます。
  5. 失効状態の確認：クライアントは、証明書失効リスト（CRL）への問い合わせ、またはOnline Certificate Status Protocol（OCSP）の利用によって、証明書が失効していないかを確認します。失効した証明書はもはや信頼されません。

証明書の信頼性を確認済みでも所有者の確認が重要な理由

証明書の有効性と信頼：この手順では、証明書が信頼された認証局（CA）によって発行され、有効期間内にあり、失効していないことを確認します。これにより、その証明書が正当であり、改ざんされていないことが確かめられます。

サーバーの身元の検証：証明書が有効で信頼できるとしても、それが接続先のサーバーのものであることも確認しなければなりません。そのために、証明書のCommon Name（CN）またはSubject Alternative Name（SAN）がサーバーのドメイン名と一致することを確かめます。この手順によって、その証明書が特定のサーバーのために発行されたものであることが保証され、攻撃者が別のドメインの有効な証明書を提示する中間者攻撃を防げます。

クライアントがこの問いに答える2つの方法と、それぞれで生じる2つの結果

  1. Domain Name System（DNS）による検証：クライアントは、証明書のCommon Name（CN）またはSubject Alternative Name（SAN）がサーバーのドメイン名と一致することを確認します。
    結果：
    • 一致：名前が一致すれば、クライアントはその証明書が当該サーバーのために発行されたものだと確信して接続を継続できます。
    • 不一致：名前が一致しない場合、クライアントは接続を終了するか警告を表示し、セキュリティ上のリスクがある可能性を示します。
  2. 公開鍵基盤（PKI）による検証：クライアントは、発行元の認証局（CA）の公開鍵を使って証明書のデジタル署名を検証します。
    結果：
    • 署名が有効：署名が有効であれば、その証明書が改ざんされておらず、信頼された認証局から発行されたことが確認できます。
    • 署名が無効：署名が無効な場合、クライアントは接続を終了するか警告を表示し、その証明書が侵害または偽造されている可能性を示します。

使用する方法を決める要因

Domain Name System（DNS）による検証：

  • 用途：この方法はTLSハンドシェイクの一部として常に使用されます。クライアントは、証明書のCommon Name（CN）またはSubject Alternative Name（SAN）をサーバーのドメイン名と照合し、一致することを確認します。
  • 決定要因：これはTLSプロトコルの標準的な一部であり、安全な接続を確立する際にクライアントが自動的に実行します。

公開鍵基盤（PKI）による検証：

  • 用途：この方法もTLSハンドシェイク中に常に使用されます。クライアントは、発行元の認証局（CA）の公開鍵を使って証明書のデジタル署名を検証します。
  • 決定要因：これもTLSプロトコルの標準的な一部です。クライアントは、証明書が有効で改ざんされていないことを確かめるため、この確認を自動的に実行します。

サーバーがクライアントに送るべき証明書

TLSハンドシェイクにおいて、サーバーは次の証明書をクライアントに送る必要があります。

  • エンドエンティティ証明書：サーバー自身の証明書であり、クライアントに対して自身の身元を証明します。
  • 中間証明書：エンドエンティティ証明書を信頼されたルート証明書に結び付ける証明書です。サーバーの証明書から信頼されたルート証明書までの信頼チェーンを確立するのに役立ちます。

Domain Validation証明書とExtended Validation証明書

Domain Validation（DV）証明書は、認証局（CA）が申請者によるドメインの管理権限を検証するタイプのTLS証明書です。検証は通常、次の方法で行われます。

  • ドメインの管理者連絡先に送られたメールに返信する。
  • DNSのTXTレコードを追加する。
  • Webサーバーにファイルをアップロードする。

主な特徴：

  • 迅速な発行：検証が最小限で済むため、多くの場合数分以内に発行できます。
  • 基本的なセキュリティ：暗号化と、ドメインが証明書の要求者によって管理されているという基本的な保証を提供します。
  • 費用対効果：安価または無料であることが多く、小規模なWebサイトや個人のプロジェクトでも利用しやすくなっています。

Extended Validation（EV）証明書は、より厳格な検証手続きを要する上位のTLS証明書です。認証局は、証明書を要求する主体の法的、物理的、運用上の実在性を検証します。これには次の確認が含まれます。

  • 主体の法的な身元と状態の確認。
  • 主体の物理的および運用上の実在の検証。
  • 主体がそのドメインを使用する排他的な権利を有していることの確認。

主な特徴：

  • 高い保証水準：徹底した審査を伴うため、利用者に最も高い水準の信頼と保証を提供します。
  • 視覚的な表示：一部のブラウザーでは、かつてEV証明書がアドレスバーに組織名を表示していましたが、現在ではあまり見られません。
  • 信頼の向上：金融機関やeコマースサイトなど、機微な情報を扱うWebサイトに適しています。

安全性の比較

Extended Validation（EV）証明書は、厳格な検証手続きを経るため、一般にDomain Validation（DV）証明書より安全だと考えられています。両者を比較すると次のようになります。

Domain Validation（DV）証明書

  • 検証水準：ドメインの管理権限のみを検証します。
  • セキュリティ：基本的な暗号化と保証を提供します。
  • ユースケース：個人のWebサイト、ブログ、小規模事業者に適しています。

Extended Validation（EV）証明書

  • 検証水準：主体の法的、物理的、運用上の実在性を検証します。
  • セキュリティ：徹底した審査により、より高い水準の信頼と保証を提供します。
  • ユースケース：金融機関、eコマースサイト、機微な情報を扱うあらゆるWebサイトに適しています。

EV証明書のほうが安全な理由：

  • 徹底した審査：EV証明書は広範な検証を必要とするため、悪意ある主体が取得するのは困難です。
  • 信頼の指標：現在ではあまり見られませんが、EV証明書はかつてブラウザーのアドレスバーに組織名を表示し、利用者に目に見える保証を与えていました。
  • より高い保証水準：詳細な検証手続きによって証明書の背後にいる主体が正当であることが確かめられ、フィッシングをはじめとする攻撃のリスクを減らせます。

OCSPステープリングによる失効確認の流れ

OCSPステープリングは、遅延を減らしプライバシーを高めることで、標準のOCSPの仕組みを改善します。その仕組みは次のとおりです。

  1. サーバーがOCSPレスポンスを要求：Webサーバーは、自身の証明書の失効状態をOCSPレスポンダー（認証局が運用するサーバー）に定期的に問い合わせます。この要求はバックグラウンドで行われ、クライアント接続のたびに行われるわけではありません。
  2. OCSPレスポンダーが応答を返す：OCSPレスポンダーは、証明書の状態（「good」「revoked」「unknown」など）を示す、署名済みでタイムスタンプ付きのOCSPレスポンスを返します。サーバーはこのレスポンスをキャッシュします。
  3. ステープルされたレスポンスを伴うTLSハンドシェイク：クライアント（Webブラウザーなど）がサーバーへの接続を開始すると、サーバーはキャッシュしたOCSPレスポンスをTLSハンドシェイクに含めます。これがレスポンスをハンドシェイクに「ステープルする」と呼ばれる動作です。
  4. クライアントがOCSPレスポンスを検証：クライアントはステープルされたOCSPレスポンスを検証します。レスポンスは認証局によって署名されているため、クライアントはその有効性を信頼できます。レスポンスが証明書の失効を示していれば、クライアントは安全な接続を確立しません。
  5. 定期的な更新：サーバーはキャッシュしたOCSPレスポンスを定期的に更新し続け、TLSハンドシェイクの際に常に最新の状態を提示できるようにします。

この仕組みによってクライアントが個別にOCSP要求を行う必要が減り、性能とプライバシーが向上します。