1.简介
Microsoft 根证书计划支持根证书分发，这样做让客户能够信任 Windows 产品。 本页介绍该程序的一般要求和技术要求。
注意
- 有关已发布的最新更新的信息，请参阅 https://aka.ms/rootupdates
- 用书签标记此页面：https://aka.ms/RootCert
2. 继续履行程序要求
审核要求
- 计划参与者在开展商业运营前，以及此后的每一年，都必须向 Microsoft 提供每个根、不受约束的从属 CA 和交叉签名证书的合格审核证据（请参阅 https://aka.ms/auditreqs）。
- 计划参与者必须负责确保所有不受约束的从属 CA 和交叉签名证书均符合计划审核要求。
- CA 必须公开披露不受约束的从属 CA 的所有审核报表。
- CA 提供商必须确保其支持 S/MIME 的根 CA 和所有能够颁发 S/MIME 证书的从属 CA 已经并且将继续根据最新版本（至少是以下一套标准之一）进行审核。 此审核必须每年至少进行一次。 初始审核期必须不晚于 2023 年 9 月 1 日开始。
- 适用于证书颁发机构的 WebTrust 原则和标准 – S/MIME
- ETSI EN 119 411-6 LCP、NCP 或 NCP+
- 适用于证书颁发机构的 WebTrust 原则和标准 – S/MIME
通信和披露要求
计划参与者必须向 Microsoft 提供至少两名“受信任的代理”的信息，这些代理将作为计划的代表，并提供一个通用电子邮件别名。 计划参与者必须在删除或添加人员作为受信任的代理时通知 Microsoft。 计划参与者同意通过电子邮件接收通知，并且必须向 Microsoft 提供接收官方通知的电子邮件地址。 当 Microsoft 发送电子邮件或公函时，计划参与者必须同意通知有效。 提供的联系人或别名中至少有一个应是24/7受监视的通讯频道，以便应对吊销请求和其他事件管理情况。
计划参与者必须每年向 Microsoft 披露其完整的 PKI 层次结构（非有限从属 CA、跨签名的非注册根 CA、从属 CA、EKU、证书约束），包括颁发给 CCADB 内部由外部第三方运营的 CA 的证书。 如有更改，计划参与者必须确保 CCADB 中的此等信息准确无误。 如果未公开披露或审核从属 CA，则该 CA 必须受域约束。
计划参与者必须通过电子邮件在将链接到已注册根的已注册根 CA 或从属 CA 的所有权转移给另一实体或个人之前至少提前 120 天通知 Microsoft。
原因代码必须包含在中间证书的吊销请求中。 吊销任何中间证书时，CA 必须在 30 天内更新 CCADB。
计划参与者同意，微软可以联系其认为可能会因计划中即将被移除的根 CA 而受到严重影响的客户。
其他要求
商业 CA 不能将根 CA 注册到组织内部高度信任的计划当中（即企业 CA）。
如果某个 CA 使用转包商来经营其业务的任何方面，则该 CA 将承担转包商的业务运营责任。
如果 Microsoft 单方面发现某个证书的使用情况或属性与受信任的根计划的目标不同，则 Microsoft 将会通知责任 CA 并请求吊销该证书。 CA 必须在收到 Microsoft 通知的 24 小时内吊销证书或向 Microsoft 请求作为例外处理。 Microsoft 将评审提交的材料，并自行决定是否授予或拒绝例外，然后通知 CA。 如果 Microsoft 不同意这是例外状况，则 CA 必须在遭到拒绝的 24 小时内吊销证书。
3. 计划技术要求
计划中的所有 CA 必须符合计划技术要求。 如果 Microsoft 认为某个 CA 不符合以下要求，则 Microsoft 会将该 CA 排除在计划之外。
A. 基本要求
- 根证书必须是 x.509 v3 证书。
- CN 属性必须标明发布者，并且必须是唯一的。
- CN 属性必须采用适合 CA 市场的语言，并且可供该市场中的典型客户阅读。
- Basic Constraints 扩展必须为 cA=true。
- Key Usage 扩展必须存在并且必须标记为“关键”。 必须将 KeyCertSign 和 cRLSign 的位位置设置为有效。 如果根 CA 私钥可用于对 OCSP 响应进行签名，则必须设置 digitalSignature 位。
- 根密钥大小必须满足下面“签名要求”中详述的要求。
- 待添加到受信任的根存储中的证书必须是自签名根证书。
- 自提交之日起，新构建的根 CA 的最短有效期限为 8 年，最长有效期限为 25 年。
- 参与根 CA 不得自本要求涵盖的根颁发新的 1024 位 RSA 证书。
- 所有颁发 CA 证书都必须包含具有有效 CRL 的 CDP 扩展，和/或指向 OCSP 响应者的 AIA 扩展。 最终实体证书可能包含具有有效 OCSP URL 的 AIA 扩展和/或指向包含 CRL 的有效 HTTP 终结点的 CDP 扩展。 如果不包括具有有效 OCSP URL 的 AIA 扩展，则生成的 CRL 文件应为 <10MB。
- 每个根证书的私钥和使用者名称必须是唯一的；同一 CA 在后续根证书中重复使用私钥或使用者名称的行为可能会导致意外的证书链问题。 在 Microsoft 分发之前生成新的根证书时，CA 必须生成新的密钥并应用新的使用者名称。
- 政府 CA 必须将服务器身份验证限制到政府颁发的顶级域范围内，并且只能向拥有主权控制的 ISO3166 国家/地区代码颁发其他证书（请参阅 https://aka.ms/auditreqs 第 III 部分，了解“政府 CA”的定义）。 每个 CA 各自的合同中均提及了这些政府颁发的 TLD。
- 链接到参与根 CA 的颁发 CA 证书必须单独使用服务器身份验证、S/MIME、代码签名和时间戳。 这意味着单个颁发 CA 不得将服务器身份验证和 S/MIME、代码签名或时间戳 EKU 结合起来。 必须为每个用例使用单独的中间对象。
- 最终实体证书必须满足 https://cabforum.org/baseline-requirements-documents/ 中 CAB 论坛基线要求的附录 A 中列出的订阅方证书的算法类型和密钥大小要求。
- CA 必须在其证书策略扩展最终实体证书中声明以下任何一个策略 OID。
- DV 2.23.140.1.2.1。
- OV 2.23.140.1.2.2。
- EV 2.23.140.1.1。
- IV 2.23.140.1.2.3。
- 非 EV 代码签名 2.23.140.1.4.1。
- S/MIME 邮箱验证类型 旧版 2.23.140.1.5.1.1。
- S/MIME 已验证邮箱多用途 2.23.140.1.5.1.2。
- S/MIME 邮箱验证了 Strict 2.23.140.1.5.1.3。
- S/MIME 组织已验证旧版 2.23.140.1.5.2.1。
- S/MIME 组织已验证多用途 2.23.140.1.5.2.2。
- S/MIME 组织已验证严格 2.23.140.1.5.2.3。
- S/MIME 发起人验证了旧版 2.23.140.1.5.3.1。
- S/MIME 发起人验证的多用途 2.23.140.1.5.3.2。
- S/MIME 赞助者严格验证 2.23.140.1.5.3.3。
- S/MIME 个人验证的旧版 2.23.140.1.5.4.1。
- S/MIME 个人验证的多用途 2.23.140.1.5.4.2。
- S/MIME 严格的个人验证 2.23.140.1.5.4.3。
- 从 2024 年 8 月开始，受信任的根证书计划管理的所有自定义 EV SSL OID 以及各自的工具将被删除并替换为符合 CA/B 论坛的 EV SSL OID (2.23.140.1.1)。 Microsoft Edge 团队将在浏览器中实现对 EV SSL OID (2.23.140.1.1) 的检查，因此将不再接受其他 EV SSL OID 与 Edge 保持一致并避免不兼容。
- CA 应用于其根证书的 OID 不得超过 2 个。
- 包含符合 IETF RFC 5280 的基本约束限制的最终实体证书的 CA 字段必须设置为“FALSE”，且不得存在“pathLenConstraint”字段。
- CA 必须从技术层面约束 OCSP 响应程序，以便唯一允许的 EKU 为 OCSP 签名。
- CA 必须能够按照 Microsoft 请求的具体日期吊销证书。
B. 签名要求
| 算法 | 除代码签名和时间戳之外的所有使用情况 | 代码签名和时间戳使用 |
|---|---|---|
| 摘要算法 | SHA2（SHA256、SHA384、SHA512） | SHA2（SHA256、SHA384、SHA512） |
| RSA | 2048 | 4096（仅限新根） |
| ECC /ECDSA | NIST P-256、P-384、P-521 | 不支持 |
请注意：
- Windows 和较新的 Windows 安全功能不支持使用椭圆曲线加密（ECC）（例如 ECDSA）的签名。 使用这些算法和证书的用户将面临各种错误和潜在的安全风险。 Microsoft 受信任根证书计划建议，由于这种已知的不兼容性和风险，ECC/ECDSA 证书不应向用户颁发。
- 代码签名不支持 ECC 或密钥 > 4096
°C 撤销要求
CA 必须设有记录在案的吊销策略，并且必须能够吊销其颁发的任何证书。
OCSP 响应者要求：a. 最低有效期为 8（8） 小时;最长有效期为七（7）天;和 b. 下一次更新必须在当前期间到期前至少八 (8) 小时内提供。 如果有效期超过 16 小时，则下一次更新必须在有效期 1/2 可用。
OCSP 不存在时的 CRL 建议：a。 应包含微软特定的扩展 1.3.6.1.4.1.311.21.4（CRL 下一次发布）。 b. 新的 CRL 应在下一个 CRL 发布时可用。 c. CRL 文件（完整 CRL 或分区 CRL）的最大大小不应超过 10M。
注意
当 OCSP 不可用时，第 3.C.3 节 - CRL 建议的目标是在大规模吊销的情况下为终端用户提供保障。
CA 不得使用根证书颁发最终实体证书。
如果 CA 颁发代码签名证书，则该 CA 必须使用符合 RFC 3161“Internet X.509 公钥基础结构时间戳协议 (TSP)”的时间戳颁发机构。
D. 代码签名根证书要求
- 如果 CA 请求，支持代码签名的根证书可能会在发布替换滚动更新根证书之日起的 10 年内或更短时间内，由该程序从分发中删除。
- 在 Windows 10 操作系统中，根证书若在其算法安全期限（例如 RSA 1024 = 2014、RSA 2048 = 2030）后仍在发布中仅用于支持代码签名，可能会被设置为“禁用”。
- 从 2024 年 2 月开始，Microsoft 将不再接受或识别 EV 代码签名证书，CCADB 将不再接受 EV 代码签名审核。 从 2024 年 8 月开始，所有 EV 代码签名 OID 都将从 Microsoft 受信任根证书计划的现有根证书中删除，所有代码签名证书都将受到同等对待。
E. EKU 要求
CA 必须为分配给其根证书的所有 EKU 提供业务理由。 该理由可以采取某种或某些类型证书发行的现有业务所提供的公开证据形式，也可以是表明计划在根证书发布后一年内发行这些证书的业务计划。
Microsoft 将仅启用以下 EKU：
- 服务器身份验证 =1.3.6.1.5.5.7.3.1
- 客户端身份验证 =1.3.6.1.5.5.7.3.2
- 安全电子邮件 EKU=1.3.6.1.5.5.7.3.4
- 时间戳 EKU=1.3.6.1.5.5.7.3.8
- 文档签名 EKU=1.3.6.1.4.1.311.10.3.12
- 此 EKU 用于在 Office 中对文档进行签名。 其他文档签名不需要要求。
F. Windows 10 内核模式代码签名 (KMCS) 要求
Windows 10 提高了验证内核模式驱动程序的要求。 驱动程序必须经 Microsoft 和采用扩展验证要求的计划合作伙伴签名。 希望在 Windows 中纳入内核模式驱动程序的所有开发者都必须遵循 Microsoft 硬件开发团队所述的过程。 有关详细信息，请参阅适用于 Windows 硬件的合作伙伴中心。