使用しなくなったLet's Encrypt証明書を破棄してから破棄する必要がありますか？

Question

Let's Encryptのドキュメントでは、証明書の対応する秘密鍵が安全でなくなった場合は証明書を取り消すを推奨しています。

しかし、鍵が危険にさらされている兆候がなく、証明書が不要になった場合も、同じことを行う必要がありますか？ Let's Encrypt証明書は90日後に自動的に期限切れになります。証明書とその秘密鍵を削除するだけで十分ですか？

背景として、これは私の具体的なシナリオです：

新しいソフトウェアをデプロイすると、新しいEC2インスタンスが作成され、最終的に既存のインスタンス（不変サーバーパターン）が置き換えられます。
起動時に、新しいインスタンスは新しいLet's Encrypt証明書を取得します。
証明書（およびその秘密鍵）がEC2インスタンスを離れることはありません。

したがって、古いインスタンスが終了すると、そのマシンに割り当てられている証明書は破棄されます。この時点では、秘密鍵にアクセスできなくなりました。

質問：

私の理解から、失効は良い習慣かもしれません。しかし厳密に言えば、システムのセキュリティは向上しません（もちろん、秘密キーが危険にさらされていないと想定します）。あれは正しいですか？
Let's Encryptオペレーターが未使用の証明書を明示的に取り消すのに役立ちますか、それとももっと害がありますか？（わかりませんが、失効すると余分なプロセスがトリガーされる可能性があります。キーが危険にさらされている兆候がない場合は、不要な可能性があります。）

Mike Ounsworth · Accepted Answer

これは主観的なコストとリスクの決定です。私たちはあなたのためにそれを作ることはできませんが、私はあなたが関係する要因を調べるのを手伝うことができます。

費用

あなたへ：証明書を取り消す努力。これを手動で行う必要がある場合、それは面倒ですが、10分でスクリプトを作成してCloudFormationプレイに追加できる場合は、なぜですか？ @Hildredが指摘しているように、これはサーバーが廃止されたことも通知します。これは、注意の度合いによってはプライバシー/セキュリティの問題と見なされる可能性があります。

To LetsEncrypt：取り消し要求を処理する必要がありますが、これは特に重い要求ではありません。取り消された各証明書は、その行に CRL を追加し、CRLを送信するための帯域幅コストがわずかに高くなり、CRLを検索する必要があるOCSPレスポンダーにわずかなパフォーマンスのペナルティをもたらします。しかし、システムは文字通りこれのために設計されているので、それは確かに負担ではありません。

危険

攻撃者が証明書を取り消さずにVMを終了させた場合、攻撃者はその証明書を有利に利用できますか？悪意のある管理者（あなたまたはAmazonのいずれか）は、VMから証明書とキーをプルし、あなたが賢くならないようにすることができます。ライブシステムからプルするよりも、おそらくそうではありません。

つまり、私たちは非常に小さなコストと非常に小さなリスクを扱っています。あなたの選択。質問してくれてありがとう。

Tom · Answer

秘密鍵が危険にさらされなければ、セキュリティの観点から、失効は必要ありません。

不必要な取り消しにより、Let's Encryptインフラストラクチャにわずかな負荷が追加されますが、それほどではありません： https://community.letsencrypt.org/t/does-revocation-cause-additional-load/252

hildred · Answer

見落とした可能性の1つは、失効を生成するが、必要になるまで公開しないことです。インフラストラクチャにわずかな負荷をかけますが、マシンの削除を隠し、必要に応じて取り消しを利用できます。

Lie Ryan · Answer

これは非常に主観的な質問です。

証明書を失効させても害はありません。明示的に取り消すのではなく、やがて期限切れにしたいだけなのかどうかは、リスク分析次第です。もちろん、取り消さない場合は証明書が漏洩するリスクが高くなりますが、メンテナンスの手間と比較してこのリスクを許容できると考える場合は、毎回明示的に取り消す場合に通過する必要があり、リスクを受け入れることができます。そしてそうする。

このリスクが許容できるかどうかは、独自のインフラストラクチャに基づいて評価する必要があります。おそらく、会社やデータセンターの従業員になることによって、または盗難などの他のリスクによって、キーにアクセスできる人のリストを列挙し、これらの人が偶然または意図的にキーをリークします。また、システムで実行されているサービスのリストを検討し、悪用されてキーが漏洩する可能性があるかどうかという観点から、セキュリティリスクを評価する必要があります。また、キーが何に使用されているか、およびこれらのキーが会社に悪用された場合の損害を評価する必要があります。これらの考慮事項およびその他の考慮事項に基づいて、これらのリスクを受け入れる場合は、情報に基づいた決定を行うことができます。