SSL接続プロトコルは自己署名証明書とどのように連携しますか？
自己署名証明書を使用していますが、このプロトコルの仕組みがわかりません。 2つのアプリをソケットSSLで接続しましたが、正常に動作します。サーバーはPythonアプリであり、クライアントはAndroidアプリです。私はopenSSLを使用して自己署名証明書を作成しましたが、2つのファイルがあります：プライベートキーと自己署名証明書サーバーはすべてのファイルを使用しますが、クライアントは自己署名証明書のみを使用します。
署名付き証明書とCAを使用したプロトコル接続を説明するページがたくさん見つかりましたが、CAなしで自己署名したものはありませんでした。
署名付きプロトコル：クライアントサーバー
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
（このスキーマはRFCから恥知らずにコピーされています。）
自己署名証明書はどうですか？
SSLプロトコル（現在は [〜＃〜] tls [〜＃〜] と呼ばれます）では、証明書はブラックボックスです。SSLの観点から見ると、証明書はサーバーから受信されます。 どういうわけか使用する公開鍵がクライアントに知られるようになります。証明書はサーバーの公開鍵をクライアントに伝達するために使用される容器であり、すべてのCAビジネスは、クライアントが受信した公開鍵が実際に目的のサーバーからの正しいものであることを保証するための方法です。
サーバーが自己署名証明書を使用する場合、クライアントは既知のCAから信頼を転送して、受信した自己署名証明書が本物であり、アクティブな攻撃者からの模倣ではないことを確認できません。ただし、クライアントがすでににサーバーの公開鍵を知っている場合（たとえば、以前のインストール段階で、制御された条件下で、サーバーの自己署名証明書がクライアントに表示され、クライアントはそれを記憶します）、その後、クライアントは、定義により、適切なサーバーの公開鍵を認識し、それを使用します。
いずれの場合でも、SSLレベルのプロトコルは完全に変更されていません。サーバーは引き続きCertificateメッセージを送信し、クライアントは引き続きClientKeyExchangeメッセージにサーバーの公開鍵を使用します。
編集：ここを参照してください： SSL/TLSはどのように機能しますか？ またはここ 自己署名証明書-動作方法
わかりませんが、CAの証明書に署名したときのプロトコルは次のとおりです。クライアントはHelloをサーバーに送信します---サーバーはHelloと証明書をクライアントに送信します---クライアントはCAで証明書を確認し、サーバーに確認を送信します---最後に、サーバーはクライアントに署名された確認を送信します。 – juve164 2014年6月14日12:15
自己署名証明書はどうなりますか。クライアントはサーバーにHelloを送信します---サーバーはクライアントに証明書を送信し、クライアントは証明書を確認しますが、どのように???同じ証明書かどうかを比較しますか？ – juve164 2014年6月14日12:23
これについて少し考えてみましょう。証明書ユーザーの公開鍵暗号。つまり、公開鍵と秘密鍵は同時に生成され、数学的に結合されます。この秘密鍵のみがこの公開鍵で機能し、その逆も同様です。
証明書を紹介すると、それは「署名入りの紙」に過ぎません。その署名は秘密鍵からのものです。これは、キーが何に使用されるかについての参照を提供するだけです。別名google.com。
TLSハンドシェイク：
CClientHello：これが始まりです。TLSプロセスを開始できるようにサーバーと通信しています。
SServerHello：サーバーが応答して、TLSで話していることを確認します。
SCertificate：これは、サーバーにインストールされている証明書のコピーです。
SServerKeyExchange：これは、TLSハンドシェイク後に使用する同じ対称鍵に両方のデバイスが到達できるようにするために使用されるプロトコルの一部です
SCertificateRequest：サーバーが証明書でクライアントを検証する場合にのみ使用されます。これは、認証の形式として伝達できます。
SServerHelloDone：サーバーは、TLSハンドシェイクの一部で終了します。
C証明書：必要な場合にのみ提供されます。上記のCertificateRequestを参照してください。
CClientKeyExchange：これは、両側に対称鍵があることを確認するためのServerKeyExchangeのコンパニオンです。
CCertificateVerify：CertificateRequestおよびクライアント側TLSの一部。
CChangeCipherSpec：これは通常、すべての処理が完了し、暗号化との対話を開始する準備ができたことを示しています。
CFinished：これはクライアント側の終わりです。
SChangeCipherSpec：サーバーは暗号仕様に同意しています。
S終了：すべて完了し、完全に暗号化されました。
このプロセスでは、サーバーによって送信される証明書は、サーバーで構成されたものになります。これがCAによって署名されている場合、通常、これにはリーフ証明書（ドメイン名を持つもの）、即時署名機関、およびその署名機関の親（該当する場合は同様）が含まれます。したがって、Certificateには通常、3つの物理証明書が含まれます。
次に、クライアントはリーフ証明書で発行者を確認し、チェーンバックアップの追跡を開始します。中間者には（ルートCAである）発行者がいるため、その証明書をチェックします。ルートCAは自己署名証明書です。これは、独自の秘密鍵が証明書に署名した証明書であり、他のエンティティではありません。クライアントがルートCAを信頼している限り、クライアントは中間体を信頼します。これは、リーフを信頼することを意味します。
サーバー上の自己署名証明書では、クライアントが検証するために発行された証明書のみがあります。証明書の発行者を調べ、それ自体が署名したことを確認します。クライアントがそのCAを信頼している限り、クライアントは接続を信頼して続行します。
すべてのルートCAは自己署名されています。コンピューターがそれらを信頼する唯一の理由は、コンピューター上でそれらが信頼されるように構成されているためです。
https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake
ウィキペディアから： https://en.wikipedia.org/wiki/Self-signed_certificate
暗号化とコンピュータセキュリティでは、自己署名証明書は、IDを認証するのと同じエンティティによって署名されたID証明書です。この用語は、実際に署名手順を実行した個人または組織のIDとは関係ありません。技術的には、自己署名証明書は独自の秘密鍵で署名された証明書です。
秘密鍵はCAです。