自签名与CA签发证书对比

简单来说，核心区别在于“谁来证明你的身份”以及“信任的起点” 。

以下是详细的对比分析：

1. 核心定义

• 自签名证书：

  • 谁签发：  自己（持有者自己就是签发者）。
  • 过程：  自己生成公钥/私钥对，然后用自己的私钥给自己的公钥签名。
  • 应用：  通常是根CA证书，或者仅用于内部测试环境的服务器证书。

• CSR 方法生成的证书（CA 签发证书）：

  • 谁签发：  第三方权威机构（CA，即证书颁发机构）或内部的根CA。
  • 过程：  自己生成公钥/私钥对，并生成一个包含公钥和身份信息的CSR文件，然后将CSR发送给CA。CA验证你的身份后，用CA自己的私钥给你的公钥签名。
  • 应用：  公网上的网站（如支付宝、谷歌）、企业内部安全通信（如Kubernetes集群）。

2. 详细对比

A. 信任机制

• 自签名：  需要手动信任。浏览器或操作系统默认不信任自签名证书，访问时会提示“不安全”。除非用户手动点击“继续前往”或手动安装该证书到“受信任的根证书颁发机构”列表。
• CA签发：  受浏览器/操作系统信任。如果CA的公钥已经内置在操作系统（如Windows、MacOS）或浏览器中，那么由该CA签发的所有证书都会自动被信任，不会有安全警告。

B. 身份验证（认证强度）

• 自签名：  无法验证对方身份。任何人都可以伪造一个声称是“某银行”的自签名证书，没有第三方来核实这个声称的真实性。
• CA签发：  需要验证身份。CA（如Let‘s Encrypt、DigiCert等）在签名前，会通过DNS验证、邮箱验证或企业资质审核来确认你确实拥有这个域名或代表了这家公司。

C. 有效期

• 自签名：  有效期通常设置得比较长，例如10年、20年甚至更长，因为不涉及频繁的吊销或更新。
• CA签发：  有效期较短（目前行业趋势是90天到1年）。为了安全性，现代浏览器不再信任长期有效的证书。

D. 安全性（私钥管理）

• 自签名：  私钥完全由自己保管，不经过网络传输。缺点是容易养成随意点击信任的习惯，容易遭受中间人攻击（如果用户无视警告继续访问恶意站点）。
• CA签发：  私钥同样由自己保管（CSR只包含公钥和身份信息，不包含私钥）。缺点是如果CA被黑客攻破，CA可以签发假的证书。

E. 吊销机制

• 自签名：  不支持吊销列表或OCSP（在线证书状态协议）。如果私钥泄露，你只能手动去每台信任它的机器上删除它。
• CA签发：  支持吊销。如果私钥泄露，可以请求CA吊销该证书，客户端可以通过CRL或OCSP查询证书状态。

3. 适用场景

场景	自签名	CSR + CA 签发
个人开发/学习	✅ 最合适（简单、免费）	❌ 没必要，除非想学习完整的PKI体系
局域网内部服务	✅ 合适（可以在公司内部部署根CA，所有电脑信任根CA）	❌ 没必要（公网CA不认识内网IP或.local域名）
公网网站（生产环境）	❌ 绝对不行（浏览器会拦截，用户流失）	✅ 必须使用（如购买证书或使用Let's Encrypt）
微服务/容器集群	⚠️ 可用但麻烦（常用于服务间mTLS，可以自建集群CA）	✅ 更好（可以使用Vault等工具搭建内部CA服务）

4. 实际操作流程对比

假设你要为域名 example.com 生成证书：

• 自签名流程：

  1. openssl req -x509 -newkey rsa:2048 -keyout example.key -out example.crt -days 365
  2. （一步到位，直接得到 CRT 和 KEY）

• CA 签发流程：

  1. 生成私钥：  openssl genrsa -out example.key 2048
  2. 生成 CSR：  openssl req -new -key example.key -out example.csr
  3. 发送 CSR：  将 example.csr 发给 CA（比如购买证书或提交给Let's Encrypt）。
  4. CA 验证：  验证你对 example.com 的所有权。
  5. CA 签发：  CA 返回给你 example.crt（由CA签名的证书）。

总结

• 自签名证书相当于自己写了一张身份证并自己签了字。在只有你自己承认的圈子里（比如家里的局域网）可以使用，但出了这个圈子，没人会认可。
• CSR + CA 签发的证书相当于拿着自己的资料（CSR）去公安局（CA）办了一张身份证。因为操作系统（相当于“社会系统”）内置了对“公安局”的信任，所以全社会都会认可这张身份证。