Appearance
OID 与 EKU 是什么关系？ClientAuth 的现状与 CA 调整时间
OID 是对象标识符，EKU 是表示证书用途的扩展。EKU 中的每个用途由一个 OID 标识。 ClientAuth 表示 TLS 客户端认证，用于调用方向服务端证明身份。
1. OID、KU 与 EKU 分别是什么？
OID（Object Identifier，对象标识符）是按层级分配的数字标识，例如 1.3.6.1.5.5.7.3.2。证书使用 OID 标识扩展类型、算法、策略和用途等对象。阅读证书时，结合 OID 所在的字段判断它的含义。
| 名称 | 表示什么 | 示例 |
|---|---|---|
| OID | 给某个对象或含义分配的标识 | 1.3.6.1.5.5.7.3.2 标识 TLS 客户端认证用途 |
| KU（Key Usage，密钥用法） | 以位标志表示密钥允许进行的操作 | Digital Signature、Key Encipherment；扩展本身的 OID 为 2.5.29.15 |
| EKU（Extended Key Usage，增强型密钥用法） | 在 KU 基础上进一步限定用途；内容是一组用途 OID | ServerAuth、ClientAuth；扩展本身的 OID 为 2.5.29.37 |
例如，一张同时包含 ServerAuth 和 ClientAuth 的证书，可以简化理解为：
text
证书扩展：Extended Key Usage（2.5.29.37）
├─ TLS 服务器认证（1.3.6.1.5.5.7.3.1）
└─ TLS 客户端认证（1.3.6.1.5.5.7.3.2）“增强型密钥用法”是扩展名称；其中每个用途由自己的 OID 标识。证书查看器可能显示中文名称、英文名称或数字 OID，指向同一标准用途。
常见 EKU 用途
| 用途 | 标准名称 | OID |
|---|---|---|
| TLS 服务器认证 | id-kp-serverAuth | 1.3.6.1.5.5.7.3.1 |
| TLS 客户端认证 | id-kp-clientAuth | 1.3.6.1.5.5.7.3.2 |
| 代码签名 | id-kp-codeSigning | 1.3.6.1.5.5.7.3.3 |
| 邮件保护 | id-kp-emailProtection | 1.3.6.1.5.5.7.3.4 |
| 时间戳 | id-kp-timeStamping | 1.3.6.1.5.5.7.3.8 |
| OCSP 响应签名 | id-kp-OCSPSigning | 1.3.6.1.5.5.7.3.9 |
KU 与 EKU 同时存在时，实际用途必须满足两者限制。对于包含 anyExtendedKeyUsage（2.5.29.37.0）或省略 EKU 的证书，可接受的用途由应用要求及证书策略共同决定；应用可以要求证书明确包含指定的用途 OID。依据：RFC 5280 §4.2.1.12。
2. ClientAuth 与 ServerAuth 有什么区别？
- ServerAuth：服务端向调用方证明身份，例如浏览器验证 HTTPS 网站的服务器证书。
- ClientAuth：调用方向服务端证明身份，例如 mTLS 中 API 调用方出示客户端证书。
text
调用方 服务端
←── 服务端证书（ServerAuth） ──
── 客户端证书（ClientAuth） ──→ 仅在要求客户端证书认证时“客户端”指发起连接的一方，可以是浏览器、应用程序或另一台业务服务器。常规 HTTPS 访问由浏览器校验服务端证书；启用客户端证书认证的服务还会要求调用方出示 ClientAuth 证书。
使用 ClientAuth 证书进行 mTLS 认证，需要同时配置证书、信任关系和服务端验证规则。 服务端启用客户端证书认证、信任其 CA，并校验证书链、有效期、吊销状态及应用身份与权限。选择证书时，服务端身份认证对应 ServerAuth，调用方身份认证对应 ClientAuth。
3. 客户端认证 EKU 的现状
ClientAuth 仍是有效的标准用途。当前调整主要涉及公共 TLS 服务器证书的用途配置及浏览器信任层级。 私有 PKI 和其他适用的客户端认证签发体系可继续按用途签发，由业务验证方建立相应信任。
Chrome 根计划正在推动 TLS 服务器认证专用层级。按当前政策 §1.3.2：
- 对现有 Chrome 信任层级，
2026-06-15起，按该日及之后向 CCADB 披露的中间 CA 证书适用 ServerAuth-only 要求。这一日期适用于中间 CA 证书。 - 对相应层级，
2027-03-15及之后签发的终端 TLS 证书要求只包含 ServerAuth。CA 可以更早执行，申请加入 Chrome 的专用层级还适用更严格要求。
Chrome 根库用于验证网站服务器身份；客户端证书的信任和用途由接收它的业务服务端校验。两者按各自的信任策略运行。政策依据：Chrome 根计划 §1.3.2。
4. 各 CA 的变更进度与时间
下表依据各 CA 的官方公告与证书策略，整理主要合作品牌公共 SSL/TLS 产品的调整安排。国密、私有证书和其他身份产品的安排需按具体产品确认。
| CA / 品牌范围 | 关键时间 | 调整说明 |
|---|---|---|
| DigiCert；公告涵盖 GeoTrust、Thawte、RapidSSL。Secure Site 为 DigiCert 产品系列 | 2025-10-01 默认移除；2027-03-01 最终停止提供 | 已进入默认 ServerAuth-only 阶段；过渡期是否可保留 ClientAuth 需按产品及渠道确认。2027-03-01 起包括新签、续期、重颁发和副本均不再提供。见 DigiCert 公告。 |
| GlobalSign | GCC 主要迁移日 2026-07-27；未在 7 月迁移的账号计划 2026-09-13 切换；Atlas 按对应公告 | R46/E46 专用 TLS 根下仅保留 ServerAuth；上述计划日期已经过去，具体账号的完成情况以实际签发层级及证书用途配置为准。见 GCC 公告及 Atlas 公告。 |
| Certum | 公告列明 2026-05-15 停止签发带 ClientAuth 的公共 SSL/TLS 证书 | 具体产品执行情况需通过支持确认。公告中的 Certum 签发日期与 Chrome 政策分别核对；Chrome 终端 TLS 证书要求采用上文的 2027-03-15。见 Certum 公告。 |
按三个阶段安排换证
默认移除表示新申请默认仅含 ServerAuth；最终停止提供表示该公共 TLS 产品结束 ClientAuth 签发；存量证书的使用期限由有效期、吊销状态、链路信任及验证方政策共同决定。已签发证书中的 EKU 保持原值；续期或重颁发取得新证书后，应重新检查用途。
5. 如何检查手里的证书？
在 Windows 证书查看器中打开“详细信息 → 增强型密钥用法”，核对是否包含“客户端身份验证”或 1.3.6.1.5.5.7.3.2。
已安装 OpenSSL 的环境可查看本地 PEM 证书：
sh
openssl x509 -in certificate.pem -noout -ext extendedKeyUsage同时带两个用途的输出示例：
text
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication上述命令用于读取 EKU 字段，实际用证时还需校验证书链、有效期及应用要求。最终 EKU 由 CA 的产品与签发策略决定，申请时确认 ClientAuth 支持情况，签发后检查实际证书。
需要调整 EKU 时，应按适用产品重新签发。PFX/JKS 封装和证书链补齐会保留原证书中的 EKU；直接修改证书内容会破坏 CA 签名。
6. 需要客户端认证时怎么处理？
仅提供网站 HTTPS 时，继续使用符合 ServerAuth 的公共 TLS 证书；系统依赖 mTLS、设备接入或服务间身份认证时，换证前确认 ClientAuth 和验证方信任要求，先测试再切换。
CertCloud 客户通过 TrustAsia 交付或技术支持确认私有 ClientAuth 证书或私有 PKI 方案，并在保留用途与证书校验的前提下完成联调。具体迁移步骤与 DigiCert 过渡期办理说明见 公共 SSL 证书移除 ClientAuth 后，双向认证怎么办？。
官方来源与维护
- OID、KU 与 EKU：RFC 5280 §4.2.1.3、§4.2.1.12。
- 浏览器层级要求：Chrome 根计划政策。
- CA 时间及 profile：上表链接的 DigiCert、GlobalSign、Certum 公告及 TrustAsia CA 信息库。
- CFCA 产品及政策查询：CFCA 全球信任体系 CP/CPS 入口。
CA 公告可能更新。办理前核对当前产品、正式公告与实际证书，确认最新用途配置和调整安排。