信頼できるCA SSL証明書と組み込みデバイス
HTTPSとMQTTSを介してサーバーに接続する組み込みデバイスがあります。サーバー証明書は、信頼されたCA（たとえば、Let's Encrypt）によって発行されます。ただし、デバイスは信頼できるCAを認識していないため、クライアント側でのサーバー証明書の検証に問題があります。
だから私はいくつかのオプションがあります：
DSTルートCA Xルート証明書（LEルート証明書）をデバイスに入れ、それをチェックします。
自己署名ルート証明書を作成し、デバイスに入れます。
公開鍵の固定。
DST Root CA Xが来年期限切れになるため、最初のアプローチは機能しません。さらに、Let's暗号化はルート証明書をいつでも変更する可能性があり、新しく発行された証明書が同じ証明書によって署名されることは保証できません。
2番目の方法では、HTTPSサーバーがWebブラウザーなどの他のクライアントに対して信頼されなくなります。
同時に複数の証明書を使用するのはどうですか？出来ますか？ Nginxサーバーがそれをサポートしているのは間違いではないが、それが私が推測する方法で機能していることを確信していない場合：最初の証明書（たとえばLet's Encrypt）の検証が失敗した場合、サーバーはフォールバック証明書（たとえば自己署名）をクライアント。そうであっても、すべてのサーバーがこれをサポートしているわけではありません。
3番目の方法は、サーバーの公開鍵ハッシュをファームウェアに入れることです。この場合、将来的に任意のCAを使用できます（私は正しいですか？）。私が注意しなければならない唯一のことは、CSRを生成するときに常に同じキーを使用することです。
どっちがいい？または私の問題の他の解決策はありますか？
トラストアンカーがパブリックに信頼されたルートCA、ローカルに信頼されたルートCA、またはローカルに信頼されたサーバー証明書である場合、実際には問題にはなりません。代わりに、トラストアンカーを信頼すべきではない状況にどう対処するかが重要です。
単純なアプローチは、永久に有効なトラストアンカーを持つことです。これは、あなたが行おうとしている方法であり、次の方法で実装できます。任意のパブリックCAを発行し、後でサーバー証明書を更新しますが、各サーバー証明書に同じ固定キーペアを使用します。次に、デバイスのサーバー固定公開鍵に固定します。この方法では、デバイスは期待される公開鍵のみをチェックするため、検証に満足できます。証明書は信頼するCAによって発行されたので、ブラウザーも満足します。
ただ、サーバーのキーが危険にさらされた場合はどうなりますか？これは、信頼がパブリックルートCAに基づいており、CAの有効期限が切れている場合に直面する同様の状況です。どちらの場合も、トラストアンカーは信頼されなくなります。したがって、どういうわけか新しいトラストアンカーに切り替える必要があります。
サーバーのキーに対してピン留めした場合、代替キーが事前に作成されており、最初のキーが危険にさらされた場合に使用されるデバイスに配置される可能性があります。証明書の検証では、検証が主キーで失敗した場合に、この代替キーに対してチェックします。これが成功した場合、主キーは古くなっていると見なされ、確認のために再度使用することはできません。また、複数の代替キーを使用して、時間の経過とともにより多くのキーを廃止することもできます。
それでも、時間の経過とともにキーが危険にさらされたり弱くなったりする可能性が高まるため、キーを永久に信頼するべきではありません。そのため、デバイスのソフトウェアを更新する方法が必要になる可能性が非常に高いです。これは通常、いずれにしてもバグ修正に必要ですが、これらのトラストアンカーが新しい信頼されたルートCAまたは信頼されたサーバーキーであるかどうかに関係なく、デバイスに新しいトラストアンカーをもたらすためにも使用できます。