我一直在学习 TLS 协议握手过程。据我所知，TLS 版本完全由客户端操作系统\浏览器支持决定。所选的密码套件由服务器决定（基于客户端可用的套件）
我正在尝试了解证书对协议的哪一部分有影响。我记得 Chrome 警告过我有关 sha1 证书的问题，并强迫我在服务器上续订证书（本质上是强迫我升级我的组织 CA 服务器）
答案1
据我了解，TLS 版本完全由客户端的操作系统\浏览器支持决定。
大部分情况下确实如此。客户端可能会从更强大的选项开始，如果该选项与服务器提供的协议不匹配，则重试旧协议。
所选的密码套件由服务器决定（基于客户端可用的套件）
不完全是。密码套件由服务器和客户端商定。服务器提供一个或多个它支持的密码套件，这些密码套件可能按强度降序排列，也可能不按强度降序排列，客户端将使用其选择使用的密码套件进行响应；
我试图了解证书对协议的哪部分有影响。
证书用于（相互）身份验证和密钥交换。使用证书，您可以验证特定服务器是否是其声称的服务器（因为该 PKI 顶部有一个相互信任的 CA），并且使用证书，您可以使用客户端证书作为身份验证因素。使用证书上的密钥对的非对称加密也用于协商对称密钥，以便从那时起加密通信。这种方法有很多细微差别和变化，它非常复杂和复杂，但简而言之，这就是证书所实现的功能。
我记得 Chrome 曾警告我有关 sha1 证书的问题，并强迫我在我的服务器上更新证书（本质上是强迫我升级我的组织 CA 服务器）
这与用于签署所提供证书的算法有关。SHA1 已被证明很容易发生冲突，因此已被弃用为证书签名的安全方法。
答案2
约定密码的主要贡献者是：
关键算法
这类型证书中的密钥可能会对您的 TLS 密码产生影响。
您将看到许多带有 RSA 密钥的证书。因此，双方同意的密码套件只能包含与 RSA 密钥配合使用的密码。例如，此站点使用 RSA 密钥，OpenSSL 显示的密码为：（ECDHE-RSA-AES128-GCM-SHA256请注意 RSA）。
但是，其他网站不使用 RSA 密钥，因此上述密码不会被允许/同意。说实话，我费了好大劲才找到一个例子；但肯定有一个例子在某个地方！
以下内容将对设置 TLS 会话产生影响。它不会影响约定的密码，但会导致更二进制的成功/失败。
签名算法
这不会限制密码的选择，但最近 SHA1 的弃用意味着客户端（尤其是浏览器）将拒绝使用 SHA1 签名的证书（自签名证书除外）。
密钥使用扩展
证书可能（并且通常确实）包含限制密钥使用的扩展。该列表定义在RFC 5280 第 4.1.2.3 节并允许在高级别上实现目的，例如等digitalSignature。keyEncipherment如果证书在此处包含不正确的值，客户端应拒绝该证书。例如，CA 证书应仅具有keyCertSign和crlSign，因此不应用于设置 TLS 会话（例如 HTTPS）。
扩展密钥使用扩展
这与上一个扩展类似，但更细粒度。此列表定义在RFC 5280 第 5.2.1.12 节。例如，两个常见的 EKU 是id-kp-serverAuth和id-kp-clientAuth。两者都允许使用密钥对实体进行身份验证，但它们的方向不同。服务器证书应该具有前者，而客户端证书（可能在 TPM 或智能卡等中）应该具有后者。符合要求的软件应该拒绝没有正确 EKU 的证书。