web-dev-qa-db-ja.com

証明書を取り消す責任は誰にありますか?

CAはクライアント/サーバーに証明書を発行します。要求がクライアント/サーバーによって行われるときはいつでも、証明書は身元を確認するために使用されます。

さて、証明書を取り消す必要がある場合、誰がどのようにしてどのように取り消しますか?クライアント/サーバーは失効したものとして「マーク」しますか?または、CAはそれを行いますか? CAがそれを行う場合、何を取り消すべきかをCAはどのようにして知るのでしょうか?

また、取り消されたことを示すフィールドが証明書にありますか?または、取り消されたすべての証明書を含む証明書のブラックリストがどこかに保持されていますか?

24
ritratt

answer by user2320464 は良いですが、もっと拡張したいと思います。


概要:失効の全体のポイントはこの証明書の所有者が信頼できないことを通知することであるため、証明書所有者は通常、自分の失効情報を管理しません。証明書の正当な所有者は、証明書が失効したことを宣言できる必要がありますが、秘密鍵も持っている攻撃者が失効を「取り消す」ことはできません。証明書の所有者自身が信頼できない場合は、その意志に反して証明書を取り消す方法が必要です。

私たちが見つけた最良のソリューションは、サードパーティが失効情報(通常は証明書を発行したCA)を追跡することです。彼らはブラックリストを維持し、「証明書#28277392は取り消されていますか?」というオンライン要求に応答することもできます。


失効が醜い理由

失効は本当に証明書の世界では醜いアヒルの子です。それを処理するためのエレガントな方法はまだ見つかっていません。難しいのは、一見矛盾する要件があるためです。

  1. サーバーがクライアントに証明書を渡すと、クライアントは証明書が取り消されたかどうかを認識できるはずです。

  2. サーバーは、自身の証明書の失効情報を生成または渡す責任を負うべきではありません。それは、クッキーがまだそこにあるかどうかを確認し、うそをついていないことを犬に尋ねるようなものです。

  3. したがって、CAは証明書ごとに失効情報を動的に生成する必要があります。 (または少なくともそれを追跡し、ブラックリストを毎時または毎日公開します)。

  4. 証明書の優れた点の1つは、署名を検証するためのすべてのデータが含まれていることです。これは、オフラインで非常に高速に実行できます。

  5. ただし、失効はリアルタイムで行う必要があります。失効する時点がわからないため、最初の証明書にそれを入れて忘れることはできません。

  6. クライアントが証明書の検証ごとにCAに直接連絡する必要がある場合、オフラインで証明書を検証することは不可能であり、ネットワークラグを追加します。

現在使用されている2つの主要な失効メカニズムがあります。CRLとOCSP(下記を参照)ですが、どちらも本当にエレガントなソリューションではありません。


証明書が取り消される理由

あなたのコメント

クライアント/サーバーは失効したものとして「マーク」しますか?

証明書が取り消される理由を完全に理解していないと私を信じさせます。通常、証明書を取り消す理由は3つあります。

  1. 証明書の正当な所有者がそれを悪用しています。通常、これは、発行してはならない証明書を発行しているサブCAです。彼らの証明書は取り消され、もはや彼らを信頼しないように世界に告げる。

  2. サーバーが廃止されたか、何らかの理由で証明書が不要になった。

  3. 証明書に対応する秘密鍵の鍵侵害。正当な所有者とハッカーのどちらに話しているのかわからなくなったため、この証明書に対して署名または暗号化されたものを信頼することはできなくなりました。

ケース2)の場合、証明書の所有者は、提案した方法で自分の証明書に失効のフラグを立てることができますが、他の2つのケースでは、攻撃者は失効する前の古いバージョンの証明書を使用できます。そのため、失効は実際には、証明書所有者の管理外であるサードパーティによって処理される必要があります。通常、それは証明書を発行したCAによって行われます。

証明書を取り消すには、通常、CAに連絡し、本人であることを証明し、証明書の取り消しを要求します。証明書を取り消す前に必要な証明のレベルはCAごとに異なると思います。これは、攻撃者が証明書をサービス拒否として取り消すことを要求するのを防ぐためです。サーバー証明書などのエンドユーザー証明書の場合、失効は自動的に行われることが多く、ネットワークメッセージに証明書の秘密鍵で署名するだけで十分です(つまり、証明書自体を取り消すことができます)。サブCAのような価値の高い証明書を取り消すには、IT作業とクリーンアップを行う必要があり、エンドユーザー証明書を移行して再発行し、罰金を支払う必要があるなど、取り消しは両社の多くの人々が関わる大事件。


証明書が取り消される方法

取り消されたすべての証明書を含む、どこかに維持されている証明書のブラックリストはありますか?

