要点总结

• 2026 年 5 月的安全更新 (KB5087539) 将 ML-DSA（NIST FIPS 204后量子签名算法）引入 Windows Server 2025 上的 AD CS。CA、证书模板和在线响应程序现在可以使用抗量子密钥进行签名。

• ML-DSA仅提供签名保护。它可以防止未来伪造证书和代码签名，但并不能确保 TLS 会话或加密数据的量子安全。要实现量子安全，需要使用 ML-KEM，微软已将其与复合证书一起列入后续开发计划。

• 不支持就地迁移。现有的证书颁发机构 (CA) 无法转换为 ML-DSA：您需要搭建一个新的、并行的层级结构。这使得早期实验成本低廉，而拖延的成本则很高。

• 即使量子安全的时间节点尚未确定，监管的时间节点也是固定的：NIST 计划在 2030 年后弃用 RSA-2048 和 ECDSA P-256，并在 2035 年后禁止所有易受量子安全攻击的公钥算法。今天发布的信任锚已经与这些日期重叠。

• 实际的第一步不是算法替换：而是加密资产清单和自动化层，这样最终的替换就变成了配置更改，而不是一个多年的项目。

悄无声息却影响深远的更新

2026 年 5 月 12 日，微软发布了 Active Directory 证书服务 (AD CS) 二十多年发展历程中最具影响力的变更之一。针对 Windows Server 2025 的 2026-05 安全更新 (KB5087539) 使AD CS能够使用 ML-DSA（由NIST在 FIPS 204 中标准化的基于模块格的数字签名算法）构建证书颁发机构、颁发证书并对 OCSP 响应进行签名。ML-DSA 是首个在微软内置 CA 中正式发布的后量子算法。

这不仅仅关乎加密技术本身。AD CS 默默地支撑着全球绝大多数企业级 Windows 系统中的证书颁发：域身份验证、智能卡、设备注册、内部 TLS 和代码签名。多年来，人们普遍认为 AD CS 处于维护模式，任何重要的加密现代化都必须在其他地方进行。但 2025-2026 年的版本周期（CRL 分区、审计改进以及现在的 PQC）改变了这种看法。微软的信息很明确：内置 CA 是后量子时代转型的参与者，而不是受害者。

在本文中，我们将详细解读已交付的内容、其背后的加密技术、目前哪些功能有效哪些无效、推动这一切的监管期限，以及您的 PKI 团队可以据此制定的务实的分阶段时间表。

为什么需要后量子密码学，以及为什么公钥基础设施（PKI）是首选方案

如今，您的证书颁发机构 (CA) 颁发的每个证书都基于RSA或椭圆曲线数学。它们的安全性都源于一些问题（例如整数分解和离散对数），而足够大且容错的量子计算机运行 Shor 算法就能高效地解决这些问题。对称加密的表现要好得多：Grover 算法只会将有效密钥强度减半，因此 AES-256 和 SHA-2 仍然非常安全。真正的安全隐患恰恰集中在公钥基础设施 (PKI) 的核心领域：非对称密钥和数字签名。

没有人能预测出真正具有密码学意义的量子计算机何时问世。但由于以下两个原因，这种风险如今已经存在：

• 现在收集，以后解密。攻击者如今正在记录加密流量和窃取的密文，意图在量子技术成熟后进行解密。任何需要在量子技术成熟后仍保持机密性的数据（例如健康记录、知识产权、国家机密），一旦经过易受量子攻击的密钥交换环节，实际上就会暴露无遗。

• 长期信任。这是公钥基础设施 (PKI) 特有的问题，它关乎签名而非保密性。2026 年颁发的根 CA 证书，有效期为 15 年或 20 年，必须在 2041 年或更久以后仍然不可伪造。今天应用的代码签名或固件签名，将在多年后由依赖方进行验证。如果底层算法的有效期也在此范围内，攻击者就可以伪造证书和更新，这些证书和更新能够完美地链接到您的信任锚点：从而追溯性地破坏所有基于这些信任锚点构建的系统。

  
  

