你正在搭建一个安全网站，浏览器却突然弹出「连接不安全」警告，很令人沮丧吧？这种情况常发生在站点使用了自签名证书时——这是一种由同一实体自行创建并签名的 SSL 证书，而非来自受信任的证书颁发机构（CA）。虽然这类证书易于生成且零成本，但浏览器并不将其视为可信，通常会引发安全警告，让用户犹豫是否继续访问，还可能将站点暴露于中间人攻击等潜在风险中。
那么这是否意味着自签名证书永远不该使用？并非如此。虽然它们不适合公开网站，但在开发、内部网络以及测试环境中相当有用。究竟何时该用、何时该避免？本文拆解自签名证书的定义、用途、相关风险，以及它真正派上用场的情形，并指导你如何创建一张，同时分享降低安全风险的最佳实践。
什么是自签名证书，它如何工作？
自签名证书是一种由开发者自行签名的 X.509 数字证书，不同于受信任第三方 CA 颁发的证书。虽然它们的工作方式与 CA 签发证书相同，但缺少外部审核流程，这正是浏览器和操作系统不信任自签名证书的原因。访问使用 CA 签发证书的网站时，浏览器会通过受信任根证书核对 CA 的数字签名来验证证书真实性；而自签名证书没有这一步验证，于是触发安全警告。它缺少 CA 带来的「信任链」，即没有独立实体为站点或服务器的身份与可信度背书。
自签名证书的常见用途是内部、非公开场景，如开发与测试环境，不建议用于用户信任与数据安全至关重要的生产环境。尽管如此，在受控环境中它仍在安全通信中扮演重要角色，可在不引入外部 CA 的情况下提供加密。不过用户仍需手动将其加入受信任证书存储（如 Microsoft 管理控制台 MMC）以避免警告与连接问题。
组织为何使用自签名证书？
组织选择自签名证书用于内部需求与测试，是因为它无需外部验证。由于用于公开应用会带来多种安全风险，自签名证书的使用通常仅限于私有网络。具体原因包括：
开发与测试
开发者在本地与预发布环境中偏好自签名证书，因为它们无需昂贵复杂的 CA 证书采购即可模拟 HTTPS 连接，在开发早期或测试阶段尤为有用。
内部通信
许多组织为没有外部交互的内部服务器、应用与设备使用自签名证书。由于证书有效性只需在组织内部成立，无需引入 CA。
成本与便利
创建自签名证书既免费又简单，组织将其用于非生产需求。生成无需付费、消除延迟，对快速实施或测试场景是重大优势。但这些证书需手动维护，包括定期续期与安全分发到所有相关系统。
控制与灵活性
自签名证书让组织完全掌控安全参数，包括有效期、加密方法与密钥强度。由于没有外部供应商依赖，证书生命周期管理更可行。但对大规模内部使用，部分组织选择部署自托管公钥基础设施（PKI）来简化内部证书签发与信任管理。
自签名证书的安全风险与常见错误
用户可能遇到 'error_self_signed_cert'、'err_cert_authority_invalid' 或 "NET::ERR_CERT_COMMON_NAME_INVALID" 等常见错误消息。这通常因为站点使用的自签名证书未被任何浏览器或 CA 识别，信任链中包含不受信任的自签名证书。了解相关风险与错误至关重要：
缺乏信任
浏览器和操作系统本身不信任使用自签名证书的网站，会向用户显示安全警告，削弱用户参与意愿并降低信心。
易遭中间人攻击（MITM）
自签名证书没有第三方 CA 的验证机制，因此更容易遭受中间人攻击。攻击者可轻易拦截并篡改服务器与用户间的通信，以窃取密码、用户资料等敏感数据。
无吊销机制
自签名证书没有像 CA 签发证书那样通过证书吊销列表（CRL）或在线证书状态协议（OCSP）的标准化吊销流程。一旦证书被泄露，它仍会持续生效，没有任何吊销程序，使站点暴露于攻击之下。
合规问题
许多行业法规强制使用受信任 CA 的证书来保障通信安全。自签名证书可能不满足这些规则，导致法律与财务问题。例如医疗与金融行业对数据保护和强加密有严格规定。
钓鱼攻击风险
用户可能习惯忽略与自签名证书相关的安全警报，从而更易落入钓鱼骗局。恶意行为者利用这一习惯搭建带自签名证书的虚假网站，企图骗用户信任这些冒牌站点。
品牌声誉受损
相关安全警报会吓退潜在访客，使其担心网站不保护登录信息或个人数据，进而对站点流量、转化率造成负面影响，并随时间损害品牌形象，最终导致用户失去对网站的信任。
何时该使用自签名 SSL 证书？
自签名证书理想的使用场景是信任因素并不关键的场合。在开发与预发布环境中，它能在不依赖第三方 CA 的情况下建立安全通信。开发者可轻松生成自签名证书，在测试或构建阶段加密数据——尽管浏览器不信任，开发者机器与服务器之间的连接仍是安全的。自签名证书在封闭内部网络中同样有用，其便利与低成本使其成为企业内部工具（如仅供员工访问的仪表盘）的好选择，这些场景无需外部验证。面向公众互联网的网站或服务应配备来自受信任 CA 的 SSL 证书，以避免「不安全」等浏览器安全警告和可能劝退用户的信任问题。
如何创建自签名证书？
可使用 OpenSSL 等工具创建自签名证书，步骤如下：
第 1 步：安装 OpenSSL
确保系统已安装 OpenSSL。
第 2 步：生成私钥
运行以下命令创建私钥：
openssl genpkey -algorithm RSA -out private.key第 3 步：创建证书签名请求（CSR）
此步对自签名证书可选，但可用于指定证书详情：
openssl req -new -key private.key -out request.csr第 4 步：生成自签名证书
使用私钥（及已创建的 CSR）生成证书：
openssl req -x509 -key private.key -out certificate.crt -days 365该命令创建有效期为 365 天的证书。
第 5 步：配置服务器
在服务器上安装证书与私钥，并配置应用使用它们进行 SSL/TLS 连接。
降低自签名证书风险的最佳实践
虽然自签名证书安全性有限，仍可实施一些最佳实践来降低相关风险：
限制使用范围
仅在信任受控、无需外部验证的环境中使用，切勿用于面向公众、用户信任与安全至关重要的应用或服务。
实施严格的访问控制
私钥与证书文件应通过严格的访问控制策略严密管控，仅授权人员可生成、访问和管理证书，并部署恰当的身份认证机制保护这些凭据。
定期轮换证书
定期生成新的自签名证书有助于降低被泄露的风险。规律的更新流程可确保过期或存在漏洞的证书不被继续使用，避免被攻击者利用。
监控安全警报
持续警惕对识别自签名证书相关的安全风险或警报至关重要。SSL Labs、OpenSSL 等安全工具可帮助发现错误配置，并在证书过期警告和异常活动检测时提供通知，以便及时补救。
教育用户
访问带自签名证书内部系统的用户，需要了解其安全性质与关联风险。适当的教育能帮助内部用户理解证书用途，从而正确应对各类安全警报。
结语
自签名证书能在内部工具与测试环境中零成本快速落地 SSL，但其安全局限性必须被严肃对待。由于缺少第三方审核与验证，它们无法为需要与普通终端用户交互的应用提供足够的信任与安全保障。通过证书轮换策略、访问控制协议以及监控方案等最佳实践，可将自签名证书的安全风险降至最低。