更新证书时是否应该更改私钥？

#1 楼

我要说的是，他们的建议不是一个很可靠的建议，除非您使用的密钥太小，否则您将遇到另一个问题。据估计，至少可以确保您安全到2020年，甚至更长。如果您使用的是1024位或更少的密钥，则说明您不符合标准，我建议立即更新为2048位。如果您当前使用的是1536位密钥，则应该安全一两年。

当然，从学术上来说这都是。某人一年内能够（或倾向于）破解您的1024位SSL密钥的可能性非常低。

正如您所链接的问题中提到的那样，有优点也有缺点。

优点


为攻击者减少破解密钥的时间。如果您仍在使用合理的密钥大小，那将是一个有争议的问题。
停止可能危害您私钥的不法分子。不太可能，但是未知。
让您有机会增加密钥大小，使其领先于曲线。除非您使用非常小的密钥，否则可以为您提供防止密钥破解的任何具体保护。
浏览器的SSL检查/ anti-MitM插件可能会警告用户密钥已更改。在我看来，这是一个薄弱的缺点-大多数用户不会使用此功能。
与更严格的HSTS政策和实施有关，可能会引起临时警告。您可能还会做其他事情。

因此，从两方面来说，都有一些薄弱的原因，并且可能需要考虑一些极端情况。只要您使用2048位或更高版本的键，我都会稍微倾向于“除非您需要”，否则不要倾斜。

最重要的是要问他们为什么他们认为有必要-可能是您有一个与基础架构相关的原因来更新我们不知道的密钥。如果他们不能提出一个可靠的论点（“为什么不正确”是不正确的），那么他们应该适当地重新评估他们的建议。

#2 楼

更改私钥不是最佳实践，而是一种广泛的实践。实际上，它与安全性几乎没有关系，而与通用CA处理证书更新的方式有很大关系，即，大多数时候，CA就像新证书一样，具有新的私钥生成。在CA方面，不做任何特殊的续订操作就比较简单。因此，就有了更改密钥的习惯。

从安全的角度来看，即使情况相似，相同的系统管理员也不会坚持每年为其SSH服务器生成新密钥。或者，更确切地说，更改SSH服务器密钥有点不方便，因为它破坏了客户端的.ssh/known_hosts文件。因此，习惯上避免更改SSH服务器密钥。因此，SSH服务器密钥是长期存在的。没有人真正跳过这一点。他们为什么要担心具有类似加密强度的SSL密钥？

最佳做法是，在技术进步使您的密钥有些脆弱时，考虑到普遍的偏执狂（通常称为“合规性”）来更改密钥原因”）；因此，您应该考虑到现在，在2013年，应该用更长的密钥代替1024位RSA密钥，尽管我们仍然无法破解这样的密钥。如果您的RSA密钥是1536位或更宽，则没有密码理由要创建一个新密钥（但是再次，也许在CA端更方便地更改它）。

#3 楼

答案不是技术或加密，而是关于人的。有了工作变更（听不到心烦的管理员？），服务器迁移，灾难恢复测试，备份以及私钥之类的内容，可能会有所暴露。

鉴于上述情况，密钥更新是一种安全性最佳实践。

#4 楼

不用担心有人将您的RSA密钥分解。对于州级对手来说，分解1024位RSA密钥可能是可能的，但是即使对他们来说，这可能也不划算。 2048位密钥分解可能要几十年才能实现。

我主要担心的是您的私钥在服务器漏洞中被盗。由于攻击者可能在您的服务器上存在持久性恶意软件，因此在过去的入侵中获得的收益还不清楚。因此，您需要重新安装服务器以保护新密钥。

另一个问题是，某些弱SSL套件（主要是基于RSA加密的家族）使用您的长期密钥来保密，并且不仅用于身份验证。有了这些妥协，您的服务器密钥便可以解密与使用这种弱套件的服务器之间过去的所有SSL通信。使用新密钥并安全删除旧密钥会限制此类攻击的影响。

因此，如果您的服务器仍启用了这些套件，则强烈建议您定期更改密钥。

#5 楼

