自签名证书是什么？
自签名证书是网站管理员或开发人员自行生成、不经过任何受信任证书颁发机构（CA）签发的SSL/TLS证书。它具备完整的公钥基础设施（PKI）结构，包含私钥、公钥、有效期和主题信息，但其根证书未被操作系统或浏览器预置信任库收录，因此在真实用户访问时会触发“您的连接不是私密连接”等安全警告。
这类证书无法满足HTTPS加密的“信任链验证”要求——浏览器无法追溯到一个已知可信的根CA。它本质上是一个闭环验证体系：仅对签发者自身有效，不具备跨设备、跨用户、跨平台的浏览器信任能力。
技术机制：为什么浏览器不信任？
现代浏览器（Chrome、Firefox、Safari、Edge）内置了约100个全球主流CA的根证书，如Sectigo、Digicert、Geotrust、锐安信等。当客户端发起TLS握手时，会逐级向上验证证书链，直至抵达一个预装的根证书。而自签名证书的签发者就是自己，链路在此中断，验证失败，直接标记为不受信任。
即使使用OpenSSL命令行生成2048位RSA密钥+SHA256签名，也无法绕过该信任锚点缺失问题。这不是加密强度问题，而是PKI信任模型的根本限制。
适用场景与工程实践限制
自签名证书仅适用于严格可控的封闭环境：内部测试服务器、CI/CD流水线中的服务间通信、Kubernetes集群内Service Mesh mTLS、或开发阶段的本地HTTPS调试（配合手动导入根证书到系统钥匙串）。我们曾在线上灰度环境中部署过自签名证书用于API网关健康检查探针，但必须同步配置所有节点的信任库，运维成本极高。
⚠️ 真实生产网站、面向公众的Web服务、小程序后端、微信公众号回调地址等场景严禁使用。Google自2017年起已将HTTP标记为“不安全”，而自签名HTTPS在Chrome中显示的警告级别更高，用户流失率超68%（2025年TopSSL客户数据抽样）。
与免费SSL证书的本质区别
很多人误以为Let’s Encrypt或免费SSL证书也是“自签名”，这是严重误解。Let’s Encrypt是经Mozilla、Apple、Microsoft联合信任的公开CA，其根证书ISRG Root X1已预置在全球99.9%终端设备中。它通过ACME协议自动完成域名控制验证（DCV），生成的是完整可验证的证书链，属于标准的DV SSL证书。
而自签名证书连最基本的域名验证都不存在，更无OCSP响应、CRL吊销支持，也不符合CA/B Forum Baseline Requirements第9.2条关于证书透明度（CT Log）的强制要求。
| 对比项 | 自签名证书 | 免费DV SSL证书（如Let’s Encrypt） |
|---|---|---|
| 浏览器信任 | ❌ 默认全部拦截，需手动导入 | ✅ 全平台原生信任 |
| 域名验证 | ❌ 无验证环节 | ✅ DNS / HTTP / TLS-ALPN 自动验证 |
| 证书链完整性 | ❌ 单证书，无中间件 | ✅ 完整三级链（叶证书→中间CA→根CA） |
| 合规性 | ❌ 不符合CA/B Forum、等保2.0 | ✅ 满足基线要求与国内监管规范 |
常见问题
Q：自签名证书能用于微信小程序后台吗？
A：不能。微信校验服务器证书时强制要求由可信CA签发，自签名会返回request:fail ssl hand shake error，导致消息推送、支付回调全部失败。
Q：能否把自签名证书加入安卓手机信任库？
A：Android 7.0+默认禁用用户添加的CA证书用于HTTPS验证；即使开启，也仅对特定App生效（需代码层显式启用Network Security Config），且无法覆盖WebView及系统级访问。
Q：有没有办法让自签名证书被浏览器“假装信任”？
A：开发阶段可通过Chrome启动参数--unsafely-treat-insecure-origin-as-secure临时绕过，但该方式仅限localhost，且2026年起已被Chrome 128+彻底移除，不可用于任何线上场景。
京公网安备11010502031690号
网站经营企业工商营业执照