稍加计算，便会发现紧迫性并非纸上谈兵。信任锚是任何企业中最持久的加密资产。如今建立的经典根节点，实际上是在押注量子计算在未来二十年内无法成熟——而美国国家标准与技术研究院 (NIST)、美国国家安全局 (NSA) 和微软都已公开表示不接受这一赌注。

转变背后的标准

2024年8月，经过八年的全球竞争，美国国家标准与技术研究院（NIST）最终确定了其首批三项后量子标准。所有这些标准都建立在数学问题（主要是结构化格）之上，而目前尚无有效的量子算法可以解决这些问题：

第四种签名标准 FN-DSA（基于 Falcon）目前仍处于草案阶段。对于企业级 PKI 规划而言，关键的配对很简单：ML-DSA 取代 RSA/ECDSA 用于签名；ML-KEM 取代 RSA 加密和 (EC)DH 用于密钥建立。AD CS 第一阶段实现了这一配对的前半部分。

你真正在与时间赛跑

对于“量子计算机何时会破解RSA？”这个问题，诚实的答案是：没人知道。但出于合规考虑，答案则要具体得多，因为监管机构决定不再等待确凿的证据。目前，三个时间线都指向同一个十年：

现在，将您自己的证书有效期与该表进行对比。2026 年颁发的 20 年根证书将在 2046 年过期，比禁用日期晚了 11 年。明年创建的 10 年颁发 CA 在 RSA-2048 成为正式审计发现时仍然有效。这就是为什么微软首先推出 CA 端支持的原因：层次结构中生命周期最长的对象必须最先进行迁移。

微软在 AD CS 中实际发布了什么

第一阶段的范围经过精心限定：它涵盖了Microsoft PKI的端到端签名层面。具体来说，在已打补丁的 Windows Server 2025 计算机上，AD CS 现在可以：

• 安装根 CA、从属 CA、企业 CA 和独立 CA，这些 CA 的密钥对和证书签名操作均使用 ML-DSA，包括在每个层级都使用 ML-DSA 时完全后量子链。

• 发布颁发 ML-DSA 叶证书的证书模板，用于代码签名、TLS/Web 服务器、用户和计算机用途。

• 通过证书 MMC 管理单元和 certreq.exe 注册这些证书，包括自动注册样式的模板 ACL 评估。

• 使用 ML-DSA 在线响应者签名证书对OCSP响应进行签名。

• 使用 ML-DSA 证书验证和应用 Authenticode 代码签名：Set-AuthenticodeSignature 和签名 UI 可以端到端地工作，.NET 10 通过 MLDsa / MLDsaCng 类向开发人员公开了该算法。

  
  

微软已明确公布了未来的发展路线图。支持将分阶段推出，平台团队承诺将 PQC 扩展到 AD CS 角色服务：证书注册策略和注册 Web 服务 (CEP/CES)、NDES 和在线响应程序：

平台基线。AD CS 中的 PQC 要求 CA 运行 Windows Server 2025 或更高版本（需安装 2026 年 5 月安全更新 (KB5087539)），注册客户端运行 Windows 11 24H2/25H2 或更高版本（需安装 2025 年 10 月更新 (KB5067036)）。目前没有迹象表明会向后移植：Windows Server 2019 和 2022 CA 预计不会获得 PQC 支持。如果您的颁发 CA 仍在旧平台上运行，则操作系统升级现已正式列入 PQC 的关键路径。所有 PQC 算法还需要 CNG 密钥存储提供程序：不支持旧版 CryptoAPI CSP。

ML-DSA 底层原理：PKI 工程师应该了解什么

