SSL固定和证书到期

这个问题涉及在客户端应用程序中针对web api和证书使用SSL固定 到期日

场景：

我拥有example.com，并拥有一个子域，其中承载api，例如：api.example.com

我希望通过SSL使用api，因此为子域创建SSL证书

获得证书后，我有：

• 公开证书
• 中级证书
• 私钥

据我所知，我在我的Web服务器上安装了这些证书

然后，我希望我的客户端应用程序连接到api。以减轻对中间人的攻击 攻击时，我希望使用SSL固定，这样客户端将只与我的api通信，而不与我的api通信 有人在欺骗它

为了在客户端应用程序中进行pin，我有两种选择，要么针对公众进行pin，要么针对中间用户进行pin 证书

假设我实现了这个

api.example.com上的证书过期时会发生什么情况

据我所知，客户端应用程序将不再工作

我是否需要重新生成一整套公共/中间/私人项目？然后 在应用程序中放置新的公共证书或中间证书

问题：

在api.example.com上的证书更新之前，我仍然希望客户端应用程序能够正常工作。 当然，新证书可以放在客户端应用程序中，但像推出这样的事情需要时间

我该怎么办

我读到谷歌每个月都会更新他们的证书，但不知何故，它还是设法保持公钥不变：

如果这是可能的，那么解决方案就是简单地从服务器提取公钥，并对照本地存储的公钥进行检查……但是谷歌是如何做到的呢

谢谢

---

Chris

注意：我更熟悉浏览器到服务器的固定（HTTP公钥固定-HPKP），而不是应用程序到服务器的固定，但我认为其原理是相同的。在HPKP中，固定策略由服务器作为HTTP头提供，但请理解，这通常内置在应用程序中，而不是从HTTP响应读取。因此，请阅读下面的答案，并记住所有这些：

锁定通常是针对密钥而不是证书的，可以是多个级别。所以你有几个选择：

重复使用相同的密钥/crt生成新证书。有些人（我认为正确！）建议在每次更新证书时生成新密钥，但这在使用固定时很复杂。那么，钉扎是否会鼓励像密钥重用这样糟糕的安全习惯呢

在您的锁定策略中有几个备份密钥，并在证书续订时循环使用它们，丢弃最旧的密钥并添加一个新密钥，这样就有足够的时间和更新，永远不会出现短缺。就我个人而言，我更喜欢在证书续订时生成密钥，而不是有一些备份，这些备份可能会或可能已经被破坏，所以我也不是这方面的特别粉丝。您应该有多少备份？例如，如果您需要重新颁发证书，因为在续期方面存在妥协，并且还把它搞砸了？那么2呢？3.一百

再往上钉。比如说第一个中间证书或根CA证书。因此，任何新颁发的证书仍然是可信的（前提是它由相同的证书路径颁发）。这有四个缺点：i）您仍然会错过由该固定证书颁发的证书（我认为这不是一笔大交易，因为您仍然大幅减少了攻击面，但仍然是一些人关注的问题），ii）您无法保证客户会使用该中间证书，因为有时存在多个有效路径。第二个更重要。您可能认为提供中间证书可以保证使用该证书，但事实并非如此（大量的sha-1示例）。iii）不能保证新的证书将由相同的中间人或根用户颁发（特别是当技术发生变化时，如sha2的引入），因此对我来说，整个选项是非初学者iv）它将您与使用相同的证书提供商联系在一起（也许没什么大不了的，但我喜欢移动的自由）。不确定应用程序是否在本地支持此功能，但浏览器肯定支持

提前续订，在策略缓存过期之前不要使用新密钥。例如，如果您有一年的证书和30天的锁定策略，那么您可以在11个月后续订，将新密钥添加到策略，然后等待30天，这样您就可以确保每个人都会选择新策略，或者至少旧策略已经过期，然后切换密钥和证书。取决于短期策略，并且可能会浪费部分时间（在本例中至少30天），除非证书提供商从旧策略到期后的第二天开始提前提供证书。对于一个应用程序，如果钉住策略是硬编码的，那么这可能涉及推送更新所需的时间长度

归根结底，因为证书确实需要更新，我不太喜欢固定。我不认为定期更新、半永久性的东西是正确的答案。甚至有人谈论在浏览器中预加载固定策略，这让我不寒而栗

固定提供了一种保证，即流氓CA不会为您的域颁发证书，但与固定的麻烦相比，这种可能性有多大？像证书透明，甚至仅报告钉扎这样的东西可能是解决该问题的更好办法，即使它们实际上没有阻止该攻击

最后，本地安装的根目录（例如，用于防病毒扫描程序或公司代理），绕过了锁定检查（至少在浏览器上），这在我看来再次降低了它的有效性

因此，在使用pinning之前请仔细考虑，并确保您了解所有后果。

建议对签署服务器证书的中间CA的证书进行pin

"