私はMQTTにOne Way SSLを実装したいと思っていました。私が調査したところから、SSLで、クライアントにはデフォルトの証明書が保存されています。この最初に保存された証明書を使用して、それをブローカー側の証明書と比較します。証明書が有効な場合は、保護された接続が確立されます。しかし、私たちのエンベデッドソフトウェアエンジニアは、クライアント側では証明書が必要ないと言っています。証明書をブローカ側から取得し、セキュリティで保護された接続に使用するだけです。要約すると、私が理解することは、クライアントには保管された証明書があり、それはブローカーが持っている証明書と比較されます。エンジニアは、クライアントは保存された証明書を持っていないと言います。それはブローカーから取得するだけです。MQTTで片方向SSLはどのように機能しますか？
彼はすでに、最初に保存された証明書を使用してブローカーに接続してテストしました。今、私はSSLが本当にうまくいくかどうかを理解していません。
MQTTを使用するSSLは、他のプロトコルと同様に動作します。
は2つの*メインモード
サーバー（ブローカー）のみの認証があります。この場合、クライアントはサーバー（ブローカー）に接続し、ブローカーはその証明書をクライアントに送信します。クライアントは、証明書がクライアントが信頼する誰かによって発行（署名）されたことを確認します。これは、サーバー（ブローカー）が誰であるかを証明し、信頼できることを証明します。クライアントとサーバー（ブローカー）は、暗号化されたトンネルを設定するためにキーネゴシエーションを行います。信頼できる当事者がサーバ証明書を発行したことを確認する行為は、既知のCA（Certificate Authority）証明書によって署名されていることを確認することです。これは、クライアントが信頼できる証明書のリストを保持する必要があることを意味します。
クライアントとサーバー（ブローカー）の両方の相互認証。これは、クライアントが独自の証明書をサーバ（ブローカ）に送信することを除いて、以前とほぼ同じです。これは、既知のCAによって発行されたことを確認するためにもチェックされ、CNフィールドはクライアントのユーザID 。
*証明書をまったく使用しない事前共有キーモードもあります。
こんにちは、答えに感謝します。これは、クライアントが信頼できる証明書のリストを保持する必要があることを意味します。これは、依頼人が依然として検査のために最初に準備された証明書を持っていなければならないということですか？ –
はい、クライアントは既知の信頼できるCA証明書のリストにアクセスできる必要があります。提供された証明書をただ受け入れるようにクライアントに指示することはできますが、中間の攻撃で人を検出する方法が必要なので、セキュリティポイントの半分を守りません。 – hardillb
いいえ。ありがとう！ –
あなたはここで何を達成しようとしていますか？ 1）クライアントとブローカとの間の安全な接続、または2）ブローカへのクライアントの識別だけでなく、安全な接続の作成？ – hardillb
@hardillb私はちょうど安全な接続を作成しようとしています。ブローカーはクライアントを知る必要はありません。 –