ML-DSA 源自 CRYSTALS-Dilithium，后者是美国国家标准与技术研究院 (NIST) 安全竞赛的主要签名获胜者。它的安全性基于结构化格上的“带误差的模块学习”和“模块短整数解”问题的难度，而这些数学问题目前尚无已知的有效量子攻击手段。ML-DSA 的两个特性直接影响 AD CS 的行为，因此在接触控制台之前，务必先理解并掌握它们。

它是一种仅包含签名的算法

ML-DSA 无法加密数据，也无法执行密钥交换。仅此一点就足以解释您将遇到的大部分配置限制：模板必须仅用于签名用途；禁止使用密钥加密和密钥协商密钥；拒绝 EFS 和安全电子邮件密钥交换单元 (EKU)；TLS会话机密性在 ML-KEM 出现之前保持不变。如果工作流需要密钥来保护数据，而不是用于验证身份或完整性，那么从设计上讲，ML-DSA 就不是合适的工具。

三组参数，三种安全性/尺寸权衡

AD CS 支持所有三种 FIPS 204 参数集，且为纯模式（非复合模式）。请根据所需的安全性等级和预算进行选择：

初次接触时容易让人困惑的一个细节是：Windows 用户界面显示的密钥大小为 15,616 位，这与 RSA-2048 相比显得格格不入。这其实只是以比特为单位的公钥长度（1,952 字节 × 8）。没什么特别的，只是密钥更大而已。作为参考，ML-DSA-65 是颁发 CA 和叶子证书的合理默认选择（类别 3 与 AES-192 并列），ML-DSA-87 适用于根证书和需要最大裕量的长期锚证书，而 ML-DSA-44 则适用于密钥长度真正受限的情况，此时类别 2 是可以接受的替代方案。

为什么哈希算法下拉菜单消失了？

传统的公钥基础设施 (PKI)基于先哈希后签名的机制：证书颁发机构 (CA) 计算待签名数据的摘要，然后用其私钥对摘要进行签名。哈希算法的选择是一个独立的、可配置的自由度，而这正是业界最终使用 MD5 和 SHA-1 算法，却仍然使用完全有效的密钥进行签名，然后不得不进行痛苦的迁移来修复这一问题的原因。ML-DSA 则移除了这个自由度：消息处理是签名方案本身不可分割的一部分，内部固定，操作员无法选择。

AD CS 会如实反映这一点。在 CA 设置过程中，一旦您选择 ML-DSA 密钥算法，哈希算法列表就会简化为一个条目：NoHash。在证书模板中，哈希选择器和“备用签名格式”控件（PKCS#1 v2.1 开关）会变灰：没有签名方案可供选择。NoHash 并不意味着数据未进行哈希处理；它意味着哈希处理已内置于 FIPS 204 标准中，AD CS 不会假装您有选择余地。这样一类由来已久的 PKI 配置错误就彻底消失了。

纯证书与复合证书：过渡问题

后量子证书有两种架构类型，微软的路线图特意包含了这两种类型：

• 纯粹。该证书使用单一的后量子算法：即 AD CS 目前提供的算法。它是最简洁的最终状态，但链中的每个依赖方都必须已经了解 ML-DSA 才能对其进行验证。在包含众多设备、嵌入式协议栈和传统中间件的异构环境中，这确实是一个限制。

• 复合证书。该证书同时包含一个经典密钥（RSA 或 ECDSA）和一个后量子密钥，其签名也包含经典签名和后量子签名。验证需要同时验证这两个密钥，因此伪造证书意味着破解两种算法，只要其中一个密钥有效，证书就能保持安全。其代价是数据量较大（每种密钥都需要两份），并且要求验证者理解复合格式，该格式目前在 IETF LAMPS 草案中定义。

  
  

实际应用：纯 ML-DSA 适用于闭环的全新生态系统，您可以控制每个验证器：内部代码签名、基础设施认证、托管集群内的机器间信任。复合型 ML-DSA 是混合型环境的迁移方案，它需要后量子时代的安全保护，但又不希望一开始就依赖通用的 ML-DSA 支持。AD CS 第二阶段计划推出复合型 ML-DSA 和复合型ML-KEM；在此之前，纯 ML-DSA 的部署应围绕依赖方兼容性测试进行规划。

