握手失败 (Handshake Failed)怎么办

握手失败的典型工程归因

TLS 握手失败不是单一错误，而是客户端与服务端在密钥交换、身份认证或协议协商任一环节中断后触发的通用错误提示。常见归因包括：服务端未启用客户端所支持的 TLS 版本（如 Android 7.0+ 默认禁用 TLS 1.0）、证书链不完整导致验证失败、SNI 扩展未正确发送或服务端拒绝响应、ECDSA 证书在旧版 Android（如 4.4）上缺乏对应签名算法支持。这些均属协议实现层面的兼容性断点，而非网络连通性问题。

主题锚点句：本文仅讨论由 TLS 协议栈实现差异、证书配置缺陷或系统级加密策略变更引发的握手失败，不覆盖 DNS 解析失败、TCP 连接超时等传输层问题。

Android 系统对 TLS 的约束随版本演进显著增强。例如 Android 10（API 29）起默认启用 TLS 1.3，同时废弃对不安全重协商（RFC 5746）的支持；Android 12 引入 Certificate Transparency（CT）日志验证强制策略，若服务端证书未嵌入有效 SCT（Signed Certificate Timestamp），部分 WebView 实例将直接终止握手。此类行为变更并非 Bug，而是平台级安全基线升级，需通过实际设备抓包（如使用 adb shell setprop log.tag.ssldebug VERBOSE 配合 OkHttp 日志）定位具体失败阶段。

服务端证书配置的合规性检查项

证书链必须完整且顺序正确：根证书不可包含在服务端发送的证书列表中，中间证书须按“叶证书→中间证书”顺序排列，否则 Android 4.1–5.0 的 Conscrypt 实现会因无法构建信任路径而静默失败。自签名证书或私有 CA 颁发的证书，必须显式预置到应用的 network_security_config.xml 中，Android 7.0+ 不再信任用户安装的 CA 证书（除非应用明确声明 android:usesCleartextTraffic="true" 并配置 <trust-anchors>）。

OCSP Stapling 与 CRL 分发点配置虽非强制，但在高合规要求场景下影响显著。Android 11+ 的 TrustManagerImpl 对 OCSP 响应的 nextUpdate 字段执行严格校验，若该时间戳早于当前系统时间，即使证书本身未过期，握手也会被拒绝。同理，若证书的 CDP（CRL Distribution Points）指向不可达地址，且无备用 OCSP 响应，部分定制 ROM（如 Samsung One UI 4.x）会在证书验证阶段阻塞并返回 SSLHandshakeException。

客户端侧可验证的调试路径

在 Android 应用中，优先启用 OkHttp 的连接日志（EventListener + ConnectionSpec 调试输出）或使用 openssl s_client -connect example.com:443 -tls1_2 -servername example.com 在模拟环境中复现。关键观察点包括：ClientHello 是否携带预期的 supported_groups（如 x25519）、服务端是否返回 ServerHello 及其选定的 cipher suite、是否出现 CertificateRequest 后无响应（表明双向认证配置错配）。这些信息可精确区分是服务端策略拦截，还是客户端能力缺失。

对于 WebView 场景，需注意 WebViewClient.onReceivedHttpError() 不捕获 TLS 层错误，必须监听 WebViewClient.onReceivedError() 并检查 errorCode == ERROR_FAILED_SSL_HANDSHAKE。自 Android 8.0 起，WebView 使用独立的 Chromium 网络栈，其 TLS 行为与系统 HttpsURLConnection 存在差异——例如对 TLS 1.3 的 Early Data 支持、对 Ed25519 公钥的解析能力均不同步。因此不能假设同一证书在 OkHttp 和 WebView 中表现一致。

FAQ

Q：Android 5.1 设备访问 HTTPS 接口报 handshake failed，但 Chrome 浏览器能打开，为什么？
A：Chrome 使用自带的 BoringSSL 实现，支持 TLS 1.2 及更丰富的密码套件（如 ECDHE-ECDSA-AES128-GCM-SHA256），而系统 HttpsURLConnection 在 Android 5.1 依赖 OpenSSL 1.0.1e，不支持 SHA256withECDSA 签名算法。服务端若仅配置 ECDSA 证书且未提供 RSA 回退选项，系统级调用即失败。

Q：证书由 Let’s Encrypt 签发，为何在部分华为 EMUI 设备上握手失败？
A：EMUI 9.1–10.0 的 TrustManager 对 Let’s Encrypt 新根证书 ISRG Root X1 的交叉签名链处理存在缺陷，当服务端未发送完整的 R3 → X1 中间链时，设备无法完成路径构建。解决方案是确保 Nginx/Apache 配置中 ssl_certificate 指向包含 R3.crt 与 X1.crt 的合并文件。

Q：启用 TLS 1.3 后握手失败率上升，是否应降级到 TLS 1.2？
A：不应简单降级。TLS 1.3 失败多源于服务端未正确实现 0-RTT 或 Key Share 扩展协商逻辑。建议先确认服务端使用的 OpenSSL 版本 ≥ 1.1.1k，并禁用实验性特性（如 SSL_OP_ENABLE_KTLS），再通过 Wireshark 过滤 tls.handshake.type == 1（ClientHello）与 == 2（ServerHello）比对协商结果。