TLS连接握手阶段Truststore实际应存储哪类证书？

明确结论：应当存储第2类证书，即CA机构自身的证书Google.crt，不需要存储服务端下发的Youtube.pem。

核心校验逻辑 #

TLS握手阶段校验服务端证书的核心是证书链签名验证机制：

• 握手过程中服务端会主动下发自身实体证书（即例子中的Youtube.pem）及对应证书链上的中间证书，客户端不需要提前存储这类站点实体证书。
• 客户端拿到服务端发来的证书后，会从站点证书开始逐级向上校验签发签名：先验证Youtube.pem的签发方是否为Google.crt对应的CA机构、签名值是否合法，直到追溯到一个本地明确信任的「信任锚」证书，整条链路校验通过才会判定服务端身份合法。
• truststore的本质就是存储这些「信任锚」的容器，常规公网TLS场景下，里面存的都是受信任的根CA自签名证书，也就是例子里的Google.crt。

直接存储Youtube.pem的问题 #

把单个站点实体证书直接导入truststore属于*证书固定（Certificate Pinning）*的特殊用法，仅适合强安全管控的内网/测试场景，不适用于公网常规TLS连接：

• 站点证书本身有固定有效期，到期轮换、密钥更新、重新签发是常规运维操作，一旦站点更换证书，本地存储的旧Youtube.pem会立刻失效，直接导致TLS连接失败，维护成本极高。
• 这种方式完全绕过了CA信任链的校验逻辑，相当于仅认可单个特定证书文件，无法适配正常的证书更新流程。

两类证书存储的职责区分 #

注意不要混淆两个证书存储的定位：

• keystore：存储客户端自身的身份凭证，包括本地持有的私钥、对应的客户端证书，仅在双向TLS认证场景下使用，作用是向服务端证明客户端自身身份。
• truststore：存储客户端认可的信任锚，常规场景下仅需导入受信任的根CA证书即可，不需要逐个导入各个站点的实体证书。

内容的提问来源于stack exchange，提问作者BoboSha