建立 ML-DSA CA：当今行之有效的方法

仅采用新的层级结构，这是设计使然。

部署过程中最重要的一点是：ML-DSA CA 必须全新安装。现有 CA 无法就地转换，也无法通过更新算法来实现：更改公钥算法意味着需要新的密钥、新的证书，以及全新的 CA 身份。微软的建议是，在生产 PKI 系统旁构建一个并行的后量子层级结构，并逐步迁移工作负载。虽然这听起来不太方便，但它与 PKI 历代轮换的模式一脉相承，这意味着您可以立即开始评估，而无需担心对生产环境造成任何影响。

安装 CA

在服务器管理器 AD CS 配置向导中，三个 ML-DSA 参数集现在与 RSA 和 ECDSA 一起出现在密钥算法列表中，选择其中一个会将哈希列表折叠为 NoHash。

现场提示：注意 NoHash 陷阱。您必须显式传递 `-HashAlgorithmName “NoHash”` 参数。AD CS 安装引擎默认使用 SHA-256 的 RSA 算法，即使您将密钥算法切换到 ML-DSA，它仍然会保留该 SHA-256 哈希值，因此，如果 ML-DSA 安装过程中省略了该参数，则会失败。同样的逻辑也适用于自动化部署：任何硬编码 SHA256 的部署脚本在访问 PQ CA 之前都需要一个条件分支。

安装完成后，certsrv.msc显示的内容完全符合预期：Microsoft 软件密钥存储提供程序持有 ML-DSA 密钥、NoHash 哈希算法以及 ML-DSA 签名算法的 CA 证书。密钥链构建、CDP/AIA 发布以及pkiview.msc健康检查均运行正常。

证书模板：五大设置，掌控一切

只有当模板格式正确时，ML-DSA 才会出现在模板的“密码学”选项卡中，并且其中几个要求可以直接追溯到“仅签名”：

注册、OCSP 和代码签名

目前，已在安装了 Windows 11 24H2/25H2 补丁的客户端上通过证书 MMC 向导和certreq.exe进行注册。NDES (SCEP) 注册目前尚不可用：如果您的 MDM 颁发的设备证书基于 NDES，则需要注意这一点。

现场提示：部分打补丁的客户端。在部分打补丁的 Windows 11 客户端上，注册向导可能会列出 ML-DSA，但在实际注册时失败。检查向导的“密钥大小”字段以确定原因：实际值（10,496 / 15,616 / 20,736）表示客户端已完全启用该算法，而 0 表示客户端的密钥存储提供程序中仅部分启用了该算法：请先完成补丁，然后再考虑 CA 的问题。

在线响应器接受 ML-DSA OCSP 响应签名证书（复制默认模板而非编辑它），并能无误地对响应进行签名。一个外观上的小问题：对于 ML-DSA 配置，响应器的 hash-algorithm 属性可能会显示一个无意义的值，因为没有哈希值可供显示。忽略该字符串，并信任pkiview.msc 的显示，它会报告响应器运行正常。Authenticode 也同样完善：使用Set-AuthenticodeSignature / Get-AuthenticodeSignature进行签名和验证可以端到端地完成，这使得内部代码签名成为 PQ 层级结构中最可靠的初始生产工作负载之一。

尚未存在之物

诚实地进行范围界定是优秀咨询工作的一半，所以这里用一种视角来概括一下当前的界限：

在向任何人承诺“量子安全内网”之前，请仔细阅读右侧栏。今天的版本确保了证书颁发和签名层面的安全。会话层面（TLS 密钥交换，以及传输中数据的“先收集后解密”保护）则取决于 TLS 协议栈中 ML-KEM 的集成。第三方依赖方的安全问题尚待解决：许多应用程序、设备和与 HSM 相关的中间件目前还无法解析 ML-DSA 证书，因此每个试点项目都需要兼容性矩阵，而不是想当然。

