为什么当有多个证书时浏览器知道使用哪个证书？

我对服务器和网络世界还很陌生，我希望问题很清楚，不要那么琐碎。我最近遇到了以下场景：

1. 有一个根证书 A，它将在几个月后到期。还有另一个新的根证书 B，旨在替代 A。A 和 B 都是自签名的。A 的 CA 受新旧浏览器/OS 信任，而 B 的 CA 仅受现代浏览器/OS 信任

2. 我们的服务器目前正在使用交叉证书 A->B（B 由 A 签名）。然而，由于 A 即将到期，我们应用了另一个交叉证书 C->B（B 由 C 签名，C 的 CA 被新旧浏览器/操作系统信任）作为替代。

3. 现在，在 UAT 环境中，我们更新证书 C->B，对于客户端，我尝试使用一些旧版浏览器进行测试，我验证了只有 A 的 CA 和 C 的 CA 是可信的，而 B 的 CA 不是。对于 PROD 环境，我们保持不变，即使用证书 A->B

4. 我使用提到的浏览器访问 UAT 站点，并首次验证使用的证书是 A->B。令人惊讶的是，对于后续访问 UAT 和 PROD 站点，使用的证书是 C->B（在客户端检查）。

我的问题是，这是正常行为吗？为什么自从第一次访问 UAT 站点以来，客户端“知道”使用 C->B？我还使用openssl s_client验证 PROD 服务器是否仍在使用 A->B。浏览器如何知道要使用哪个证书并相应地“更新”证书？

编辑于 2022-Dec-13

1. 我们的主要目的是支持非常旧的浏览器/操作系统和现代浏览器/操作系统。即即使证书A过期，所有浏览器都可以成功访问我们的站点。
2. 我认为我的主要问题或怀疑是，如果以下内容为真：

• 旧版浏览器，第一次访问UAT站点，由于某种缓存机制，显示服务器正在使用证书A->B
• 在第一次访问 UAT 站点后，服务器实际上将新证书 C->B“推送”到在服务器中配置的客户端。现在，浏览器，甚至操作系统级别都承认最新的证书是 C->B，而不是 A->B。
• 尽管 C->B 已被确认，但证书 A->B 仍保存在浏览器/操作系统中。但是浏览器以某种方式知道要使用较新的证书 C->B 进行验证。意味着我们的目的可以实现。