摘要：HTTPS连接开始前，客户端和服务器需要协商协议、验证身份并建立会话密钥。本文以常见的TLS 1.3证书认证完整握手为例，解释ClientHello、服务器证书、CertificateVerify和Finished各自的作用，并说明为什么证书正确不等于连接一定成功。
浏览器访问一个HTTPS网站时，不能只凭服务器说“我是这个网站”就发送账号密码。双方既要确认采用哪套通信规则，也要验证对方的身份和后续消息使用的密钥。TLS握手承担的正是这些工作。
日常所说的“SSL证书”，在现代HTTPS连接中通常用于TLS协议。下面以一次基于证书认证、使用临时密钥交换的TLS 1.3完整握手为例；会话恢复、客户端证书认证以及TLS1.2等情况，消息和流程会有区别。
一 ClientHello先告诉服务器什么
客户端先发送ClientHello，提供自己支持的协议版本、密码套件、签名算法与密钥交换相关参数。在使用SNI的连接中，还会携带要访问的服务器名称，帮助同一入口选择对应的网站配置和证书。
SNI与证书名称验证是两件事。前者帮助服务器选站点，后者由客户端判断拿到的证书是否适用于实际访问名称。即使服务器根据SNI选出了一张证书，客户端仍要检查它是否覆盖当前主机名。
TLS 1.3中，客户端通常还会提供密钥共享参数。若服务器无法使用所给参数，可能要求重新提供，因此不能把所有连接都理解成完全相同的一次往返。
二 服务器选择参数并证明自己的身份
服务器通过ServerHello确定本次连接使用的参数，并提供自己的密钥共享信息。双方据此结合握手上下文派生相应密钥，后续握手中的敏感内容开始获得加密保护。
服务器发送证书链，向客户端提供站点公钥及相关身份信息；随后使用与证书公钥对应的私钥，对规定的握手内容生成CertificateVerify签名，证明自己能使用这把私钥。只复制一份公开证书，而没有相应私钥，无法正常完成这项证明。
这里最容易被混淆的是会话密钥的来源。在本文描述的TLS1.3临时密钥交换中，通信双方通过密钥协商派生会话密钥，服务器证书主要参与身份认证。不能笼统地描述成“浏览器生成一把密码，再用证书公钥加密交给服务器”，那并不适用于这一流程。
三 客户端为什么还要检查证书链
拿到证书后，客户端需要建立到受信任根的验证路径，核对有效期、主机名和用途等条件，并按照自身实现及策略处理证书状态等检查。服务器通常应发送站点证书和需要的中间证书，根信任来自客户端的信任配置，而不是服务器随意附上一张根证书就能建立。
这解释了一个常见现象：一台电脑能打开网站，另一台却提示证书不受信任。两台设备可能拥有不同的信任库、系统时间或网络拦截环境，也可能一台设备曾缓存过缺失的中间证书。排查时要比较实际收到的链和客户端环境，不能只看服务器磁盘中存放了什么文件。
GlobalSign提供的SSL/TLS证书参与这一身份验证过程。企业采购时选择DV、OV或EV，决定的是相应身份核验与证书信息；实际握手能否成功，还取决于私钥、证书链、协议配置和客户端兼容性。
四 Finished确认本次握手没有被改写
在完整握手中，服务器和客户端分别发送Finished消息，使用派生出的密钥校验相关握手记录，使对方能够发现握手内容被篡改等问题。完成相应验证后，双方使用应用数据密钥保护HTTP请求与响应。
| 环节 | 它要解决的问题 | 常见检查方向 |
| 协议与算法协商 | 双方能否使用共同参数 | 客户端版本、服务器TLS配置 |
| 证书与身份验证 | 连接对象是否符合预期 | 名称、有效期、证书链、信任库 |
| 私钥签名证明 | 服务器是否掌握对应私钥 | 证书与私钥配对、签名能力 |
| 握手确认 | 相关握手消息是否一致 | 协议错误、网络中间设备、实现日志 |
表中各项有关联，却不能相互替代。新证书成功签发，只能说明申请阶段完成；如果负载均衡仍绑定旧证书，客户端看到的身份信息不会因此变化。
五 TLS 1.2与双向认证为什么看起来不同
有些抓包教程会把服务器发送证书、密钥交换和ChangeCipherSpec画成固定顺序。这类示意可能针对TLS 1.2中的某一种握手，不能逐条照搬到TLS1.3。排查前应先确认实际协商版本，避免因为日志中没有出现旧教程里的消息名称，就误判连接异常。
还应区分常见的网站单向认证与双向TLS认证。普通浏览器访问网站时，通常是客户端验证服务器证书；在要求客户端证书的业务里，服务器还会要求客户端提供相应证明。此时，网站证书正常也不能代替客户端证书的信任、用途和有效期检查。
例如，内部API要求客户端证书，维护人员只替换了服务器证书，却没有发现调用方证书已到期，那么网页测试与实际接口调用就可能表现不同。问题并不一定在新换的服务器证书上，而在这条连接还有另一项认证条件。
相反，如果应用在TLS连接之后要求账号、令牌或业务授权，那属于后续应用层控制。服务器证书验证成功，不代表调用方已经获得访问业务数据的权限。将这两层身份检查分别记录，有助于开发和运维判断故障归属。
六 看懂握手 对运维有什么实际帮助
遇到连接失败，先区分故障是否发生在建立TCP连接、TLS握手或应用请求阶段。服务根本无法连接，与已经收到证书但名称不匹配，是不同的问题。一次访问得到HTTP500响应，也往往意味着TLS连接已经建立，后面应继续看应用日志。
检查证书时应使用真实访问名称和端口，并确认是否经过CDN、网关或代理。对外终止TLS的位置可能不在源站服务器。若内部链路也使用HTTPS，前端和回源连接还需要各自核对。
维护人员不必记住每一种消息编码，但应知道证书、私钥、会话密钥各自负责什么。这样在更新证书或调整配置时，才不会把身份验证、加密协商与业务响应混在同一项检查里。
FAQ
1 问 每次打开网页都会重新完成一次完整握手吗
答：不一定。已有连接可能被复用，也可能使用会话恢复机制。本文描述的是用于理解身份认证和密钥建立的完整握手示例。
2 问 安装了SSL证书 就能支持所有旧设备吗
答：不能据此保证。协议版本、签名算法、证书链以及旧设备的信任库都可能影响兼容性，应根据实际客户端范围测试。
3 问 OV或EV证书 会让TLS握手的加密强度自动提高吗
答：不会自动提高。在算法、密钥参数和协议配置相同的条件下，验证等级不直接改变会话加密强度。选型还应考虑业务对组织身份信息的要求。
资料来源
IETF RFC 8446：TLS1.3协议
https://www.rfc-editor.org/rfc/rfc8446.html
GlobalSign中国官网：SSL/TLS证书
https://www.globalsign.cn/shop/ssl