在SSL/TLS中，服务器应该将其证书显示为链的一部分。从理论上讲，服务器应该确保发送的链是正确的，如果服务器发送的确切链无法验证，客户端“道德上有权”拒绝连接。但是，允许客户做出额外的努力；如果他们可以使用另一个链验证证书，则可以继续。

因此，如果服务器发送有缺陷的链，不能正式责怪某些客户端未能验证服务器的证书。

当客户端尝试构建备用链时，它将使用以下部分或全部方法：

• 客户端可能已经在本地安装了中间 CA 证书（在 Windows 系统中，“中间 CA”存储就是为此而生的）。
• 服务器发送的证书可能会被重复使用（但可能不会以相同的顺序）。
• 客户端可能有权访问某些 LDAP 服务器或等效项，其中可以通过主题名称查找某些证书（这可能发生在 Windows / Active Directory 设置中）。X.509 的最初计划是应该有一个全球目录，就像某种通用 DNS，但它从未发生过。
• 客户端可能会尝试通过在证书的授权信息访问扩展中找到的 URL 下载其他中间 CA 证书。

最后一种方法通常会起作用。一个良好颁发的证书将包含一个 AIA 扩展，其 URL 指向颁发它的 CA 的证书。该证书本身可能包含指向上层 CA 的 AIA 扩展，依此类推，直至根。只要所有 URL 都可以公开访问，网络正常运行，并且没有系统管理员以可悲的借口阻止该机制（不幸的是，我已经看到它完成了），那么链就会成功重建。现代 Windows 系统会自动执行此操作。

但请记住，不允许SSL 客户端以这种方式行事。需要注意的重要一点是 URL-following 依赖于 HTTP。Web 浏览器知道 HTTP；这是浏览器的核心功能。但是，使用某些 SSL 库的独立应用程序可能无法发出随机 HTTP 请求，甚至根本不愿意这样做。一些 SSL 库提供协议支持，但依赖调用者实际提供网络连接（调用者打开并操作 TCP 连接，该库纯粹是在计算方面）。根据应用程序的设计方式及其 SSL 实现，您可能会也可能不会成功推送必要的额外证书。

如果一开始就正确安装了服务器，那就更好了。

浏览器通常会缓存他们见过的中间证书。如果您对缺少通用中间证书的服务器使用 firefox，则可以对此进行测试。如果浏览器已经看到这个丢失的证书，它将允许连接。但是，如果您使用新的 Firefox 配置文件并重试，它会报错，因为证书缓存是按配置文件完成的。

在我看来，这是一种不好的行为，因为它会导致浏览器的行为不可靠。当使用浏览器进行的测试没有抱怨时，管理员通常不会意识到 HTTPS 设置被破坏，因为他们缓存了丢失的中间证书。