某网站已经部署了HTTPS的ssl证书，但是需要对Cipher协议进行调整。
先通过chrome浏览器 - ctrl+shift+J - privacy and security 查看SSL证书连接详情，比如：
Connection:
Certificate
系统是CentOS 7.9，查看nginx版本nginx -V，返回：
nginx -V nginx version: nginx/1.18.0 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) built with OpenSSL 1.1.1g 21 Apr 2020 TLS SNI support enabled
openssl版本：
openssl version OpenSSL 1.0.2k-fips 26 Jan 2017
因为指定 cipher 协议，TLSv1.3 控制命令是 ssl_conf_command，而ssl_conf_command需要nginx版本高于1.19.4，需先升级nginx。
执行：./upgrade.sh nginx 按提示输入版本号后回车（访问 http://nginx.org/en/download.html 可查找nginx的最新版本号和以往旧版本号 ），再次回车确认即可开始升级Nginx。Nginx升级为平滑升级，升级过程不影响nginx的运行。
./upgrade.sh nginx
https://nginx.org/en/download.html 查看选择nginx-1.24.0 （选择高于 1.18.0 最近的一个版本，防止版本跨度过大！）
升级好：
nginx -V nginx version: nginx/1.24.0 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) built with OpenSSL 1.1.1g 21 Apr 2020 TLS SNI support enabled
因为服务器上有多个vhost解析，我们需要调整默认的server块，加上 default_server，防止HTTPS和客户端握手时采取其他的server块配置：
server
{
# 加上 default_server，确保它是 443 端口的基准
listen 443 ssl http2 default_server;
...
}需要将 cipher 从 AES_256_GCM 调为 AES_128_GCM，server块增加：
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers on; # TLSv1.3 控制命令 ssl_conf_command ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256; # 针对 TLS 1.2 的套件顺序（也建议将 128 放在前面以适配你的代理环境） ssl_ciphers "TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:!MD5:!aNULL";
重启nginx，或者重新加载reload均可。
如果你的本地电脑（或另一台 Linux 服务器）的 curl 版本较新（7.52.0+），可以直接通过命令行查看：
curl -I -v --tlsv1.3 https://x360.net 2>&1 | grep "SSL connection using"
输出示例：SSL connection using TLS_AES_128_GCM_SHA256。
如果输出包含 TLS_AES_128_GCM_SHA256，说明生效；如果依然是 TLS_AES_256_GCM_SHA384，则说明优先级未调换成功。
此时再查看：
Connection
如果需要调整issuer为ECC格式：
强制签发 ECC 证书
执行以下命令（请根据你的实际路径调整 acme.sh 的位置）：
# 强制指定密钥长度为 ec-256 /usr/local/acme.sh/acme.sh --issue -d x360.net --keylength ec-256 --webroot /home/wwwroot/x360.net/public
返回：
[Sat Mar 7 19:39:04 CST 2026] Using CA: https://acme.zerossl.com/v2/DV90 [Sat Mar 7 19:39:04 CST 2026] Creating domain key [Sat Mar 7 19:39:04 CST 2026] The domain key is here: /usr/local/nginx/conf/ssl/x360.net_ecc/xi360.net.key [Sat Mar 7 19:39:04 CST 2026] Single domain='x360.net' [Sat Mar 7 19:39:15 CST 2026] Getting webroot for domain='x360.net' [Sat Mar 7 19:39:15 CST 2026] Verifying: x360.net [Sat Mar 7 19:39:21 CST 2026] Processing. The CA is processing your order, please wait. (1/30) [Sat Mar 7 19:39:27 CST 2026] Success [Sat Mar 7 19:39:27 CST 2026] Verification finished, beginning signing. [Sat Mar 7 19:39:27 CST 2026] Let's finalize the order. [Sat Mar 7 19:39:27 CST 2026] Le_OrderFinalize='https://acme.zerossl.com/v2/DV90/order/aw8MkOLms8P9/finalize' [Sat Mar 7 19:39:31 CST 2026] Order status is 'processing', let's sleep and retry. [Sat Mar 7 19:39:31 CST 2026] Sleeping for 15 seconds then retrying [Sat Mar 7 19:39:47 CST 2026] Polling order status: https://acme.zerossl.com/v2/DV90/order/aw8MkOLms8P [Sat Mar 7 19:39:48 CST 2026] Downloading cert. [Sat Mar 7 19:39:48 CST 2026] Le_LinkCert='https://acme.zerossl.com/v2/DV90/cert/FNQ1xYugNE' [Sat Mar 7 19:39:52 CST 2026] Cert success. [Sat Mar 7 19:39:52 CST 2026] Your cert is in: /usr/local/nginx/conf/ssl/x360.net_ecc/x360.net.cer [Sat Mar 7 19:39:52 CST 2026] Your cert key is in: /usr/local/nginx/conf/ssl/x360.net_ecc/x360.net.key [Sat Mar 7 19:39:52 CST 2026] The intermediate CA cert is in: /usr/local/nginx/conf/ssl/x360.net_ecc/ca.cer [Sat Mar 7 19:39:52 CST 2026] And the full-chain cert is in: /usr/local/nginx/conf/ssl/x360.net_ecc/fullchain.cer
注意，ECC证书生成的目录是类似 x360.net_ecc 格式，可以删除 _ecc ，然后同步调整vhost里证书目录即可：
ssl_certificate /usr/local/nginx/conf/ssl/x360.net/fullchain.cer; ssl_certificate_key /usr/local/nginx/conf/ssl/x360.net/x360.net.key; ssl_session_timeout 5m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers on; # TLSv1.3 控制命令 ssl_conf_command ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256; # 针对 TLS 1.2 的套件顺序（也建议将 128 放在前面以适配你的代理环境） ssl_ciphers "TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:!MD5:!aNULL"; ssl_session_cache builtin:1000 shared:SSL:10m; ssl_dhparam /usr/local/nginx/conf/ssl/dhparam.pem;
附注：
| 特性 | ZeroSSL RSA CA | ZeroSSL ECC CA |
| 全称 | Rivest-Shamir-Adleman | Elliptic Curve Cryptography |
| 密钥长度 | 通常为 2048 位或 4096 位 | 通常为 256 位或 384 位 |
| 计算效率 | 较低（加密/解密速度较慢） | 极高（更快的握手速度） |
| 资源消耗 | 较高（占用更多 CPU 和内存） | 极低（对移动设备更友好） |
| 带宽占用 | 证书文件较大 | 证书文件更小 |
虽然 ECC 的密钥长度比 RSA 短得多，但其安全强度反而更高。
256 位的 ECC 密钥提供的安全性相当于 3072 位的 RSA 密钥。
随着计算能力的提升，RSA 需要不断增加位数（如从 2048 增加到 4096）来维持安全性，而 ECC 只需微调即可达到极高的抗攻击能力。
这是选择时最需要权衡的一点：
RSA (Domain Secure Site CA): 具有近乎完美的兼容性。无论是十年前的老旧浏览器、早期的安卓系统，还是各种 IoT 设备，几乎都支持 RSA。
ECC (Domain Secure Site CA): 虽然现代浏览器（Chrome, Edge, Safari, Firefox）和操作系统（iOS, Android）都已经全面支持，但在一些极老旧的平台（如 Windows XP 上的 IE、部分非常老的 Java 客户端）上可能会出现握手失败。
选择 ECC 的场景：
追求极致性能： 如果你的网站流量很大，ECC 能显著降低服务器在高并发下的 CPU 负载，并加快首屏加载速度（TTFB）。
移动端优先： 适合 App、小程序后端，因为小密钥对移动设备的电池和性能损耗更小。
选择 RSA 的场景：
追求最大兼容： 如果你的用户群可能使用老旧系统，或者你需要确保在所有复杂的网络环境下（包括一些老旧的防火墙或网关）都能正常访问。
默认推荐： 如果你无法确定用户的设备环境，RSA 是最保险的“万金油”选择。
总结：ECC 是未来，它更小、更快、更安全；而 RSA 是现状，它胜在稳定和无处不在的兼容性。目前大多数高性能站点（如 Cloudflare、Google）会优先尝试使用 ECC 证书。