我根本不清楚你不明白什么，所以我会慢慢理解。

首先是一些术语。弄清楚这一点很重要，因为否则你无法正确地知道你在听什么和说什么。

密钥对：在数学上相关的私钥和相应的公钥，用于公钥密码术（PKC），也称为非对称密码术。对于 RSA，通常是人们在不指定时唯一知道的 PKC，公钥由一个模数 N 和一个公共指数 E 组成，它是两个大素数的乘积，公共指数 E 可以而且通常很小（实际上它通常是 3 或 65537）；私钥至少包含 N 和一个私钥 D 使得 E x D = 1 mod phi(N) 或至少 lambda(N)；在实际使用中，私钥通常包含可以加快计算速度的附加值，但还有很多其他问题，因此我不再赘述。

数字签名：使用私钥为指定的数据块（几乎总是“真实”数据的散列）计算的值，以便可以使用相应的公钥来确定给定的签名对于给定的签名是否正确数据并且只能由给定的私钥生成。这允许验证者确定数据没有被更改或伪造，并且数据已发送或至少被私钥持有者看到，但它没有说明该持有者是谁。

（X.509 又名 PKIX）（身份）证书：一种数据结构，包括实体的公钥和该实体的身份；加上与实体和/或 CA 相关的一些其他信息；所有这些都由称为证书颁发机构或CA的（通常）不同的实体签名。我希望您仅将 Verisign 用作示例；它是一个 CA，但不是唯一一个；您可以从 GoDaddy、Comodo、 StartCom LetsEncrypt 等其他人那里获得同样出色的 Internet 证书。如果您信任给定的 CA 可以正确颁发证书，那么您可以信任它颁发的证书中的大量公钥和身份。2017 年更新：StartCom 不再好，因为它被 WoSign 收购，后来被抓到违反 CABforum 规则，现在被广泛不信任。OTOH LetsEncrypt 现在广受信任且免费。这进一步强调了拥有多个 CA 的重要性！更多更新：现在威瑞信也很糟糕；尽管在 2017 年没有如此广泛地宣传，但赛门铁克（已经收购了 Verisign 和其他几个品牌，但继续主要使用现有名称）被抓到了误传和逐渐不信任的问题，他们通过将业务出售给 DigiCert（后者很快取代了受污染的赛门铁克证书）来解决这个问题与 Digicert 的）。但是我在下面的示例中留下了伪 Verisign 名称，与 Q 匹配，因为这只是一个示例，任何名称的逻辑都是相同的。

用户（终端实体）证书：包含 CA 以外任何事物的密钥和身份的证书，例如 SSL 服务器、SSL 客户端、邮件系统等。

(CA) 根证书：包含根 CA 的公钥的证书。由于根“之上”没有 CA，因此使用了使用 CA 自己的私钥的虚拟签名，但这没有安全价值。您必须决定（或委托）是否“带外”信任该密钥，即基于密码计算以外的原因。

链或中间证书（和 CA）：（如您的问题所示）大多数 CA 现在以分层方式运行，其中不使用根密钥直接颁发用户证书。相反，根 CA 及其根（私有）密钥用于为多个中间或从属 CA 签署证书，每个 CA 都有自己的密钥对。然后每个中间 CA 可以颁发用户证书，有时也可以颁发第二级中间证书；这可以扩展到多个级别，但很少需要。

由于您提到了浏览器，因此您显然（仅？）关心 HTTPS（基于 SSL/TLS 的 HTTP）的证书（和密钥）。这是证书和 PKC 的常见且重要的用途，但不是唯一用途。

现在，案例 1。由于此案例不考虑链/中间体，而 Verisign 确实使用了它，因此我将使用假设的SimpleCA。首先，没有CA 拥有或向您发送您的私钥。您生成您的密钥对并将您的公钥以称为证书签名请求或CSR的数据结构发送给CA。CSR 还应包含您的姓名；对于 SSL 服务器，这通常是服务器的域名 (FQDN)。CSR 包含一些您现在可以忽略的其他数据。CA 验证您声称的身份（对于 SSL 服务器，您“控制”指定的域名），通常会收取费用，然后创建包含以下内容的证书：

• 您的姓名（此处为 SSL 服务器 FQDN）作为主题和/或一个或多个名称作为SubjectAlternativeNames，尤其是近年来
• 您的公钥为SubjectPublicKey，通常将其哈希为SubjectKeyID
• ValidityPeriod ，指定证书的有效期，由 CA 选择，部分取决于您支付给他们的费用
• CA作为Issuer的名称，通常是一个AuthorityKeyID，它也标识 CA
• 您现在可以忽略的其他一些数据

并且整个结构使用 CA 的私钥签名（这意味着可以使用 CA 的公钥对其进行验证）。CA 将此证书与您已有的私钥一起发回给您，以便在您的服务器中使用。

以前，假设SimpleCA表明它可以被信任以适当地验证申请人并支付费用，浏览器供应商（Microsoft、Mozilla、Google、Apple 等）同意将其公钥包含在他们的浏览器中，通常以 SimpleCA 的根的形式证书。现在，当某些浏览器连接到您的服务器并且您发送的证书实际上显示“Aviel-server 经 SimpleCA 批准”时，浏览器会找到 SimpleCA 的根证书和SimpleCA 的公钥，并使用它来验证您的证书是否已正确签名，并且您的证书中的服务器名称与用户想要的 URL 中的服务器匹配；如果这两个都通过，它会接受您证书中的公钥作为您的正确公钥，并使用它来完成 SSL/TLS 握手。如果不是，它会显示某种警告或错误。

