但是，如果没有迹象表明该密钥已被破坏，则应该执行相同的操作，但是您应该不再需要证书？让我们加密证书将在90天后自动过期。删除证书及其私钥是否足够？
作为背景，这是我的具体情况：
当我们部署新软件时，它将创建新的EC2实例，最终将替换现有实例（不可变的服务器模式）。
启动时，新实例将获得新的Let's Encrypt证书。
证书（及其私钥）永远不会离开EC2实例。
因此，当旧实例终止时，分配给该计算机的证书将被销毁。此时，我们将无法再访问私钥。
问题：
从我的理解来看，撤销可能是一个好习惯。但是严格来说，它不会增加系统的安全性（当然，假设私钥没有受到破坏）。这是正确的吗？
它会帮助“让我们加密”操作员显式吊销未使用的证书吗，还是会造成更大的危害？ （我不确定，但是吊销可能会触发额外的过程，如果没有迹象表明密钥被盗用，这可能是不必要的。）
#1 楼
这是主观成本与风险的决定。我们无法满足您的要求，但我可以帮助您检查所涉及的因素。成本
致您：撤销证书的工作。如果您必须手动执行此操作，那会很烦人，但是如果您可以在10分钟内编写脚本并将其添加到CloudFormation播放器中，那为什么不呢？正如@Hildred指出的那样，这还表明您的服务器已经停用，这可能会被视为隐私/安全性问题，具体取决于您关心的程度。
对于LetsEncrypt：他们需要处理吊销请求，而不是一个特别繁重的要求。每个被撤销的证书在其CRL中增加了一行，传输CRL的带宽成本略高，并且对需要搜索CRL的OCSP响应者造成了轻微的性能损失。但这肯定不是负担，因为该系统实际上是为此目的而设计的。
风险
如果攻击者发现您在不撤销证书的情况下终止了VM，他们是否可以利用这些优势？流氓管理员（无论您是您的还是亚马逊的）都可以在终止虚拟机时从虚拟机中提取证书和密钥，而您绝对不是一个明智的选择。与从实时系统中撤出威胁相比，这是否可能构成威胁？可能不是。
实际上，我们要处理的是很小的成本而很小的风险。你的选择。不过，感谢您提出问题，请多加思考！
评论
让我们加密没有CRL，只有OCSP。
–汤姆
17年8月3日在18:52
@tom啊，我不知道LetsEncrypt不向公众提供CRL。谢谢。但是即使如此，我敢打赌他们仍然在内部使用它们。您可以设计一个CA，以便它具有一个直接查询CA数据库的中央OCSP响应程序，但是出于安全和性能方面的考虑，最好在每个地理区域中使用OCSP响应程序来处理本地吊销数据缓存。无论您实现哪种，它基本上都是CRL。
–麦克·恩斯沃思（Mike Ounsworth）
17年8月3日在19:17
比较不错，谢谢。在考虑之后，我相信在我的特定用例中，撤销它们是有意义的。我已经有一个钩子可以在实例被销毁之前进行一些清理，因此自动化它应该不难。我没有考虑过撤消请求表明服务器已经退役。在我的特定情况下，它并不适用，因为无论如何我们的活动实例列表是公共的。如果攻击者监视了此列表，则对于他来说很容易找出启动服务器或关闭服务器的时间。
– PhilippClaßen
17年8月3日在22:37
OCSP服务器的负载是否较小，因为客户端首先使用下载的CRL？
– allo
17年8月4日在9:23
@ K.Biermann取决于您对“没有知识”的定义。现在，大多数公共信任的CA都会将其颁发的所有证书记录到“证书透明性”日志中。您可以在Google的透明度报告页面上搜索特定域名的证书发行。好的系统管理员将为发布到其域的证书设置通知...但是实际上，我相信很少有系统管理员会这样做。一些公共CA甚至将CT警报作为服务提供。
–麦克·恩斯沃思（Mike Ounsworth）
17年8月4日在16:24
#2 楼
从安全的角度来看，如果私钥没有受到破坏，则不需要撤消。不必要的撤消会给Let's Encrypt基础架构增加一点负担，但不会增加：https：// community。 letsencrypt.org/t/does-revocation-cause-additional-load/25203
评论
有多少次可以确保没有任何可能的方式可以破坏私钥？如果在销毁密钥之前签署了撤销并保留了副本，则可以避免将来密钥被盗用的任何风险，但是如果有人在销毁所有已知副本之前发现密钥已被盗用，则仍具有响应能力。
–超级猫
17年8月4日在23:38
您的链接指向一次性备注。我非常确定，被盗用密钥的撤销的理由很低。如果人们开始撤销成千上万的未破解密钥，那可能会大不相同。
– gnasher729
17年8月7日在6:08
@supercat：对于您使用的证书，您不确定是否有可能破坏私钥。您最好也撤销它们。
– gnasher729
17年8月7日在6:09
@ gnasher729：签署撤销和撤销密钥之间是有区别的。如果可以限制恶意撤销所造成的损害，则可以为确实使用的密钥签名撤销并在现场存储此类撤销。窃取场外撤销的小偷可以使用它们来撤销实际上并未受到破坏的密钥，但这将是他权力的极限（这与窃贼可以将密钥本身保持在远离状态的情况相反-现场）。如果小偷窃取了原始密钥，但撤销存储在异地，则可以撤消这些密钥。如果...
–超级猫
18年6月8日在18:51
...小偷窃取了原件，并且从未使用过它们来签名吊销，因此可能无法撤消小偷的钥匙。归档已签名的撤销有什么不利之处？
–超级猫
18年6月8日在18:53
#3 楼
您忽略的一种可能性是生成撤销，但直到需要时才发布。它确实会给您的基础架构带来一点负担，但隐藏了计算机的拆卸，并在需要时提供了吊销功能。#4 楼
这是一个非常主观的问题。吊销证书没有任何危害。是否只想让它在适当时候到期而不是明确撤销，这完全取决于您的风险分析。当然，如果您不撤销证书，证书被泄漏的风险更大，但是如果您认为这种风险与维护麻烦相比是可以接受的，那么每次明确撤销证书就必须经过，那么您可以接受该风险并这样做。
无论这种风险是否可以接受，我们都必须根据自己的基础结构为自己评估一些风险。您可能想枚举可以访问密钥的人员列表，这些人员是您公司或数据中心的雇员，或者是其他风险（例如盗窃等），并评估这些人员可能意外造成的风险或故意泄漏钥匙。您还需要考虑系统中运行的服务列表，从是否可以滥用它们来泄露密钥方面评估其安全风险。您还必须评估密钥的用途，以及这些密钥将对公司造成多大的损害。基于这些和其他考虑，如果您想接受这些风险，则可以做出明智的决定。
评论
您的EC2实例通常可以居住多长时间？我可以看到答案会有所不同，具体取决于它是始终少于90天，接近90天还是始终高于90天。@CaptainMan很大程度上取决于。如果发行版存在问题，可能是几分钟后终止了它们。否则，通常几天或几周。如果有新的提交，我会尝试尽快部署它们。到目前为止，没有一个实例能达到90天的限制，但是我一直都不会保持这种状态，因为新系统仅在两个月左右的时间内就已经存在。如果代码没有更改并且没有安全漏洞（例如，nodejs最近出现了安全问题，我通过重新部署对其进行了修补），则可能会超过90天。