想象一个具有以下参数的 SSL 证书 - 我们将通过做所有可能的错误的事情来编造最糟糕的证书：
- 古老而易受攻击的密码
- 存在漏洞的签名算法
- 错误的签名（签名与内容不符）
- 明确撤销（证书位于我们正在使用的 CRL 上）
- CA 在证书存储中明确标记为不受信任
- 连接的域名/CN 错误
- 已到期
- 另一个域名的另一个证书重复
- 自签名
对于证书的所有这些错误情况，用户代理按照什么顺序进行检查？
或者换句话说，如果我在网站上使用这个糟糕的证书，我会收到什么错误消息 - 一旦我修复了它，下一步会发生什么，等等。
这些错误对连接的安全性都有不同的影响，因此客观上有些错误比其他错误更可怕 - 但是否有一个标准在某处定义这些问题的“优先级”？（例如，如果证书是用于错误的网站并使用破解的加密，告诉我证书已过期是愚蠢的）
答案1
RFC 5246对 ServerHello 消息有如下描述：
当服务器能够找到一组可接受的算法时，它将发送此消息以响应 ClientHello 消息。如果找不到这样的匹配，它将以握手失败警报进行响应。
因此，如果客户端提出的密码不被服务器接受（假设服务器管理员已禁用弱密码且客户端只发送弱密码），则服务器将在将证书发送给客户端之前终止连接。
如果密码可以接受，服务器就会将其证书发送给客户端。RFC 5280 第 6 节描述了证书路径验证。但是，它有以下几点说明：
符合本规范的实现不需要实现此算法，但必须提供与此过程产生的外部行为等效的功能。特定实现可以使用任何算法，只要它能得出正确的结果即可。
因此，只要最终结果相同，客户端可以以任何它认为合适的方式验证路径。鉴于有许多操作系统可用，一些操作系统有许多可用于处理证书的库，因此很难对您的问题给出明确的答案。
不幸的是，你的选择可能仅限于：
- 使用上面列表的所有组合来编写脚本证书生成和测试，并针对所有库运行它；
- 如果可用，请阅读源代码。