SSL / TLS-自己署名証明書と自己署名CAの違い、およびその他の質問

Question

HTTPS経由で安全に提供したい小さな個人用Webサイトがあります。現時点では、サードパーティのCAを使用して証明書に署名したくありません。このドキュメントを自己署名証明書の生成で読んでいました。

3つの質問があります。

このドキュメントは2つの方法を示しています：（1A）独自の自己署名証明書を生成する。（1B）独自の証明書/ CAを生成し、CAを使用して証明書に署名する。

両者の違いがわかりません。（Verisignによって署名された証明書とは異なり）ブラウザーのいずれもそれを信頼しない場合、独自のCAを生成する意味は何ですか？（1B）はMITM攻撃の防止に使用されていますか？その場合、（1A）よりも（1B）を使用する必要がありますか？

複数の証明書の管理/失効（使用する場合）以外に、自己署名CAは無意味に見えますか？
ドキュメントがdes3暗号を使用していることに気付きました。 des3を使用する正当な理由がない限り、代わりにaes-256暗号を使用することは可能ですか？（また、これをどのように行うのですか？）
このスレッドは、2048ビットキーと256ビットキーの使用を区別しました。私は答えがある程度言っていることを理解しています（公開（2048ビット）鍵は対称（256ビット）鍵を暗号化してサーバーとクライアント間で鍵を交換するために使用される）。しかし、これがドキュメントのコンテキストでどのように適用されるのか理解していません。ドキュメントで、私はこの行を見ます：

openssl genrsa -des3 -out server.key 4096

この行は、対称鍵（des3）を生成してから、公開鍵（RSA 4096ビット）を生成することを意味しますか？

Tom Leek · Accepted Answer

CA証明書は、CAが所有し、CAとしての使用に適しているとマークされている証明書です。つまり、「cA」フラグがTRUEに設定されたBasic Constraints拡張が含まれていることです。

自己署名証明書は、証明書自体にある公開鍵に対応する秘密鍵で署名された証明書です。これは、証明書が他の誰かによってではなく、証明書の所有者自身によって発行されたことを意味します。

CA証明書は自己発行することができます。これはルートCAの通常のケースです。ルートCAは、それ自体が存在するCAであり、信頼されているアプリオリ（手動でWebブラウザまたはOS証明書ストアに含まれている）および別の信頼できるCAから発行されたという理由ではありません。

自己署名CAを作成し、それを使用して実際のサーバー証明書（オプション1B）に署名することは、多くのサーバーに複数の（場合によっては多くの）証明書を発行することを想定している場合に役立ちます。独自のルートCA（これがオプション1Bの意味です）では、one証明書をすべてのクライアントに手動で挿入する必要があります（自己署名ルート） CA）。生成するサーバー証明書が1つしかなく、物事がそのまま続くと予測される場合、オプション1Aは1Bと同じくらい優れています。

-desオプションは、CAキーの対称暗号化用です。悪くない。地球には、適切に実行された3DES暗号化を解読するのに十分な計算能力（または、さらに言えば、生の能力）がありません。 AES-256にアクセスしても役に立たず、OpenSSLコマンドラインツールはそのままではサポートされないため、難しい場合があります（OpenSSL、ライブラリ、AES-256実装が含まれていますが、コマンドライン秘密鍵の対称暗号化に関しては、ツールは簡単にアクセスできません）。

デジタル署名（証明書に適用されるもの）は、定義により非対称キーを使用します。非対称キーは多くの内部数学構造を必要とし、その構造を使用して弱めることができるため、適切なレベルのセキュリティを実現するには、対称キーよりもはるかに大きくする必要があります。そのため、優れたRSA鍵は2048ビット程度にする必要がありますが、128ビットの対称鍵はすでに確実です。この線：

openssl genrsa -des3 -out server.key 4096

サイズ4096ビットの新しい非対称RSAキーペアを生成し、ファイルserver.keyに保存します。そのストレージは、その時点で入力したパスワードから派生した対称キーを使用して、3DESでさらに保護（暗号化）されます。

秘密鍵には公開鍵のコピーが含まれています。公開鍵（もちろん、秘密鍵ではありません）も証明書の一部になります。最初にcertificate request（ ".csr"ファイル）そして証明書自体に。

bethlakshmi · Answer

CA対自己署名証明書