はい。最も単純なメカニズムは Certificate Revocation List(CRL) と呼ばれます。これはまさに期待通りです。つまり、取り消されたすべての証明書のシリアル番号のリストです。各CAは、発行したすべての証明書の失効ステータスを追跡し、新しいCRLを1時間ごとまたは毎日発行します。 CRLはCAキーで署名されているため、改ざんされません。これは、ダウンロード、パススルー、wtvできる.crlファイルです。これはセミオフラインで使用でき、24時間ごとに接続して更新する限り、オフラインで使用できます(もちろん、次のCRLまで、侵害された証明書と通信しているかどうかを知る方法はありません)リフレッシュ)。

より複雑な「クラウドフレンドリーな」メカニズムは Online Certificate Status Protocol(OCSP) と呼ばれます。クライアントはCAへの直接接続を開き、尋ねます

クライアント:「ねえ、あなたが発行した証明書を持っています#9388038829188、それでもいいですか?」

CA:「うん、それはまだいい」.

これにより、CRLの遅延の問題は解決されますが、クライアントがオンラインである必要があり、暗号プロセスにネットワークラグが追加されます。

2011年に OCSP Stapling と呼ばれるシステムが導入されました。これにより、サーバーはCAからOCSP応答をプリフェッチして(たとえば、5分ごとに1回)、クライアントに渡すときに証明書とバンドルすることができます。特に、クライアントの暗号化を高速化して証明書を検証します。これには、必要なすべてのローカルコピーがあり、新しいネットワーク接続は必要ないためです。これは、TLS(https、ftps、ssh、vpnなど)のエレガントなソリューションと見なされています。インターネットにアクセスできるサーバーへの接続を開いていますが、ログのようなTLS以外の証明書の使用に対する失効は解決しませんPKIスマートカードを使用してWindowsにログインし、コード署名されたソフトウェア(モバイルアプリなど)を起動し、署名されたPDFドキュメントなど)を開きます。これは、接続していない場合でも機能しますインターネット。


エンドユーザーに渡される方法

取り消されたことを示すフィールドが証明書にありますか?

はい、X.509証明書(SSLなど)では、CRLを見つけることができるアドレスはCRL Distribution Pointフィールドに入り、OCSPアドレスはAuthority Information Accessフィールドに入ります。たとえば、このページを保護している*.stackexchange.comの証明書には、次のものが含まれています。

[1]CRL Distribution Point
     Distribution Point Name:
          Full Name:
               URL=http://crl3.digicert.com/sha2-ha-server-g5.crl
[2]CRL Distribution Point
     Distribution Point Name:
          Full Name:
               URL=http://crl4.digicert.com/sha2-ha-server-g5.crl

[1]Authority Info Access
     Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
     Alternative Name:
          URL=http://ocsp.digicert.com
          URL=http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt
30
Mike Ounsworth

通常、証明書は、証明書の発行者によって取り消されます。したがって、SSL証明書を購入し、後で秘密鍵が危険にさらされていることに気付いた場合は、証明書を取り消すことになります。このアクションは「発行CA」に記録され、新しく失効した証明書のシリアル番号が証明書失効リスト(CRL)に表示されるか、オンライン証明書ステータスプロトコル(OCSP)を介して提供されます。どちらも使用する必要はありませんが、どちらも発行CAによって管理されます。 CRLおよびOCSPの場所は、証明書内で公開されます。理論的にはこれは素晴らしいことですが、問題は、すべてのクライアントが失効リストを必要なほど注意深くチェックするわけではないことです。

5
user2320464

証明書を暗号で無効にする方法はないため、システムを使用して証明書の失効を公に発表する必要があります。オンライン証明書ステータスプロトコル(OCSP)は、これを行う現在の方法です。ブラウザーは、OCSPプロバイダーをチェックして、Webサイトに接続する前に証明書が取り消されていないことを確認できます。

3
multithr3at3d

証明書のセキュリティを確保するのは、証明書を購入した人の責任です。

利用規約に違反していることが判明した証明書を取り消すのは、CAの責任です。

証明書は運転免許証によく似ています。誰かが盗んだ場合は、報告する必要があります。

2
user4294507

Webサイトの運営者はCAに証明書を取り消すように通知する責任があり、通常は同時に新しい証明書を再発行します。

次に、CAは、CRLまたはOCSPを介してこの情報を公開する責任があります。

クライアントアプリケーションは、CAから証明書のCRL/OCSPステータスを取得する責任があります。

まれに、CAが一方的に証明書を取り消す場合があります。これは、たとえば、証明書の所有者が証明書の使用条件に違反しているとCAが判断した場合、またはCAが内部違反を検出した場合、またはCAが証明書が発行または不正に使用されたと判断した場合に発生する可能性があります。 CAが証明書を取り消す可能性のある状況は、CAの証明書実務声明に開示されています。CAは、ブラウザのデフォルトの権限リストに含める要件の一部として公的に公開する必要があります。

1
Lie Ryan