基になるキーを変更せずにTLS証明書を頻繁にローテーションする目的は何ですか？
私は 証明書/公開キーのピン留めに関するOWASPチートシート を読みました。
キーのローテーションの頻度を増やすことは、キーが検出されずに侵害された場合に、継続的な損傷の時間枠が短縮されるという意味で私にとって理にかなっています。
証明書を頻繁にローテーションする利点は何ですか？一致する署名を見つけるために敵のスコープを制限しながら、SHA1（古いブラウザの互換性のため）を使用できるようにすることですか？それとも私が見逃しているものはありますか？
大きな利点の1つは、侵害が発生した場合に失効する必要がなくなることです。
これを行う「一般的な」方法は、証明書を失効させるために 証明書失効リスト（CRL） を発行するか、または OSCPプロトコル を使用することです。ただし、CRLまたはOSCPチェックは非常に簡単にバイパスできます。 MITM攻撃を実行する立場にある攻撃者は、クライアントがCRLがホストされているサーバーと通信するのを単にブロックすることができ、クライアントは喜んでそのビジネスに取り掛かります。これは、HTTPSで動作するキャプティブポータルなどの一般的な状況でありながら、CRLサーバーへのトラフィックを含む他のすべてのトラフィックをブロックするために必要です。
存続期間の短い証明書には、侵害が発生した場合、証明書の有効期限が切れるまで非常に限られた期間しか機能しないため、発生する可能性のある損傷が制限されるという利点があります。
Adam Langleyは、さらに読みが必要な場合、件名に 広範囲に記述 を記載しています。
Terry Chiaは「証明書を頻繁にローテーションする利点は何ですか？」という質問に答えました。完全に正しいので、追加するものはありません。
ただし、Googleは公開鍵も頻繁に変更するため、チートシートの前提が無効であるというメモを追加します。これはかなり混乱を招き、元の質問の理由の一部である可能性があります。
私の個人的なx509アーカイブから：
$ openssl x509 -in google-oct.pem -noout -subject -dates -modulus
subject= /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
notBefore=Sep 24 10:48:54 2014 GMT
notAfter=Dec 23 00:00:00 2014 GMT
Modulus=AF384ED52C86FBDCD4F3117AD63652874889E442C80B4B112B3AEFA978607B33758927E75F92838D1A42B19F1DB59BC55322068FB197D38BBCB68984CAB4F0328E10A1B0D98DA794AAA379AB7C3CAFF177663127EC5069872F801E925AEDB76C865209A00A55618A2D1BB91F368D5739A1DE88C9FE66F5E0108C1FF1025D62DEE3BFBFB9BCFD3E71EC9C6E91A05AECD9833AE32B89B432DCD4C489D69C2BEC7E325C621184A8E8658CD3B755E62E65E19A2649ADC668E5C2705280884FC5D3B9D5914AC27D22B050F819233A0DDFF4194F55BDE358AABA6376567087BA69407B17EA364DB3A842A1972199B9B5632088F0E1C45B50DD1AD123F49573094051F3
$ openssl x509 -in google-nov.pem -noout -subject -dates -modulus
subject= /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
notBefore=Oct 22 12:57:51 2014 GMT
notAfter=Jan 20 00:00:00 2015 GMT
Modulus=C15236913979042DF078DF5B73AF463A636F98CE32A2AABAC378180566A87C382BB3A82A6808D4103D626A37CA4FBF8ABEA5939DD6C9874A8D318593F5481F59756E76817CBD38B73A5C703438BB9A824FD054B168ED3C9E5CD0445F744ED2A4EAA6327A94813A98C941BD60F3B19C5DC8CDFB34DE9293C53D41A234B4499A4F19C6AF193084F61C6636D7E89AEA86110231E6EE03F4C853841B0FB46122E6D73E7EF08D058665C7297B1A329F16F0EEB856E7614EB16B23CB4B6BBC5B567685F02638B52ECEBC71B06A1503776C0945A75E3227F71FE2956FC48533A6529066C840433A6705E94523843D10C45A8BC9CD58FCA6A6AABD79F2FFFEE6CB254AB9
[...]
$ openssl x509 -in google-apr.pem -noout -subject -dates -modulus
Modulus=924D62DDCD6B012D33F6CF12A5FD6291B490867ABB1E4F7F356FA8BBD424400C283EE7BB14DA8D1268239814A490F7D88EBA5EA3A9ED8DFEE6B6FF841405A964D47B1F76DB6F39A6990FD024060248FA889580271D6DDA6A7ADEB1538425268FAA8C2D824865DA3F30F78D48887D4C90D86F0A8A95F0A9CC951B7562FC98EC91D132C1C9418182045652BF510D357F1792201126DF230CD76BCA58B367A30088E6606FE7B80265582BD9A235F36AC60A2A6C266775979B52501355C51C7927ABA5DD0FFAFA39DFA240B3F21826188A9818B5E9761D38E15ACA980EF12BA14BEE00CA3D8C7F66112B56CEDCE2CA8BE67DD8ACA8B594D906CAE752217F67419E59
実際のキーは完全に異なりますが、セキュリティの観点からはそれで十分です。
十分な時間とリソースを与えられたと仮定すると、例えば既知の公開鍵と一致する秘密鍵を総当たり計算しようとします。または、ハートブリードのようなことがもう一度発生し、秘密鍵が危険にさらされます。両方の種類の脅威を軽減する簡単な方法は、定期的にキーを変更することです。
私の観察では、Googleの証明書は3か月間有効ですが、月に1回交換されます。これは運用上の観点からは問題ありません。新しい証明書をまったく同じ秒でリロードしたくないのですが、影響を受けるサーバーの1％に新しい証明書の展開を開始し、サーバー全体に増やします。問題が発生した場合でも、古い証明書を有効な証明書に戻すことができ、新しい証明書、サーバー構成、サーバーソフトウェアなど、新しい（壊れた）に関連する問題を引き起こしている問題を修正するために最大2か月かかる場合があります。証明書。
Ayrxの答え の下で、Steve Setherは次のように述べています。
- 公開鍵と秘密鍵の間には1対1の対応があります。これらはいわゆるkey-pairを形成します。秘密鍵は、公開鍵が変更された場合にのみ変更されます。したがって、最初に理解する必要があります。秘密鍵は証明書の更新中に変更されないため、公開鍵も変更されません。証明書のみ、特に有効期限が更新されます。
- 私たちの秘密鍵が危険にさらされているシナリオを考えてみましょう-敵が私たちの秘密鍵を盗んだとしましょう。新しい証明書への変更は役に立ちません。証明書は公開されているため、攻撃者は新しい証明書を取得し続け、私たちになりすますことができます。
私はスティーブのポイントに同意します。それでは、新しい証明書への変更の用途は何ですか？
ここで重要なのは、新しい証明書に変更するのではなく、古い証明書の有効期限または有効期限を制限することです。秘密鍵の侵害が検出されない場合（上記の＃2）、この期限切れは役に立たない-しかし、侵害がわかっている場合（よくあることです）、証明書の取り消しを試みることができます（Ayrxによる言及）-失効に関係なく、また独立して、新しい秘密キーを使用する必要があることを知っています。古い証明書の有効期限は、秘密鍵も鍵ペアであるため、同時に「期限切れ」になることを意味します。
証明書の更新が役立つ他の攻撃があるかもしれませんが、上記の使用例は顕著なものだと思います。