Appearance
LiteSSL 移除 Key Encipherment：影响与处理方法
更换 LiteSSL RSA 证书后，如果服务器或客户端仍依赖传统 RSA 密钥交换，可能出现 TLS 连接失败。 优先评估使用 ECDSA 证书；需要保留 RSA 证书时，启用 ECDHE_RSA 并移除传统 RSA 密钥交换套件。
已经使用兼容的 TLS 1.3 或 TLS 1.2 ECDHE_RSA 握手的环境，不会仅因移除 Key Encipherment 而需要改用其他证书算法。
为什么调整密钥用途？
LiteSSL 引导证书使用向自动化、更安全的方向发展，推动生态具备加密敏捷性：当算法、证书或安全要求变化时，能够及时完成申请、替换、部署和验证，减少对旧机制的长期依赖。
在这一方向下，LiteSSL 的 RSA 证书仅保留 Digital Signature（数字签名），移除 Key Encipherment（密钥加密），不再支持不具备前向保密能力的传统 RSA 密钥交换。建议优先选择 ECDSA 算法证书；需要继续使用 RSA 证书的环境，则调整密码套件，采用 ECDHE 并移除传统 RSA 密钥交换。
前向保密保护的是过去的通信，具体原理及 MySSL 图解见什么是前向保密（正向加密）？如何用 MySSL 检测？。移除 Key Encipherment 是证书用途限制；服务器仍需检查并调整自己的套件配置，它不会因换证而自动清理旧配置。
如何确认是否受影响？
- 检查实际使用的叶子证书：在证书详情的“密钥用法（Key Usage）”中，确认是否只有 Digital Signature、不含 Key Encipherment。不要与“增强型密钥用法（EKU）”混淆，也不要只检查本地下载文件。
- 检查 HTTPS 入口：确认对外服务由 IIS、Nginx、Apache、Tomcat，还是 CDN、WAF、负载均衡提供，并核对它实际加载的证书与密码套件。
- 检查双方共同支持的套件：仅开启 TLS 1.2 不够，RSA 证书场景需确认能协商 ECDHE_RSA；只支持传统 TLS_RSA_* 的旧客户端也需要升级。
- 区分其他换证问题：同时检查证书链、域名、有效期及私钥匹配情况。一般握手失败提示不能单独证明是 Key Usage 引起的。
| 检查结果 | 处理方向 |
|---|---|
| 新证书不含 Key Encipherment，双方只能使用 TLS_RSA_* | 优先按下文更换为双方支持的 ECDSA 方案，或启用共同支持的 ECDHE_RSA；客户端能力不足时先升级。 |
| 浏览器正常，部分旧程序或设备失败 | 检查失败客户端的 TLS 库、版本和套件，也要检查其信任库；浏览器成功不能替代客户端验证。 |
| 能协商 ECDHE，但报告证书链不受信任 | 检查新证书匹配的中间链与客户端信任库，参阅浏览器正常但客户端 TLS 失败的排查指南。 |
| 对外仍返回旧证书 | 检查证书绑定、服务加载和多节点更新，参阅证书已经更新，为什么访问仍显示旧证书？。 |
传统 RSA 密钥交换要求证书允许 Key Encipherment；ECDHE_RSA 使用 RSA 做数字签名，因此可以使用仅保留 Digital Signature 的 RSA 证书。TLS 1.2 标准 §7.4.2
如何调整证书和服务器？
优先：申请 ECDSA 算法证书
在服务器及目标客户端支持的前提下，优先通过 CertCloud 申请 ECDSA（ECC）证书。使用 CSR 申请时，需要生成对应的 EC 密钥和 CSR，不能继续使用 RSA CSR；具体产品是否支持该算法，可由交付或技术支持确认。
部署新证书、匹配私钥及完整中间链后，启用 TLS 1.3，并为 TLS 1.2 配置 ECDHE_ECDSA 套件。在真实浏览器、App、Java 程序及设备上测试，确认兼容后再切换业务。
如果使用 RSA/ECDSA 双证书部署，还要检查 RSA 分支，避免该分支继续允许传统 RSA 密钥交换。ECDSA 也不是仅支持传统 RSA 的旧客户端的通用兼容方案。
其次：保留 RSA 证书，调整密码套件
需要继续使用 RSA 证书时，为 TLS 1.2 启用 ECDHE_RSA 套件，并移除 TLS_RSA_* 套件；支持 TLS 1.3 的环境同时启用 TLS 1.3。
仅把 ECDHE 排到优先位置，还不等于禁用传统 RSA。 只要服务端仍允许旧套件，部分客户端就可能协商到它。仅支持传统 RSA 密钥交换的客户端需要升级，不能靠新证书或套件排序获得 ECDHE 能力。
先确认 HTTPS 实际终止在 IIS、Nginx、Apache、Tomcat，还是 CDN、WAF、负载均衡上，再修改对应入口。调整前备份配置，在测试环境确认共同支持的套件，生效后检查全部业务入口。
暂时无法调整：选择包含 Key Encipherment 的 TrustAsia 品牌系列证书
如果您的服务器暂时无法停用传统 RSA 密钥交换方式，或无法使用 ECDSA 算法证书，可选择密钥用法中包含 Key Encipherment（密钥加密） 的 TrustAsia 品牌系列 RSA 证书。
请通过 CertCloud 或联系交付、技术支持确认具体产品的密钥用途，签发后检查证书是否包含 Key Encipherment，并在目标服务器和客户端上验证。若只是无法使用 ECDSA，但能够使用 ECDHE_RSA，仍可采用上一节的方案。
这一方案用于兼容暂时无法升级的环境；传统 RSA 密钥交换仍不具备前向保密能力，后续应继续安排升级和套件调整。
调整后如何复测？
采用 ECDSA 或 ECDHE_RSA 方案后，通过 MySSL.com 检查实际业务域名的“协议与套件”，确认需要保留的 ECDHE 套件可用，且不再列出传统 TLS_RSA_*。具体查看 FS 标记和“正向加密：YES”的方法见MySSL 检测图解。
采用 TrustAsia 兼容方案时，重点确认线上新证书包含 Key Encipherment，原先失败的客户端能够正常连接且证书验证通过；仍保留传统 RSA 套件不代表已完成前向保密整改。
随后使用原先失败的客户端重新连接，记录协商协议、套件及证书验证结果。CDN、多节点、不同端口要分别核对。若仍失败，请向技术支持提供域名和端口、发生时间、服务器与客户端版本、完整错误提示及公开证书链；请勿发送私钥或密码。
换证前的检查清单
- 已优先评估 ECDSA 证书，并完成目标客户端兼容性测试。
- 保留 RSA 证书时，已采用
ECDHE_RSA并移除传统TLS_RSA_*；暂时无法调整的环境，已确认使用包含 Key Encipherment 的 TrustAsia 证书并完成兼容性测试。 - 新证书及其匹配中间链已部署到实际 HTTPS 入口。
- MySSL 复测已检查完整套件列表，业务客户端也已复测通过。
- 自动续期流程能够同步更新证书链、加载新证书并验证部署结果，避免只完成签发而未完成上线。
自动化降低重复换证的操作负担，前向保密减少长期私钥泄露对历史通信的影响，加密敏捷性则让后续算法和证书调整更容易实施。三者需要共同落实到申请、部署和验证流程中。