客户端在验证证书时，有三种可能：

• 证书由客户端已经信任的 CA 签名（并且它知道公钥）。在这种情况下，客户端将证书视为有效。
• 证书由客户完全不知道的 CA 签署。在这种情况下，客户端将证书视为无效（并且浏览器可能会显示警告消息而不是加载页面）。
• 证书由客户端不知道的 CA 签名，但该证书具有由客户端知道的 CA 签名的证书。（在这种情况下，服务器通常必须同时发送它自己的证书和签署其证书的 CA 的证书——称为“中间 CA”）。由于中间 CA 的证书是由客户端已经信任的 CA 签名的，它知道可以信任它，并且由于服务器的证书是由中间 CA 签名的，所以客户端知道它也可以信任它。

请注意，CA 证书是“特殊的”——仅仅因为您拥有由受信任 CA 签署的证书，这并不意味着您可以签署其他证书并让客户信任它们——除非您的证书被标记为对签署其他证书有效.

它没有。它将被视为无效证书。

例如，任何人都可以对证书进行自签名，本质上是为自己充当 CA - 但浏览器不信任此类证书，因此用户会收到有关此效果的警告。

已经有一些很好的答案，但我觉得我应该补充一点，只是为了完整起见，并不总是需要将完整的链呈现给客户。

对于我们的工作原理示例，这是一个包含四个（！）证书的证书链，包括根和最终实体（注意我不推荐这样的设计）：

请注意，您可以通过在文件资源管理器中双击 .cer 格式的证书文件并选择“证书路径”来在任何 Windows 机器上获取此属性页面

当客户访问网站时，可以通过两种方式验证该链。网站可以直接向客户出示网站、发行人和保单*证书。或者，一些客户端可以在证书上查找扩展属性，这些属性提供了下载链中下一个证书的地址。

至少对于 Microsoft 证书客户端，此证书扩展称为“授权信息访问”(AIA)，其格式与 CDP（CRL 分发点）字段类似，可用于确定链中下一个证书的位置。您可以在具有认证路径的同一窗口的“详细信息”选项卡上看到它，如下所示：

有关 CDP 和 AIA 的更多信息，请点击此处。

因此，在此示例中，以下是客户端验证在未预先显示整个链的情况下的工作方式：

1. 客户通过 https 访问 website.com 并获得“网站”证书。
2. 客户端验证这不是受信任的根并且不是自签名的。为“颁发者”证书查找 AIA，下载该证书并验证该证书的公钥签署了“网站”证书。
3. 客户端验证“颁发者”证书不是受信任的根并且不是自签名的。为“Policy”证书查找 AIA，它会下载该证书并验证该证书的公钥签署了“Issuer”证书。
4. 客户端验证“策略”证书不是受信任的根并且不是自签名的。但是，它发现此证书的颁发者是受信任的根之一，并验证根证书的公钥签署了“策略”证书。

对于链中的每个证书，都会检查 CDP 的证书吊销列表 (CRL)，以确保没有吊销。

如果客户端在任何时候都找到了受信任的证书，则“网站”证书已被验证为由受信任的根颁发并且未被撤销。其他检查（如有效期）仍可能导致证书无效。

如果客户端在任何时候发现了一个自签名的、不受信任的证书，则“网站”证书尚未被验证为由受信任的根颁发。通常客户端会在此时弹出警告。

是的，这意味着您可能拥有一个非自签名的受信任证书，但这不是常见的情况。

*如果客户端信任根，它应该已经拥有根证书的副本 - 它需要手动添加到受信任的根权限列表中！（这也是为什么某些根 CA 仍然是 SHA1 的原因，这不是问题）。然而，一些网站仍然会提供根证书，因为一些软件会期望一个完整的链，包括冗余根。每当您处理与证书交互的软件时，经常会出现这种荒谬的情况。

附录 - 如何信任根

虽然我提到根是手动信任的，但大多数情况下，您的受信任根证书将通过非手动机制分发到您的机器，通常捆绑到软件的每个版本中和/或随自动更新一起分发。以下是主要网站接口证书使用软件的常用方法和策略列表：

1. Microsoft 受信任的根证书计划更新

   您可以在此处获取最新的证书包。

2. 基于 Active Directory 域的分发（请注意，链接的文章还介绍了手动将受信任的根添加到本地 Windows 计算机的方法。）

上述方法都更新了被包括 IE 和 Edge 在内的多个应用程序使用的 Windows 操作系统证书存储。

3. Mozilla 根存储策略
4. 根证书政策 - Chromium 项目（包括谷歌浏览器）

Mozilla 和 Chrome 都能够独立于操作系统信任证书（有效地维护自己的受信任根存储），并且还可以订阅操作系统受信任的根存储，具体取决于应用程序和特定操作系统中配置的设置。

应用程序特定根存储中的可信 CA 将根据其可信根程序的支持添加和删除。