11月 25, 2020
Articles
コメントはまだありません

自己署名証明書を作成する場合、CA.crtはクライアントマシンにインストールされることになっていますか？

OpenSSL C APIを使用しようとしていますが、これはまだ比較的新しいので、さまざまな情報が混在しています。したがって、アイデア/意見/説明を求めるのが賢明だと思います。

とにかく、クライアントプログラムでは、「TrustStore」を含む証明書またはディレクトリをロードする必要があります。これは、そのサーバー用に独自のSSL証明書を作成する場合、サーバーのCA証明書自体？

その場合、中間CAはルートCAの代わりにこの目的で機能しますか？

私は正しい方向に進んでいると思います。ただし、これに関して矛盾する情報を聞いたので、実際の間違いを防ぐために、いくつかの説明が必要でした。クライアントにはルートCA自体が必要であると言う人もいれば、中間CAのみをインストールすると言う人もいます。論理的なように思われるセキュリティ上の理由。

クライアント接続に関して信頼の連鎖がどのように機能するかについては、一般的に少し混乱しています。私は実際にCSRを生成し、Webサーバーに証明書をインストールするだけでよいので、クライアント側のものは私にとってちょっと新しいものです。

この質問は元々ここのStackOverflowで、info-secコミュニティに質問することをお勧めしました。

コメント

  • 間違ったフレーズを使用していると思います。自己署名証明書は、発行者証明書が証明書自体である証明書です。おそらく代わりに、独自のCAによって署名された証明書を意味します。この場合：通常、ルートCAはトラストストアに配置され、ルートCAによって署名された中間証明書と、中間証明書によって署名されたリーフ証明書がTLSハンドシェイク中に送信されます。 。
  • SSL / TLS PKIの重複の可能性

回答

tl; dr 証明書にCA:TRUEのバリエーションが含まれている場合は、配布するのが理にかなっています。含まれていない場合は、配布するメリットはありません。

信頼の連鎖自体は、証明書の構造の観点から説明できます。

サーバーの証明書から開始する場合（つまり、通常、Apacheに使用する証明書）：

  • サーバー証明書は、指定したCSRに基づいて認証局によって生成されます。そのCSRには、公開鍵と、CAが使用することに関心がある場合とない場合があるその他の情報が含まれています。
  • CAはCSRを受け取り、（通常）中間CAを使用して署名付き証明書を作成します。証明書には2つの公開鍵があります。1つはサブジェクト用（CSRから抽出された公開鍵）で、もう1つは発行者用で、CAの中間証明書です。
  • CA ” ■中間証明書は、それ自体が署名付き証明書（いくつかの特別なオプションを含む）であり、サブジェクトキーは中間CAの公開鍵（サーバー証明書の発行者公開鍵にあるものと同じ公開鍵）になります。署名（または発行）キーは、CAのルート証明書になります（または、別の中間証明書になります）。
  • CAのルート証明書は（通常）自己署名証明書です。実際には、これは発行者キーとサブジェクトキーが同じ公開キーであることを意味します。

これは、実際に証明書を確認することで確認できます。例：

$ openssl s_client -connect google.com:443 < /dev/null CONNECTED(00000003) depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority

これが構築する信頼の連鎖は、次のように要約できます（「 bottom “-Equifax証明書）：

  • ルートCA（Equifax）は、日常のアクティビティを中間CA（GeoTrust）に委任し、この事実を表す証明書に署名します（つまり、CAの設定： TRUE、KeyUsage：keyCertSign）。言い換えると、ルートCAは、中間者に代わって証明書を発行することを「信頼」します（できれば、一連の必須の検証手順を完了した後）。
  • このチェーンでは、中間者（Geotrust）はさらにGoogle CA（CN = Google Internet Authority G2）に委任しました。
  • 委任者（別名Google中間CA）はCSRに署名します。これは、事実上、特定の情報を示す文書です。名前のセット（t CN、および場合によってはサブジェクト代替名）、秘密/公開鍵のペアは有効/信頼されています（ここでの信頼は、特定の名前について話すという主張を検証したという事実から来ています-この場合、GoogleCAは* .google.comの証明書）。

（ルート）CAは通常、自己署名されていることに注意してください。CAは、人々に証明書を発行しないようにするために感じられる一連のプロセスと手順に従うため、一般的に信頼されています。誰がそれらを持ってはいけません。だから私は外に出て、自分がグーグルだという証明書を取得することができません。したがって、これは一種の規則です（正式なメカニズムに裏打ちされていますが）。独自のCAを開始する場合、そのルート（および中間）証明書を配布すると、他のCAの証明書を配布するのとまったく同じことが実現します。証明書が発行されます。そのCAによって、システムによって有効な（つまり信頼できる）ものとして受け入れられます。

より実用的な用語では、トラストストア（openSSL用）は、特定の命名規則を持つファイルの集まりです。 https://www.openssl.org/docs/faq.html#USER5 を参照してください：

いつ証明書は、ルートCAがOpenSSLによって「信頼」されている必要があることを確認されます。これは通常、CA証明書をディレクトリまたはファイルに配置し、関連するプログラムがそれを読み取るように構成する必要があることを意味します。

