古い証明書が固定されている場合のTLS証明書の置き換え（HPKP）
私の公開鍵ピンの最大年齢が60日だとします。新しい証明書はいつ導入できますか？今から60日？しかし、今から60日後に私のサイトに最初に接続するブラウザーはどうでしょうか。
このサイト 言う：
[HPKPを使用する] GitHubがTLS証明書を置き換える場合は、新しい証明書にDigiCertまたはSymantecのいずれかで署名する必要があります。そうしないと、新しい証明書チェーンのキーハッシュが既存のHPKPポリシーと一致せず、ユーザーはサイトへのアクセスがブロックされました。
したがって、最初に固定したもの（Verisignなど）とは異なるCA（Let's Encryptなど）によって署名された新しい証明書を展開することはできませんか？
これが、別のCAからのバックアップ証明書を固定することが推奨される理由ですか？
cf. p。 IvanRistićの315 防弾SSLおよびTLS （2014）
- ヘッダーには常に2つ（またはそれ以上）のピンが必要です。1つは現在の証明書用で、もう1つ（または複数）はバックアップ証明書用です（現在のピンとは別に保持され、オフラインが最適です）。
- 現在の証明書が侵害されていない場合は、ピンに触れたり、新しい証明書を発行したりする必要はありません。既存の証明書を更新するだけです（以前と同じCSRを使用して新しいCRTを発行するようCAに依頼してください）。
- システムが危険にさらされた場合は、いつでも（少なくともmax-ageの間）ピン留めしたバックアップ証明書に切り替えることができます-ピンが有効である（以前はヘッダーに存在していた）ため、UAはそれを受け入れます。
- クライアントによって信頼されているCAに、CSR（現在またはバックアップ）に署名するように依頼できます。
- 新しいピンを追加する場合は、UAが接続を拒否するリスクを排除するために、それに一致する証明書を使用する前に最大経過時間（通常は60日）待つ必要があります。以下のシナリオを参照し、クライアントXとYの違いに注意してください：
- 1日目：ピンA + crt Aを構成し、max-ageを60日に設定します。
- 2日目：クライアントXが接続し、Aが60日間安全であることを学習します。
- 3日目：クライアントYが接続し、Aが60日間安全であることを学習します。
- 20日目：ピンBをヘッダーに追加します。
- 21日目：クライアントXが接続し（彼はAを信頼します）、AとBの両方が60日間安全であることを学習します。
- 40日目：crt Bに切り替え、
- 41日目：クライアントXが接続し（彼はAとBの両方を信頼します）、
- 42日目：クライアントYは接続を拒否します-信頼できるAから新しいPINを学習できなかったため（クライアントXのように）、63日目までA以外のすべてを拒否します。
それでも疑問がある場合は、セクション2.6を参照してください。固定接続の検証と付録B . RFC 7469 の展開ガイダンス。
あなたがしなければならないことは、すでにそこにあるものに加えて、新しい証明書とチェーンのSHA-256ハッシュを追加することです。その後、60日以内に、古い証明書のSHA-256ハッシュを削除できます。