您可以固定叶 CA、中间 CA 或根 CA。一切都将起作用，但每个都带有可用性/安全性权衡，具体取决于您的设置细节。

您链接的文章实际上对差异进行了很好的总结：

叶证书。通过固定在您的叶子证书上，您几乎 100% 地保证这是您的证书，因此链是有效的。叶证书的到期时间往往很短，例如，如果由于私钥被泄露而重新颁发 SSL 证书，您的应用程序将被阻塞，直到您可以推出更新。当然，如果您经常循环使用证书，情况也可能如此。

中级证书。通过固定中间证书，您相信中间证书颁发机构不会错误地为您的服务器颁发证书。这也有一个好处，只要您坚持使用相同的证书提供者，那么对您的叶证书的任何更改都将起作用，而无需更新您的应用程序。

根证书。通过固定根证书，您信任根证书颁发机构以及他们信任的任何中介不会错误颁发证书。通常，根和中间机构是同一家公司，在这种情况下，您信任的人数差别不大，但情况并非总是如此。

除了文章提到的内容之外，我会说，然后您固定一个证书，您正在删除 CA 撤销该证书的能力，因为您的应用程序隐含地信任该证书并且永远不会去寻找它的状态信息。按照这种逻辑，固定 CA（中间或根）的好处是，当您的叶子证书过期时，由于您不小心在 github 上发布了私钥或其他任何东西而被黑客入侵，您可以轻松要求 CA 撤销它并向您发出新的一个。您的应用程序将继续工作。

就个人而言，我会避免固定叶子，因为您实际上是在删除使证书成为证书的部分：撤销和链接到信任根。您最好openssl genrsa将公钥固定在您的应用程序中，因为您并没有真正从它作为证书中获得任何好处。

也就是说，当您固定 CA 时，您的应用程序将信任该 CA 颁发的任何证书，并且可能信任其他人。您可能对此感到满意，可能是因为它是您的私有公司 CA，或者您可能需要实施额外的证书验证逻辑以确保证书链到固定 CA并且名称与您的应用程序期望的匹配（并说服自己 CA绝不会真诚地向任何不是您的人颁发具有该名称的证书）。

总结：固定叶、中间 CA 或根 CA 都是可接受的做法，但有一些轻微的利弊。做任何对你的应用有意义的事情。

您不应在 99.9% 的用例中固定中间证书或叶证书。

您的叶子证书可能因多种原因而被吊销。您可能会发现您需要自己吊销证书，或者 CA 因发现操作错误而吊销了您的证书。固定叶证书有可能将您锁定在您的应用程序之外，直到您可以更新应用程序。

不保证中间证书将保持有效并且可以在任何给定时间更改，恕不另行通知。这会将您完全锁定在您自己的应用程序之外，直到您可以更新应用程序。

您最安全的选择是使用由Mozilla、Apple、Microsoft等维护的受信任的根存储。或者将该信任委托给您的软件将运行的平台（例如操作系统）。

如果您肯定要使用证书固定，那么您应该避免固定中间件或叶子，并固定根证书。

固定根也不是没有自己的风险，但是根固定给您带来问题的可能性要小得多。作为旁注，您应该准确了解您计划通过固定来防止哪些威胁。了解固定在您的威胁建模中的确切位置并相应地进行计划。很多时候你会发现你实际上并不需要固定证书。

您可以阅读更多有关digicert 对证书固定的看法。

这只不过是对其他两个答案的评论，但我想强调的是，固定根证书也很棘手和危险，如果它比固定中间证书更危险的话。

如前所述，CA 可能会因中间证书过期或其他操作原因而无法预测且不经通知地切换中间证书。

出于同样的原因，CA 也会切换它们用于新证书或在提供下载的默认链中使用的根。他们可能会提前通知，但即使他们这样做，您也可能必须定期查看他们的新闻和支持网站才能找到它。

较老的 CA 积累了不拘一格的根证书，这些证书是通过并购获得的，或者是为了升级到更现代的密码学而颁发的，以替换将过期的旧证书，用于不同类别的证书（EV、S/MIME、政府、等），或其他原因。

较新的 CA 可能会自行生成一些根、来自上述旧 CA 之一的交叉签名，或者可能是从旧 CA 获得的整个根。

很难理解哪些根与您相关，您的客户端使用哪些 TLS 客户端和版本，以及它们的路径构建、固定和验证算法如何工作。

您的 CA 可能有关于他们的信任锚图如何组合在一起的详细文档。他们可能会提供有关固定的建议。他们可能会提供承诺。他们可能无法保留它们。如果您因自己或他们的选择而陷入困境，他们可能会与您合作。

例如，亚马逊列出了 5 个根证书（1 个从另一家公司获得）。有交叉签名。构建一个图可能会发现总共涉及大约 10 个根。一个误入歧途的 AWS 证书客户可能会固定大约 5 个不同证书中的 1 个，并且拥有一些今天可以工作并在以后爆炸的东西。我没有检查他们的文件。（此外，亚马逊自己的一些服务使用其他 CA。）

作为进一步的背景，Ryan Sleevi 写了两篇 关于路径构建复杂性的文章。