PKIインストールでは、自己署名証明書（CAまたはエンドエンティティ-サーバーなど）をすべての証明書利用者に配布する必要があります。平均的なユーザーの場合、有名で信頼性の高いパブリックCAシステムが自動的に展開されます。内部の企業環境などの小規模なインフラストラクチャの場合、ブラウザ、サーバー、その他のディストリビューションに内部CA証明書を自動的にパッケージ化できます。すべての場合において、証明書が自己署名されている場合、明示的に信頼する必要があります。

大きな違いは次のとおりです。

自己署名エンドエンティティ証明書-複数の証明書を作成する場合、作成するすべての証明書はすべてのエンドポイントで明示的に信頼されている必要があります。証明書が侵害された場合は、すべてのエンドポイントから信頼を削除する必要があります。それは自動化されたスクリプトで行うことができますが、それは多くの仕事です。
自己署名CA->署名済みエンドエンティティ-CAを明示的に信頼する必要があります。そうすると、すべてのエンドエンティティが自動的に信頼されます。任意の期間にわたって複数のサーバー証明書を作成することを計画している場合、これによりワークロードが削減されます。トリックは、サーバー証明書が侵害される可能性がある場合（常にそうである）、失効を検証する方法が必要であることです。これが複雑さの出番です。CRLまたはOCSPは、妥協点について通信するための標準的な方法ですが、CRLをステージングして配布し、（オプションで）OCSPサーバーをステージングして実行するためにより多くの作業を行うことを意味します。さらに、これをチェックするようにブラウザーを構成する必要があります。これはデフォルト設定ではありません。

これは、システムのリスクと、証明書の発行と失効のライフサイクルがどうなるかと関係があります。

DES3対AES-256

openSSLドキュメントから引用したコマンドのオプションは次のとおりです。

DES
DES3
IDEA

IDEAは新しいアルゴリズムであり、より良い方法であることをお勧めしますが、互換性のないシステムがある場合はお勧めしません。これは本当に苦痛になる可能性があります。与えられた証明書と秘密鍵は非常にイライラする可能性があり、ほとんどのシステムによって提供される答えは不明確で理解するのが困難です。

このドキュメントによると：

これらのオプションは、秘密鍵をDES、トリプルDES、またはIDEA暗号でそれぞれ暗号化してから出力します。これらのオプションのいずれも指定されていない場合、暗号化は使用されません。暗号化がパスフレーズで使用されている場合-passout引数で指定されていない場合は、プロンプトが表示されます。

これは、秘密鍵がserver.keyファイル内に保管および保護される方法です。証明書がサーバーが他のシステムと通信することを許可する方法とは関係ありません。

通常のCAシステム（OpenSSLは少し原始的である場合があります）では、暗号化にキーを使用する方法を指定する方法があります。これには、256ビットセッションキーの許可または強制などの有効なSSL設定を含めることができます。

これは、証明書のキーの要素ではありません（例では、4096ビットのRSA非対称キーです）。これは、表されているキーペアがCAおよびそれに関連付けられているセキュリティポリシーに従って実行できることの要素です。これは通常、SSLセッションのセットアップ方法を制御します。

明確にするために証明書の作成時にSSLセッションキーは作成されません。セッションキーは、クライアントがサーバーと通信するときに作成され、ネゴシエートされます-証明書が作成、署名、およびインストールされてからかなり時間がかかります。

Lucas Kauffman · Answer

会社が独自のCAを生成したい場合は、それを個人のコンピューターに含めることができます。たとえば、内部のWebサイトまたはプロキシ（SSL接続を検査する場合）を信頼するためです。
3 DESは壊れていませんが、AESはDESよりも優れたセキュリティを提供し、3DESよりも計算効率が高くなります。AESは3つの異なる鍵の長所を提供します：128-、 192ビットおよび256ビットのキー。3DESは基本的にDES 3回暗号化されます。
RSAは高価なアルゴリズムであり、すべての接続の暗号化にはあまり適していません。 RSAで暗号化されたすべてのものを送信する代わりに、サーバーは256ビットで構成されるランダムなキーを作成し（このキーはパスワードのように見える、ランダムな文字の束、長さは256ビット）、それを使って暗号化します。 RSAキーを送信し、それをもう一方の端に送信します。ここからは、どちらもAES（RSAよりもはるかに高速でデータを暗号化および復号化する）のような対称暗号化アルゴリズムを使用して、データを安全に送信します。

flihp · Answer

順番に：

このドキュメントは2つの方法を示しています：（1A）独自の自己署名証明書を生成する。（1B）独自の証明書/ CAを生成し、CAを使用して証明書に署名する。