运营实际情况：规模、HSM 和运行两个 PKI

一切都在变大

格型安全是以字节为单位计算的。比较一下你的基础设施实际移动和存储的资源：

一个使用 RSA 算法的叶证书大小约为 1-1.5 KB，而使用 ML-DSA-65 算法时，由于包含了嵌入式公钥和颁发 CA 的签名，证书大小会达到 6-7 KB；一个三层证书链在握手开始之前就已经超过 20 KB。OCSP 响应的大小会增加一个签名，通常还会包含一个嵌入式签名证书。现在就应该为这些影响做好预算：CDP/AIA 和 OCSP 的带宽和缓存、证书存储和 CA 数据库、CLM 清单、ML-KEM 握手后的 TLS 记录和 MTU 行为，以及智能卡、TPM 和受限设备的容量限制。这些影响并非难以承受（公共 Web PKI 也面临着同样的变化），但它们应该纳入您的容量模型，而不是事后分析。

HSM：承诺前请核实

第一阶段的体验基于微软软件密钥存储提供程序 (KSP)，这对于实验室和许多内部层级结构来说已经足够。但对于生产环境和受监管环境中的颁发 CA 而言，则需要硬件支持的 ML-DSA 密钥，而这完全取决于您的 HSM 供应商的 CNG 提供程序是否在固件上公开了该算法，并且该固件是否已通过（或正在努力通过）FIPS 140-3 验证。主要供应商（例如：揽阁信息提供的Thales Luna、Luna Cloud HSM 服务）已在最近的固件版本中添加了对 FIPS 203/204 的支持，但验证状态和 KSP 集成成熟度因型号和版本而异。务必将“通过 CNG KSP 向我展示 ML-DSA 并提供验证文件”作为试点计划中的一项具体内容，并认真考虑在硬件完善之前，是否在早期阶段使用软件密钥。

你将运行两个公钥基础设施（PKI）多年。

并行层级结构并非周末实验室：它是一个独立的生产环境，拥有自己的模板、CDP/AIA 发布、OCSP、监控、密钥交换、CP/CPS 增量更新，以及最终针对传统架构的退役计划。能够妥善处理这一问题的组织，会将过渡视为一项加密敏捷性计划：如果证书的颁发和续期已经实现自动化并基于库存，那么算法的切换就变成了由机器执行的配置更改。如果您的系统仍然依赖电子表格和日历提醒来续期证书，那么 PQC 迁移将会让您感觉像是 SHA-1 弃用事件重演，只不过这次涉及您拥有的所有证书，而且有效载荷更大，截止日期也更严格。

务实的迁移时间表

将监管日期与具体的公钥基础设施 (PKI) 工作对应起来，可以得出五阶段计划。以下时间节点假设一家规模可观的企业从现在开始实施；您可以根据实际情况调整或缩短时间，但顺序不变：每个阶段都会降低下一个阶段的风险。

这预示着AD CS的未来走向

这里存在一个值得注意的二阶信号。十年来，人们普遍认为 AD CS 不会再获得任何实质性的投资，平台决策也据此制定。发布符合 NIST 最新标准的签名算法（并公布涵盖 ML-KEM、复合证书和注册角色服务的多阶段路线图）并非维护模式的行为。

这一时机也与公共信任生态系统中一场悄然发生的转变不谋而合：随着根程序将服务器和客户端信任分离，公共 CA 正在从 TLS 证书中移除客户端身份验证 EKU，这意味着庞大的 mTLS 应用领域（服务网格、设备集群、B2B API 身份验证）正在迁移到私有 CA，无论是否有人预料到。一个包含在操作系统许可中、与 AD 身份集成、并且现在使用后量子算法进行签名的私有 CA 平台，突然间成为了这些工作负载的理想选择。AD CS 不仅成功度过了后量子算法的过渡期，而且还借此机会重新加入到讨论中。

