Android HttpsURLConnection禁用后端部分Cipher后出现SSLHandshakeException

针对你遇到的Azure App Service（Linux）与Android API 28应用SSL握手失败问题——即便两端存在共同Cipher套件，仍抛出javax.net.ssl.SSLHandshakeException: connection closed，核心可能原因及排查方向如下：

1. 证书密钥算法与Cipher套件不匹配 #

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384套件要求后端服务器使用ECDSA类型的SSL证书，但Azure App Service默认配置的是RSA证书。如果你的后端仍使用RSA证书，即便该套件被列入支持列表，实际握手时也无法匹配——套件名称中的ECDSA指的是证书的密钥算法，而非加密组件的算法。

验证方法：

• 查看Azure App Service的SSL证书类型，确认是否为ECDSA；
• 执行openssl s_client -connect <你的域名>:443 -cipher ECDHE-ECDSA-AES256-GCM-SHA384命令测试，若返回no peer certificate available或握手失败，即可确认证书类型不兼容。

解决方法：

• 更换为ECDSA证书部署到Azure App Service；
• 若无法更换证书，将后端Cipher套件替换为RSA兼容版本（如TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384）。

2. Azure App Service的Cipher套件配置未实际生效 #

修改Cipher套件后，可能因以下情况导致配置未生效：

• 未重启应用服务实例，配置未加载；
• 套件名称拼写错误（Azure要求使用OpenSSL格式名称，例如ECDHE-ECDSA-AES256-GCM-SHA384，而非Java格式的TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384）；
• TLS版本限制：若后端仅启用TLS 1.3，而Android API 28默认未启用TLS 1.3（需手动配置SSLSocketFactory开启），但目标套件属于TLS 1.2，需确认后端是否开启了TLS 1.2。

验证方法：

• 执行openssl s_client -connect <你的域名>:443查看服务器实际返回的Cipher套件列表；
• 检查Azure App Service的TLS设置，确认TLS 1.2处于启用状态。

3. Android端实际可用套件与打印结果存在差异 #

虽然代码打印了SSLSocketFactory支持的套件，但存在以下限制可能导致实际无法使用目标套件：

• 设备硬件限制：部分低端Android 9（API 28）设备可能缺少AES 256硬件加速支持，系统会自动禁用该套件；
• 应用网络安全配置限制：若res/xml/network_security_config.xml中设置了allowedCipherSuites，可能未包含目标套件；
• 定制ROM限制：部分厂商定制系统可能禁用了某些Cipher套件。

验证方法：

• 在出现问题的设备上，通过抓包工具捕获SSL握手过程，查看客户端实际发送的Cipher套件列表；
• 检查应用的网络安全配置文件，确认未限制目标套件。

4. 服务器在套件不匹配时直接关闭连接 #

若后端仅保留两个Cipher套件，其中第一个套件客户端不支持，部分服务器（如Azure App Service底层的nginx）可能在第一次套件不匹配后直接关闭连接，而非继续遍历剩余套件。即便第二个套件兼容，也无法完成握手。

验证方法：

• 将兼容的套件调整为后端Cipher列表的第一位，再测试连接是否正常；
• 用openssl s_client指定目标套件测试，确认单个套件是否能正常握手。

内容的提问来源于stack exchange，提问作者Mathias Rönnlund