HSTSは、不正な有効な証明書を発行する不正なCAから保護しますか？
HSTSは、不正な有効な証明書の発行を不正に行った公的に信頼されたCAからドメインを保護しますか？公に信頼されたCAの例は、 Mozilla CA Bundle のメンバーのいずれかです。
正当ではないが公に信頼されているCAが有効な証明書を発行することからドメインを保護する方法はありますか？
いいえ、HSTSは証明書の誤発行を防ぎません。 HSTSは単に、ブラウザにHTTPS経由でのそのサイトへの接続のみを許可するように指示します。証明書を信頼する必要があるかどうかの確認とは何の関係もありません。
ある程度の発行に役立つ可能性があるのは、証明書の透明性（CT）と認証局の承認（CAA）の2つです。
証明書の透明性は、CAによる誤発行を防止しませんが、証明書がパブリックにログに記録されることを要求するため、ドメインに対して発行されるべきでない証明書が発行されていないかどうかを確認できます。 2018年以降、Google Chromeは、発行されるすべての新しい証明書が信頼できるようにCTログに記録されることを要求しています。Firefoxはまだ残念ながらまだではありませんが、実際には、最近発行されたすべての証明書は、他の場合と同様にCTログに記録されますChromeでは動作しません。
認証局認証では、DNSレコードを使用してドメインの証明書を発行できるCAを指定できます。これにより、CAによる偶発的な発行が防止されますが、もちろん、悪意のある俳優はそれを無視します。 CAAは、特定の時点でどのCAが証明書の発行を許可されているかを示すことだけを目的としており、CAAレコードが変更された場合でも、証明書の有効期間中は有効ではないため、これは有用な制御にすぎません悪いアクターではないCAの場合、許可されていない証明書の発行を防ぐことができるため、最終的には信頼されなくなる可能性があります。実際、RFC 特に必要 ブラウザはCAAレコードをチェックしません。
3つ目のオプションはHPKPです。これにより、ドメインで使用する必要がある特定の証明書をピン留めできます（リーフ証明書である必要はありません。CAのルートのピン留めは、CAAの使用と多少似ていますが、より効果的です）。は支持を失い、Chromeではサポートされなくなりました。
編集： curiousguy は、場合によってはCTロギングを回避するための興味深い攻撃を指摘しています。攻撃者が中間者の位置にいる場合、（たとえば、TLSスタックの小さな動作の違いにより）どのブラウザが早い段階で接続を確立しているかを知ることができる場合があります。これにより、CTログをチェックすることがわかっているブラウザーからの接続を攻撃せずに、正当なサーバーに接続を転送するだけで、他のブラウザーに誤って発行された非CTログの証明書を提示して、正当なサーバーになりすますことができます。これを防ぐ唯一の方法は、すべてのブラウザがCTログをチェックすることだと思われます。