Chrome 124 beta版WebRTC连接失败音频失效，求故障原因

故障背景 #

我们开发的基于WebRTC的音频应用在Chrome 124 Beta版本中出现功能失效，旧版Chromium及所有Firefox版本运行正常。通过Wireshark仅捕获到一条握手相关错误包，无法定位明确原因；开启WebRTC扩展日志（启动参数--enable-logging --vmodule=*/webrtc/*=1）后，得到如下关键错误信息：

[18496:21896:0403/131717.236:WARNING:openssl_adapter.cc(820)] write_alert fatal handshake failure TLS client send_client_certificate
[18496:21896:0403/131717.236:INFO:openssl_adapter.cc(817)] connect_exit TLS client send_client_certificate
[18496:21896:0403/131717.236:WARNING:openssl_stream_adapter.cc(949)] OpenSSLStreamAdapter::Error(ContinueSSL, 1, 0)
[18496:21896:0403/131717.236:INFO:dtls_transport.cc(756)] DtlsTransport[0|1|*]: DTLS transport error, code=1
[18496:21896:0403/131717.236:VERBOSE1:dtls_transport.cc(863)] DtlsTransport[0|1|*]: set_dtls_state from:1 to 4

日志显示RTCPeerConnection的onconnectionstatechange回调进入失败状态。

故障定位 #

从日志核心信息write_alert fatal handshake failure TLS client send_client_certificate可以确定，故障根源是DTLS握手过程中客户端发送证书环节出现致命错误，导致DTLS传输直接进入失败状态，进而引发WebRTC音频功能失效。

可能的诱因 #

尽管Chrome 124公开变更日志未提及相关内容，但结合版本迭代特性，大概率是Chrome 124 Beta对WebRTC的DTLS客户端证书处理逻辑做了未公开的调整，常见可能性包括：

• 对客户端证书链的验证规则更严格：比如要求证书必须包含subjectAltName扩展、禁止使用过期的签名算法（如SHA-1）、对证书颁发机构的信任链检查更苛刻
• DTLS握手流程中证书发送的时机或格式要求变更：旧版Chrome允许的证书发送逻辑在新版本中不再兼容
• 客户端证书的加密算法支持范围缩小：比如废弃了某些老旧的非对称加密算法（如RSA 1024），而应用使用的证书依赖这些算法

验证与修复方向 #

1. 检查客户端证书有效性：确认证书未过期、证书链完整、包含合法的subjectAltName字段、签名算法符合现代TLS标准（推荐使用SHA-256及以上、ECDSA算法）
2. 对比版本差异：查看Chromium源码仓库中Chrome 123到124之间WebRTC DTLS模块（尤其是openssl_adapter.cc、dtls_transport.cc）的提交记录，定位具体变更点
3. 测试兼容调整：尝试更换为符合最新TLS规范的客户端证书，或调整WebRTC连接配置中与DTLS证书相关的参数，验证是否恢复正常

内容的提问来源于stack exchange，提问作者Aleksander Ciurej