您在HeartBleed之后更改了密钥吗？
您的数据中心技术人员对坏硬盘有何作用？
去年有人离开了运营组织吗？
最后一次是什么时候您何时旋转管理员密码和ssh密钥？

所有这些问题都应该使您开始思考密钥的完整性。我并不是说它们很可能已受到损害，或者任何人都将能够滥用它们。我正在尝试让您考虑为什么要旋转它们。

旋转钥匙应该超级容易，并且是一种很好的安全卫生措施。如果您因为困难而没有这样做，那就是一个严重的问题。构建工具和流程以使其变得容易。如果不这样做，您最终将无法轮换更重要的事情。

#6 楼

您使用密钥的次数越多，给予攻击者的时间就越多。尽管当前的技术认为不可能打破2048位，但要格外谨慎，更换钥匙也不是一件坏事。

此外，有人可以设法获取您的私钥，而您却无法检测到它。如果他不能重复该动作，那么续约的好处就非常明显。

#7 楼

尽管我同意每次续签证书都不会产生新密钥的技术原因，但我不会立即向您的安全团队/经理提出挑战，并就此问题打电话给他们。

与产生新密钥同样有效的技术原因。例如，在大型组织中，IT集中化，技能，过程和良好实践的级别各不相同，因此集中化的安全管理区域可能需要此类实践来帮助减轻某些风险，这也可以帮助使过程变得越来越小可管理的。尽管从技术角度来看，更复杂的程序可能更正确，但它们更难以记录，并且使员工更难以知道他们正确地遵循了这些程序。如果这种做法不会产生大量开销，那么采用和维护更简单的“始终执行X”方法可能会更容易。

从另一个角度考虑它。您组织中负责管理证书的每个人是否都对您有相同的意识和了解，并且对它们的理解是否充分/专心？员工更替的水平是什么？在何种程度上需要关注前员工可能会访问的敏感数据的数量。

每当考虑安全性时，人为因素几乎是总是比技术方面重要或重要。政策和程序需要考虑人的因素，并试图确保这些政策和程序的结构能够帮助员工做正确的事情，即使他们可能不完全理解为什么需要这样做。 br />

#8 楼

SP 800-57第1部分已修订，密钥管理建议

NIST关于RSA密码周期的建议似乎为1-2年。

#9 楼

确实与更改密码相同。如果有人在更改密码时正在破解密码，则必须重新开始。或者，如果密码或私钥被窃取，则续订会使他们的失窃密钥失效（假设他们无法轻易再次窃取它）。

更改私钥可能是一个好习惯每年或每隔几年，以便您知道它在需要更改时不会损坏任何东西，但是对于证书本身的安全性而言，这不是必需的。

#10 楼

一些人提出了这样一个事实，即很少旋转ssh主机密钥作为不旋转ssl密钥的理由。这似乎是另一个要解决的问题。 （我为一个稍微偏离主题的答案表示歉意，但这里有人提到它，因此似乎很合适）。

请参阅上面的答案，以了解为什么有人希望旋转键。

对于合规性需要旋转ssh主机密钥但担心可用性对最终用户造成影响的每个人，以下内容特别有用。

1）部署ssh_ca
（man ssh-keygen中非常完整的说明）

ssh-keygen -f ssh_ca -b 4096

2）将证书分发给用户：将证书授权行添加到〜/ .ssh / known_hosts

@cert-authority *.domain.name ssh-rsa AAAAB3[...]== Comment

3）签名主机密钥（确保将每个密钥限制为单个主机）

ssh-keygen -s ssh_ca -I host.domain.name -h -n host.domain.name -V +52w /etc/ssh/ssh_host_rsa_key.pub

4 ）配置服务器以显示证书（/ etc / ssh / sshd_config）：

HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

客户端现在信任由CA签名的任何主机密钥（否第一次连接时更盲目地接受密钥信号）

现在可以滚动主机密钥了不会影响客户。密钥签名可以纳入主机构建/编排过程。

这是一个很好的参考。该项目围绕使用ssh_ca自动过期的用户访问权限创建了一些有用的工具。