微信小程序“证书不受信任”主因是证书链不完整、TLS版本过低或Nginx代理配置不当：需确保服务端TLS握手时一次性发送域名证书+所有中间证书（不含根证书），Nginx ssl_certificate指向fullchain.pem，启用TLSv1.2+并禁用旧协议，且系统信任链可回溯。
小程序提示“证书不受信任”，不是浏览器能打开就没事——微信客户端校验更严，问题往往藏在证书链、TLS 协议或 Nginx 代理配置里。重点不是证书有没有，而是它是否以微信能接受的方式完整、合规地送达。
检查证书链是否真正完整送达
安卓和微信小程序要求服务端在 TLS 握手时一次性发送“域名证书 + 所有中间证书”，不能只发终端证书，也不能含根证书。
- 在 Nginx 服务器上执行：
openssl s_client -connect your-domain.com:443 -servername your-domain.com -showcerts 2>/dev/null - 观察输出中
BEGIN CERTIFICATE块的数量和顺序：
第一块必须是你的域名证书（Subject=CN=your-domain.com）；
第二块起应为中间证书（如 Let’s Encrypt R3），其Issuer要匹配上一块的Subject；
最后一块绝不能是根证书（如 ISRG Root X1） - 如果只看到 1 块，说明 Nginx 没加载中间证书；确认
ssl_certificate指向的是fullchain.pem（域名证书 + 中间证书拼接），不是cert.pem
确认 TLS 版本和加密套件兼容微信客户端
微信强制要求 TLS 1.2 或更高版本，禁用 TLS 1.0/1.1；老旧 OpenSSL 或默认 Nginx 配置可能不满足。
- 检查 Nginx 配置中是否明确启用了安全协议：
ssl_protocols TLSv1.2 TLSv1.3;（务必移除TLSv1和TLSv1.1） - 验证服务端是否响应 TLS 1.2：
openssl s_client -connect your-domain.com:443 -tls1_2 -servername your-domain.com /null 2>&1 | grep "Protocol"，输出应为Protocol : TLSv1.2 - 避免使用已淘汰的加密套件，推荐搭配：
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
排查 Nginx 反向代理场景下的后端证书信任问题
如果你的 Nginx 是 HTTPS 终结 + 代理到另一个 HTTPS 后端（比如内部 API），那它会以“客户端”身份校验后端证书——这和小程序无关，但会导致 502 或静默失败。
- 确保启用并正确配置了以下指令（必须写在
location或upstream块内）：proxy_ssl_verify on;<br>proxy_ssl_trusted_certificate /etc/nginx/ssl/upstream-ca.crt;<br>proxy_ssl_server_name on;<br>proxy_ssl_name "api.internal.com";
-
proxy_ssl_name必须与后端证书的 SAN 完全一致（大小写、通配符、www 前缀都不能错） -
upstream-ca.crt文件只能含 PEM 格式的可信 CA 证书（根 + 中间），不能混入私钥、域名证书或重复项；权限设为 644
验证系统级信任链是否可回溯
即使链看起来完整，若中间 CA 不被操作系统信任，微信仍可能拒绝连接（尤其内网 CA 场景）。
- 运行命令验证整条链能否被系统信任：
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt /path/to/fullchain.pem - 返回
OK表示链可回溯到系统可信根；若报unable to get issuer certificate，说明中间证书缺失、顺序错误，或系统 CA 包未更新（可执行update-ca-certificates） - 对 Let’s Encrypt 证书，建议直接使用系统默认 CA 包，而非手动指定 ISRG 根证书