常见问题解答

我可以将现有的 AD CS CA 升级到 ML-DSA 吗？

否。ML-DSA CA 必须全新安装：不支持就地转换，也不支持使用新算法进行续订，因为更改公钥算法意味着需要新的密钥和新的 CA 身份。支持的模式是在工作负载迁移期间，与您现有的 PKI 并行运行一个后量子层次结构。

AD CS 中的 ML-DSA 能否使我的 TLS 实现量子安全？

尚未实现。ML-DSA 涵盖签名：证书和 OCSP 完整性、代码签名、身份验证。会话机密性依赖于密钥交换，而密钥交换需要通过 TLS 协议栈使用 ML-KEM；目前，IIS 甚至不会为HTTPS绑定 ML-DSA 服务器证书。传输中数据的“先采集后解密”保护是在密钥封装阶段实现的，而不是在这个阶段。

我应该采用哪套标准参数集？

ML-DSA-65（NIST 3 类）是颁发 CA 和叶证书的实用默认选项。ML-DSA-87 保留用于根证书和长期锚证书，前提是最大裕量足以满足要求；而 ML-DSA-44 则作为容量受限场景下的特例，在这些场景下，2 类证书的风险是可以接受的。

为什么我不能再选择哈希算法了？

由于 FIPS 204 将消息处理集成到签名方案本身中，因此无需单独配置哈希签名步骤。AD CS 将其表示为唯一的 NoHash 选项。请记住在脚本安装中显式传递此选项；安装引擎的默认设置仍然是 RSA/SHA-256，并且在您选择 ML-DSA 密钥时不会自动更正。

Windows Server 2019 或 2022 是否会获得 PQC 支持？

目前没有迹象表明会向后移植：AD CS 中的 PQC 是 Windows Server 2025 的一项功能。如果您的 CA 运行在较旧的平台上，则操作系统升级现在处于后量子时代的关键路径上，应该列入明年的计划，而不是 2030 年代的计划。

我们究竟何时才必须采取行动？

根据 NIST IR 8547，RSA-2048 和 ECDSA P-256 的弃用压力将于 2030 年开始，所有易受量子攻击的公钥算法将于 2035 年被彻底禁用，而 CNSA 2.0 最早将于 2027 年通过采购流程强制执行。但真正的推动因素在于您自身的证书有效期：如今颁发的长期有效证书的有效期已经与这些日期重叠。清点工作现在就应该开始；这样，算法更换就可以按照您自己的计划进行，而不是由审计人员来决定。

结论

2026 年 5 月的更新最好被理解为一声发令枪响。AD CS 现在能够基于标准化的、经 NIST 批准的密码学技术，构建一个完整的后量子签名平面（CA 层级结构、证书颁发、OCSP、代码签名），密钥封装和复合证书也已列入已发布的路线图。技术问题已从“微软何时行动？”转变为“我的系统是否已做好跟进准备？”

量子硬件的不确定性有利有弊，但合规时间表却并非如此：2030 年和 2035 年已成定局，今天签署的信任锚定协议在这些日期到来时仍然有效。能够平稳度过这一过渡期的组织，是那些将其视为加密敏捷性计划的组织：首先进行资产盘点，其次是自动化，最后才是算法。建立实验室层级结构，趁成本低廉时找出不兼容之处，然后让替换过程本身变得轻松自然。这才是优秀的 PKI 工程的精髓所在。

揽阁信息 · 值得您信赖的信息安全顾问！

相关文章：

• 量子截止时间并非你真正的问题
• 2026年是PQC行动年：为什么最初的90天至关重要
• 为什么后量子加密对企业数据安全至关重要
• 量子风险加剧了对加密敏捷性和后量子时代准备能力的需求，工业系统面临结构性差距
• 每位高管都需要了解的后量子密码学（PQC）知识
• 谷歌设定后量子密码学迁移的2029年时间表