DV、OV 和 EV 描述的是证书颁发机构在签发 TLS 证书之前验证了多少信息。域名验证证明申请人对证书中的域名拥有控制权;组织验证在此基础上加入公司的法律身份;扩展验证则按照一套单独的指南,增加更严格的身份核查。三者的密码学部分完全相同,浏览器对三者的显示方式也一样;2019年以来,这些差异主要对读取证书详情的人和系统有意义。
概览
| DV | OV | EV | |
|---|---|---|---|
| CA 验证的内容 | 对每个域名的控制权 | 域名控制权,加上组织的合法存续、名称和地址 | OV 的各项核查,加上注册号、管辖区、实际运营状态以及请求者的授权 |
| 规则 | 《基线要求》§3.2.2.4 | 《基线要求》§3.2.2.1 至 §3.2.2.3 | CA/Browser Forum《EV 指南》 |
| 策略 OID | 2.23.140.1.2.1 | 2.23.140.1.2.2 | 2.23.140.1.1 |
| 主体字段 | 通常只有 CN;域名写在主题备用名称(SAN)中 | O、L、ST、C | 再加上 businessCategory、jurisdictionC、serialNumber(注册号) |
| 签发耗时 | 几秒到几分钟(ACME) | 首次审核通常需要几小时到几天 | 通常需要几天 |
| 自动化 | 完全自动化(ACME) | 部分自动化:身份审核一次,之后复用 | 部分自动化 |
| 验证数据复用(2026年3月15日起) | 域名控制权:200 天,2029年3月降至 10 天 | 组织身份:398 天 | 由《EV 指南》规定 |
| 证书最长有效期 | 目前 200 天,2027年3月起 100 天,2029年3月起 47 天 | 相同 | 相同 |
| 浏览器地址栏 | 锁形图标 | 锁形图标 | 锁形图标(EV 标识已移除:2018年 Safari 12,2019年 Chrome 77 和 Firefox 70) |
每个级别证明了什么
域名验证证明申请证书的一方在当时控制着该域名,方式包括:通过 HTTP 提供令牌(http-01)、发布 DNS TXT 记录(dns-01)、响应 TLS-ALPN 挑战,或者采用《基线要求》§3.2.2.4 中列出的其他方法之一。2025年起,CA 必须从多个网络视角交叉核实这些检查,因此仅劫持某一个观测点所见的 DNS 或 BGP 路由,已不足以拿到证书。DV 证书完全不说明网站由谁运营;钓鱼域名和银行一样能轻松拿到 DV 证书。
组织验证会对照官方登记机构的记录和经过验证的联系方式进行核查,然后把申请人经过验证的法定名称、所在地和国家写入证书主体。扩展验证采用更严格、规定更细的流程,涵盖注册号、注册成立地的管辖区、实际运营状态,以及验证批准该请求的人员,结果记录在专用的主体属性中。
三者都无法证明的是:网站是安全的、组织是诚实的,或者与你打交道的人就是其所声称的那个人。
如何判断网站使用的是哪一种
证书策略(Certificate Policies)扩展中的策略 OID 标明验证级别;主体显示经过验证的内容。下面的脚本于2026年10月20日用 OpenSSL 3.6.5 运行,从三个线上网站读取了这两项信息。
for host in letsencrypt.org www.microsoft.com www.paypal.com; do
echo "== $host"
openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null \
| openssl x509 -noout -subject -ext certificatePolicies
done
== letsencrypt.org
subject=CN=letsencrypt.org
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
== www.microsoft.com
subject=C=US, ST=WA, L=Redmond, O=Microsoft Corporation, CN=www.microsoft.com
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.311.76.509.1.1
CPS: http://www.microsoft.com/pkiops/Docs/Repository.htm
Policy: 2.23.140.1.2.2
== www.paypal.com
subject=jurisdictionC=US, jurisdictionST=Delaware, businessCategory=Private Organization, serialNumber=3014267, C=US, ST=California, L=San Jose, O=PayPal, Inc., CN=www.paypal.com
X509v3 Certificate Policies:
Policy: 2.16.840.1.114412.2.1
Policy: 2.23.140.1.1
CPS: http://www.digicert.com/CPS
第一张是 DV(只有名称),第二张是 OV(组织和地址),第三张是 EV(注册成立地管辖区、业务类别和注册号)。多出来的 OID 是各家 CA 自己的策略标识符。证书解码器可以为粘贴的 PEM 显示相同的字段。
浏览器显示什么
浏览器曾经用绿色地址栏和公司名称来显示 EV 证书。研究发现,用户很少注意到这个标识是否存在,也不会因此改变自己的行为;研究人员还证明,法律上独立的公司可以为与知名品牌极易混淆的名称取得 EV 证书。2018年,Safari 12 把公司名称从地址栏中移除;Chrome 77(2019年9月)和 Firefox 70(2019年10月)把 EV 详细信息移到了页面信息面板中。如今三个级别显示的都是同样的锁形图标,只有用户打开证书详情时才能看到组织信息。
运维上的差异
对所有人来说,证书有效期和验证数据的复用期限都在缩短。根据 SC-081v3 提案,2026年3月15日起签发的证书有效期最长为 200 天,2027年3月降至 100 天,2029年3月降至 47 天;域名验证结果目前可复用 200 天,2029年3月起只能复用 10 天,而组织身份信息可复用 398 天。因此,每张公开证书都需要自动续期,而 OV 和 EV 还要在同样的自动化之上增加定期重新审核身份的步骤。
ACME 本身只验证域名控制权。一些商业 CA 支持通过外部账户绑定(External Account Binding,RFC 8555 §7.3.4)把 ACME 账户与预先审核过的组织绑定,并接受这些账户提交的 OV 和 EV 证书订单;这样,企业在首次人工身份核查之后就能自动续期。证书透明度会记录每一张公开受信任的 TLS 证书,因此 OV 和 EV 证书中的组织详细信息一经签发就会公开。
如何选择
- 公开网站和 API:DV,用 ACME 自动化。把省下的精力投入 HSTS、CAA 记录和 CT 监控。
- 要求证书主体身份明确的合同、监管机构或合作伙伴(某些支付、银行和政务集成):OV;在明确要求 EV 的场合使用 EV。
- 按证书中的组织名称做匹配的客户端系统:OV;但对于这类集成,更推荐采用公钥固定或使用私有 CA。
- 内部服务和 mTLS:三者都不用,改用私有 CA。
- 代码签名:这是另一种产品,有自己的验证规则,并要求使用受硬件保护的密钥(2023年6月起强制要求),不是 TLS OV 或 EV。
- 品牌保护:CAA 记录、CT 监控和域名资产管理能更直接地应对 EV 原本想要应对的风险。
迁移说明
- 从 EV 或 OV 迁移到 DV 通常只需更换证书,服务器上无需其他改动:为相同的域名申请 DV 证书(使用新密钥,最好是 ECDSA P-256),连同完整的证书链一起部署,然后让旧证书自然过期。
- 检查对主体字段的依赖:匹配
O=的客户端允许列表、监控规则或合作伙伴集成,在换成 DV 后都会失效。 - 先实现自动化:无论验证级别如何,在 200 天的有效期下手动续期就已经有风险,到 47 天时更是跟不上。
- 设置 CAA 记录,只允许你选定的 CA 签发证书,并用
accounturi(RFC 8657)把记录绑定到你的 ACME 账户;CAA 记录生成器可以生成这些记录。 - 关注 CT:证书透明度监控工具会列出为你的域名签发的证书,这样任何级别的意外签发都能被发现(面向开发者的证书透明度)。
参考资料
- CA/Browser Forum《基线要求》(§3.2.2、§3.2.2.4、§7.1.6.1)
- CA/Browser Forum《EV 指南》
- SC-081v3 提案:缩短有效期和数据复用期限
- SC-067v3 提案:多视角签发佐证
- RFC 8555:ACME
- RFC 8659:CAA 和 RFC 8657:CAA 账户绑定