除非，也就是说，您的证书被撤销。如果您的私钥被泄露，或者如果 CA 确定您不再控制声称的身份（包括如果他们发现您从未做过但在应用程序上欺骗了他们），CA 会发布您的证书已被吊销，因此浏览器不会即使签名仍然可以验证，也要相信它（因为 RSA 计算是一个独立于时间或环境的固定数学过程）。但是撤销，以及它是否、何时以及如何运作，本身就是一个复杂的话题，这个答案已经足够大了。（编辑）OCSP 装订如何工作？涵盖撤销（实际上包括 OCSP 和 CRL），内容十分彻底。如果您的证书已过期（超过有效期）也无效；这很容易让浏览器检查。形式上，证书也可以在其有效期开始之前无效，但实际上 CA 不会颁发“过期”证书，除非有人弄乱了时区或其他东西。

但是，浏览器中提供的 CA 根证书集通常只是默认值；浏览器用户可以选择添加新的根或删除现有的根。如果是这样，那可能会使您的服务器在以前不受信任时受到信任，或者在以前不受信任。

案例2（链）。正如您所说，中间 CA 以及中间证书或链证书的一个原因是使根密钥处于脱机状态。另一个原因是允许像用户一样管理中间 CA：它们可以有有限的有效期并可以更新，如果被破坏（或不再需要）它们可以被撤销，这会自动发生并且几乎是不可见的。另一方面，如果您必须扩展、替换或撤销根，基本上世界上的每个浏览器都必须更新。这是很多工作，而且永远不会完全完成，因为用户会拒绝或忘记安装更新并信任不安全的 CA，因此可能是不合法的服务器。

使用单个中间/链证书，过程更改如下。假设VerisignServerB在VerisignRoot下发布，并依次用于发布Aviel-server。（实际名称更长，但这更容易看到。）然后您的服务器被配置为将 Aviel-server 和 VerisignServerB 都发送到浏览器。浏览器检查 VerisignServerB证书是否在 VerisignRoot公钥下正确签名（和以前一样，通常存储为自签名根证书），并且 Aviel-server证书在来自该证书的VerisignServerB公钥下正确签名，并且 Aviel-server证书名称匹配所需的。只要两者都是，检查签名的顺序无关紧要。

SSL 证书框架 101：浏览器如何实际验证给定服务器证书的有效性？ 有一个很好的图形示例，可以帮助您。

对于多个中间/链证书，当使用时，扩展现在应该是显而易见的。

具有威瑞信公钥的浏览器将如何识别我的公钥确实是有效的威瑞信密钥，可用于加密我的威瑞信私钥可以解密的消息？

它只需要验证 Verisign 的签名。威瑞信在您的证书上的签名证明该证书确实来自威瑞信并且不是在您的计算机上伪造的。签名只是用他们的私钥签名的消息。由于私钥仅加密相关的公钥解密（它以两种方式工作），因此浏览器可以使用其公钥解密该签名（因为它是公开的，任何人都可以获得它的副本，并且它包含在您的证书中，所以浏览器从那里得到它）。如果它可以解密该消息，则意味着它是用他们的私钥加密的，这反过来意味着它来自他们。

现在，浏览器应该将解密的消息与什么匹配？签名只是整个证书的散列。所以它需要做的是计算哈希本身（例如它得到 123XYZ）并将其与解密的签名进行比较。如果它也得到 123XYZ，那意味着两件事：

1. 该威瑞信确实是该证书的作者（否则解密的消息将与计算的哈希不匹配）
2. 证书没有被修改（否则哈希会不同）

我假设它是针对服务器公钥数字签名进行测试的 Verisign 公钥数字签名？，

不，它是针对证书哈希进行测试的。见前文。

如果它确实是经过测试的数字签名，我假设所有 Verisign 公钥之间存在关系？

威瑞信有一个唯一的、唯一的公钥和私钥。这个问题没有意义。

或者，威瑞信分配给特定客户端（网站/设备/等）的每个公钥与浏览器/操作系统包括的公钥之间可能只有关系。

更准确地说：他们可能会为您创建公钥，但如果您已经拥有公钥，您也可以将您的公钥交给他们并且他们会签名。

他们为您签署的证书与浏览器中的证书之间的关系是：浏览器中的证书是根证书，浏览器默认信任的证书。默认情况下，并非所有浏览器都信任威瑞信交付给客户端的证书，因此浏览器需要检查谁颁发了该证书。如果颁发者受信任，则浏览器信任您的证书并继续让您访问您请求的网站。如果不是，它将检查发行者的发行者（如果有），并查看它是否受信任。它将继续检查颁发者的祖先，直到它到达受信任的根证书颁发机构，或者如果找不到任何证书，则不信任该证书。

因此，在您的情况下，它将看到 Verisign 是颁发者（具有中间证书），而 Verisign 的颁发者是 Verisign 本身（但具有另一个称为根证书的证书），并且由于 Verisign 的根证书安装在每个浏览器上，因此它是信任，这反过来又会导致信任您的证书。

我知道对它们的需求是安全性，因此根 CA 私钥可以保持离线，如果有更多原因我很想听听它们。

安全是一个很好的理由，是的。

关于链验证，我假设服务器公钥数字签名针对服务器中间证书数字签名进行测试，如果它现在有效，则轮到中间证书数字签名针对浏览器/操作系统预安装的公共进行测试密钥数字签名，如果这也是有效的，则客户端已成功验证中间证书和服务器的公钥。

见上

在学习 SSL 的工作原理时，我制作了这张图。这可能会有所帮助。