そのディレクトリは/ etc / ssl / certsです（RHのようなものには/ etc / pkiなどの他のものがあります）。

https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu#719047 は、ストアに証明書を追加する方法の概要を示しています。 https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate 、

短いバージョンは update-ca-certificates はプロセスを自動化し、一般的に使用されるツールです。

少し長いバージョンでは、証明書をハッシュで保存する必要があります（たとえば、 openssl x509 -hash -in cert.pem）の出力で、openSSLがチェーンを効率的に検証できるようにします。

https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html 」を参照してください。

コメントの質問に回答するためにを更新：

サーバー証明書この説明では、信頼の連鎖に基づいて、信頼できるかどうかを定義します。 （例）curl https://google.comがどのように機能するかを考えると、少し理解しやすくなります。

  • curlはgoogleへのTLS接続を開き、証明書。
  • curlはその「エンドユーザー」証明書、つまりサーバーの証明書を調べ、特に発行者を探します。
  • 発行者が「既知」の場合トラストストアでは、トラストチェーンの残りの部分が検証されます（つまり、サーバー証明書の発行者の証明書がチェックされ、 それ自体以外の発行者がいる場合は、その発行者がチェックされます）。完全な信頼チェーンを検証できる場合にのみ、証明書は有効と見なされます。

ただし、エンドユーザー証明書を含める必要がある場合は、信頼チェーンを配布することは絶対に非現実的です。そこにあるウェブサイトの数はわかりませんが、Alexaが上位100万を提供しているという事実に基づいて、100万を超えると推測されます。

これは一種のポイントです。信頼の連鎖：通常、発行者証明書を用意する必要がありますが、発行者が誰であるかがわかるため、最終証明書を配布する必要はありません。

そしてそれらがないことを確認できます。」これは、発行者の公開鍵（およびそれが適切な鍵であることを確立する信頼の連鎖）を確認し、エンドユーザー（つまりサーバー）の証明書が発行者の秘密の相手によって実際に署名されているかどうかを検証できるためです。公開鍵。

いいえ、エンドユーザーの証明書を配布するのではなく、信頼の連鎖のみを配布する必要があります。簡単に言うと、生成した証明書をすべてどこに配布するかです。 BasicConstraintsは（合法的に）少なくともCA：TRUEを言います。時間とディスクスペースの無駄なので、その条件を満たさないものは配布しないでください。 -CA：TRUEを 言わないものはすべて、行うものに対して検証できます。

コメント

  • つまり、どのような場合でも、クライアントはルートCA証明書、またはサーバーが使用するCA証明書にアクセスする必要があります。証明書はによって署名されましたか？または、まだ完全にポイントが不足していますか？
  • サーバー証明書を確認するには、クライアントはその証明書の完全な信頼チェーンにアクセスする必要があります。それ以外の場合、クライアントは証明書を無効と見なすか、ユーザーにそれを受け入れるように依頼します。あなたの場合、CA / CRLの配布ポイントを設定しない可能性が高いと思われるため、最も簡単な方法は、証明書がクライアントマシンの/ etc / ssl / certsにあることを確認することです。 tl; dr：証明書は、信頼のチェーンを確立できない場合、信頼を確立するための限定的な用途です。'そして、それを確立するには、チェーン全体を検証する必要があります。したがって、信頼チェーン全体を利用できるようにします
  • サーバー上にルートCA、中間CA、および署名付き証明書がある場合、これら3つの証明書すべてが/etc/ssl/certsディレクトリ？これらはすべて公開鍵を含んでいますか？

回答

自己署名証明書は、まさにそれです。私自身に署名しました（それはそれ自身のトラストアンカーです）。

したがって、信頼されるためには、アプリケーションの信頼できるアンカーリストに手動で明示的に配置する必要があります。その方法はOSとアプリケーションによって異なります。

たとえば、Windowsの内部証明書ストレージを使用している場合は、その自己署名証明書を「信頼されたルート認証局」ストアに配置する必要があります。そうしないと、証明書は受け入れられません。 OpenSSLは、異なるアプリケーション固有のストレージシステムを使用します。証明書を信頼できるCAとしてインストールする必要がありますが、その方法は、使用しているアプリケーションとOSによって大きく異なります（この記事の一般的な手順について）

コメント

  • つまり、"トラストストア"証明書は、たとえばapacheにインストールされている証明書とまったく同じですか？'最も混乱しているのは、i ' ma GNU/Linuxユーザーで、クライアントアプリケーションでそのディレクトリにリンクする必要がありました。 /etc/ssl/certs。しかし、プロセスがその側面で正確に何であるかについての明確な説明を見つけることができませんでした。少なくともここで私の質問を理解しているので、その背後にある主なポイントは書くことですクライアントを信頼させ、接続先のサーバーを信頼させます。
  • 何を'正確に実行しようとしているのはCAを作成することであり、証明書はCA（中間）によって署名されていると思います。その場合、これはCAがトラストアンカーであることを意味します。中間Caは信頼できる証明書ディレクトリにインストールする必要がありますか？返信いただきありがとうございます。
  • したがって、あなたの質問はより一般的です。 '探している答えへのリンクで閉じることを提案しました。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です