両者の違いがわかりません。（Verisignによって署名された証明書とは異なり）ブラウザーのいずれもそれを信頼しない場合、独自のCAを生成する意味は何ですか？

証明書がブラウザーによって信頼されているCAによって署名されていない場合でも、クライアントとサーバー間のトラフィックを暗号化するために使用できます。これは、暗号化のおかげで、必要な秘密を取得できることを意味します。あなたが得ないものはあなたの訪問者のブラウザの小さな緑の南京錠で、あなたのドメインの所有権が認証局によって吟味されていることを彼らに伝えます。そのため、彼らはあなたのサイトの真正性（可能なMITM）を確認することはできませんが、通信は暗号化されます。

自己署名証明書は、すべての証明書階層における信頼のルートです。 Verisignには、署名するすべての証明書の信頼のルートである自己署名証明書があります（おそらく、どこかのバンカーにあります）。認証局を再生できるようにする場合（つまり、複数の証明書を作成し、それらすべてを同じ信頼チェーンの一部にする）、自己署名証明書を作成し、それを使用して他の証明書に署名する必要があります（openssl reqおよびopenssl x509）。

（1B）はMITM攻撃の防止に使用されていますか？

いいえ。あなたの（1B）は、作成者が最初の段落で述べたように、すべて同じCAに関連付けられた複数の証明書を作成できるようにすることを目的としています。基本的に、これは証明書の階層とは何かを効果的に示す演習です。

その場合、（1A）よりも（1B）を使用する必要がありますか？

単一のWebサイトの場合、1Bを実行するのは良い練習ですが、1Aで問題なく解決できます。

ドキュメントがdes3暗号を使用していることに気付きました。 des3を使用する正当な理由がない限り、代わりにaes-256暗号を使用することは可能ですか？（また、これをどのように行うのですか？）

Linuxディストリビューションの一部のopensslドキュメントには欠落していますが、-aes256の代わりに-des3を使用して、代わりに256ビットAESを使用できます。同様に、192ビットと128ビットのバリアントも利用できます。サポートされているアルゴリズムのリストについては、openssl genrsa --helpの出力を確認してください。適切なアルゴリズムの選択に関しては、アルゴリズムが壊れていることが知られていない限り、ほとんど違いはありません。 AES256とトリプルDES（des3）はどちらも非常に強力です。 AESの方が効率的であるため、通常はAESを使用します。

openssl genrsa -des3 -out server.key 4096この行は、対称鍵（des3）を生成してから、公開鍵（RSA 4096ビット）を生成することを意味していますか？

いいえ。このコマンドにより、opensslは、トリプルDESを使用して暗号化された4096ビットのRSA秘密鍵を作成します。パスフレーズの入力を求められます。このキーを目的に使用する前に、同じパスフレーズを使用して暗号化を解除する必要があります。これは、キーが紛失/盗難にあった場合にキーを使用できないようにすることを目的としています。

grauwulf · Answer

ここで概要情報を探しているようですので、答えは短くしておきますが、自由に読んでください opensslのドキュメント

認証局（CA）は、他の証明書に署名して信頼のWebを作成するために使用されます。例：サードパーティの証明書を取得した場合、他の誰か（thwat、verisign、koomodoなど）によって署名された証明書を受け取ります。これらは、ユーザーのブラウザのキーストアが検証できる「信頼されたCA」です。ブラウザーはYYY.comの証明書を確認し、信頼できるエージェントによって署名されており、取り消されていない場合、証明書を有効（緑色のロック）として受け入れます。署名チェーンに信頼できるCAがない場合、証明書が信頼できるかどうかを知る方法はありません。
あなたはできるはずです。 openssl genrsa -aes256 -out server.key 4096
このトピックを実際に理解するには、少し深く掘り下げる必要がありますが、非常に高いレベルでは、秘密鍵を使用して非対称鍵ペアを生成します。この記事の「DSA鍵の生成」セクションでは、秘密鍵の作成を示し、「証明書署名要求からの自己署名証明書の作成」では、その鍵を使用してcsrに署名し、結果の証明書がCAに信頼されるようにします。

これは、SSLの概念の実際の迅速で汚いレビューです（私は非難されることを期待します:)。したがって、本当にSSLについて理解したい場合は、さらに深く掘ることを強くお勧めします。 gavaghan.org に、SSLのすばらしい概要があります。これは、テクノロジをより完全に理解するのに役立ちます。「SSLチュートリアル」などの簡単なグーグルでも良い結果が得られるはずです。