必须检查证书文件本身的签名算法而非Nginx配置；若openssl命令显示sha1WithRSAEncryption，即存在SHA-1弱签名，需重签证书并验证fullchain.pem中所有证书段均为sha256WithRSAEncryption或更高。
排查 Nginx 证书链中是否含 SHA-1 等弱哈希算法，关键不是看配置文件，而是直接检查证书本身的签名算法。浏览器拦截、漏洞扫描报 ERR_CERT_WEAK_SIGNATURE_ALGORITHM 或 “Certificate signed using weak hashing algorithm”，99% 是证书文件本身用了已被淘汰的 SHA-1 签名，和 Nginx 配置无关——换再强的密码套件也救不了。
快速定位：用命令行确认签名算法
在服务器上运行以下命令，查看你当前部署的证书签名方式：
openssl x509 -in /path/to/your_domain.crt -noout -text | grep "Signature Algorithm"如果输出中出现 sha1WithRSAEncryption，就坐实问题。注意：这不是指私钥或 CSR 的哈希选项，而是 CA 最终签发证书时用的签名算法。哪怕你当年用 -sha256 生成 CSR，CA 若仍用 SHA-1 签发，证书照样被拒。
补充验证方式：
- 用在线工具（如 SSL Labs、SSL Checker）输入域名，查报告中的 “Signature Algorithm” 字段
- 浏览器点击地址栏锁图标 → 查看证书 → 详细信息 → 找 “签名哈希算法”
检查 fullchain.pem 是否混入旧证书
很多人把多个证书拼进 fullchain.pem，却没注意其中某一段是多年前签发的 SHA-1 中间证书。执行：
对每一段证书单独检查签名算法。常见陷阱：
- Let’s Encrypt R3（SHA-256）和已停用的 DST Root CA X3（SHA-1）共存于同一文件
- GoDaddy 或 Comodo 下发的旧 bundle 中包含 SHA-1 中间证书（如 “Go Daddy Secure Certificate Authority - G2”）
- 自建 CA 或内网证书未更新，仍沿用 SHA-1 签发逻辑
修复路径：必须重新获取或重签证书
没有“绕过”或“兼容开关”。现代浏览器和 TLS 栈已硬性禁用 SHA-1 验证，Nginx 无法干预这一层校验。
-
Let’s Encrypt 用户：Certbot 默认使用 SHA-256，但若长期未续期，可能还挂着旧证书。执行
certbot renew --force-renewal并确认新生成的fullchain.pem中所有证书段签名均为sha256WithRSAEncryption - 商业证书用户：登录 CA 后台，重新申请证书，务必勾选 “SHA-256” 或 “RSA-SHA256” 选项；下载时选择 Nginx 格式，不要复用旧 bundle
-
自签名证书：用
openssl req -x509 -sha256 ...重新生成，绝对避免省略-sha256参数
验证是否真正生效
改完证书后 reload Nginx，别信浏览器缓存或小锁图标：
- 再次运行
openssl x509 -in ... -text | grep "Signature Algorithm"，确保所有证书段都显示sha256WithRSAEncryption或更高（如sha384WithRSAEncryption） - 用
openssl s_client -connect your.com:443 -servername your.com -showcerts检查服务端实际下发的证书链，逐段确认签名算法 - 提交到 SSL Labs 测试，确认 “Handshake Simulation” 中 iOS、Android、Chrome 等主流客户端全部显示绿色通过，且无 “Weak Signature” 类警告
