ローカルネットワークで証明書ピンニング（HPKP）と自己署名証明書を機能させる方法は？
ローカルネットワークでSSLを使用する必要があり、ブラウザの無効な証明書エラーを回避したい。
私の考えは、自己署名証明書を生成してから証明書ピンニング（HPKP）を使用して、この証明書のみを信頼できることをブラウザーに通知することです。
私は現在、このアイデアに関連するすべてのオプションを検討しています。自己署名証明書とHPKPヘッダー（Public-Key-Pins）を使用して、次のような値でテストしました。
"pin-sha256="somedataencodedbase64=";pin-max-age=10;includeSubDomains"
ブラウザはそれをセキュアとして受け入れません。私はまだこのテストを終了する必要があります（異なる自己署名証明書を使用して、SPKIが正しく計算されていることを確認する必要があります...
今の質問は次のとおりです。
指定されたローカルホスト名（mylocalserverなど）に対して自己署名証明書が発行され、サーバー応答に固定されていても有効ですか？これも機能しますか？
証明書のピン留めはローカルホスト名に対して機能しますか（つまり、ドメイン名でのみ機能します）？
固定された証明書は、最初に有効であるか、CAによってプッシュされる必要がありますか（これは、自己署名証明書を固定できないことを意味します-クライアントのトラストストアに追加されない限り）？
有効なSSLをローカルに設定する最も簡単な別の方法は何でしょうか。そのため、クライアント（クライアントトラストストア）を構成する必要はありません。
信頼できるCAの代わりに証明書のピン留めを見ることができますか？私はどこかでそれがちょうどさらにであることを読んだので、これは証明書チェーンが最初に有効である必要があることを意味し、それからあなたはそれを固定することができますか？
このアイデアがうまくいくかどうかもますます考えています。そうすれば、この手法の使用が増えるからです。誰もが自己署名証明書を生成し、それを固定するだけです...そしてCAの信頼できる証明書に数ドル節約します...または私が全体の概念について間違っているか正しいのは何ですか？
HPKPは、通常の検証に代わるものではありません。代わりに、通常の検証に追加されます。したがって、証明書が自己署名されているために通常の検証が失敗した場合、HPKPは役に立ちません。
指定されたローカルホスト名（mylocalserverなど）に対して自己署名証明書が発行され、サーバー応答に固定されていても有効ですか？これも機能しますか？
はい、HPKPは特定のx.509証明書の署名をアドバタイズするだけです。ブラウザ（または任意のWebクライアント）は、指定された期間だけキャッシュし、その後のアクセス時にこの署名を検証します。
証明書のピン留めはローカルホスト名に対して機能しますか（つまり、ドメイン名でのみ機能します）？
ローカルホスト名は、他のホスト名と同様にホスト名です。短くても。ローカルTLDがある場合でも。重要なのは、クライアントがそれをどのように解決するか、そしてHTTPリクエストのHost:ヘッダーで何をリクエストするかです。ホストfoobarを適切なIPに解決し、HTTPリクエストでこのHost:を要求し、自己署名証明書にそれがある場合CNをfoobarに設定すると、スキーム全体が機能し始めます。
固定された証明書は、最初に有効であるか、CAによってプッシュされる必要がありますか（これは、自己署名証明書を固定できないことを意味します-クライアントのトラストストアに追加されない限り）？
いいえそうではありません。ただし、どういうわけか、Webクライアントにはサーバー証明書を信頼する方法が必要です。信頼できるサーバー証明書のリストに追加するか、例外を作成するか（これは実際には以前と同じです）、ローカルCAを作成し、ローカルCA証明書を使用してサーバー証明書に署名します。自己署名サーバー証明書は、ローカルCAの作成をスキップする方法にすぎません。ちなみに、すべてのofficialCAは、公開鍵インフラストラクチャのルートポイントとして自己署名証明書を使用します。これがCAを作成するための正当な方法です。 officialCAは、OSやブラウザなどの最もよく知られているソフトウェアのトラストストアに証明書が追加されるCAです。追加の交渉にはお金がかかるので、それらのほとんどは無料ではありません。
有効なSSLをローカルに設定する最も簡単な別の方法は何でしょうか。そのため、クライアント（クライアントトラストストア）を構成する必要はありません。
使用しているすべてのサービスの自己署名証明書を取得します。そのようなサービスが少ない場合は自己署名証明書を扱い、数十ある場合はローカルCAを作成します。公に受け入れられたX.509証明書を取得するための合法的な無料の方法もあります LetsEncrypt 認証局を使用するだけです-それは無料です。ただし、ワイルドカード証明書（*を持つ証明書）は提供されません。これは、膨大な数のサービスがある場合に問題になる可能性があります。
信頼できるCAの代わりに証明書のピン留めを見ることができますか？私はそれがちょうど追加であるところを読んだので、これは証明書チェーンが最初に有効である必要があることを意味します、そしてあなたはそれを固定することができますか？
いいえ。証明書ピンニングは、誰かがターゲットCAになりすます場合の、man-in-the-middle攻撃に対する対策です。このため、「誰か」はすでにルートCA証明書をトラストストアに配置する必要がありますが、それは別の問題です。
このアイデアがうまくいくかどうかもますます考えています。そうすれば、この手法の使用が増えるからです。誰もが自己署名証明書を生成し、それを固定するだけです...そしてCAの信頼できる証明書に数ドル節約します...または私が全体の概念について間違っているか正しいのは何ですか？
あなたは間違いなくそうです。
さらに調べてみたところ、実際の仕様まで掘り下げたかったのです。
したがって、RFC7469は次のように述べています。
2.3.1。公開鍵ピン応答ヘッダーフィールドの処理
UAがセキュアトランスポートを介して、セクション2.1で指定された文法に準拠するPKPヘッダーフィールドを含むHTTP応答を受信した場合、基礎となるセキュアトランスポートエラーまたは警告はありません ...
したがって、最初に適切なSSLハンドシェイクを実行する必要があり（認証チェーンの検証を含む）、次にHPKPを実行できることが公式に明らかになりました...