管理 Windows Server 2003 公钥结构

公钥结构 (PKI) 要求在操作和维护方面进行的规划与其初次实现时进行的规划一样多。本文提供了有关如何规划和实现 Microsoft^® Windows Server^™ 2003 PKI 的管理和操作的指南。其中包括有关评估管理 PKI 所需资源的详细信息，以及有关分配管理角色和安排操作任务的指南。本文用较大篇幅描述了为使 PKI 保持最佳状态而需完成的日常操作和支持任务。本文基于 Microsoft System Architecture (MSA) 证书服务部署，也是对它的补充。

本页内容

	简介
	规划资源以管理 Windows PKI
	配置 PKI 操作环境
	操作 PKI
	容量规划和优化
	管理更改和配置
	常见支持任务
	摘要
	相关链接
	附录 A － PKI 设计概述
	附录 B － 通用标准管理角色

简介

管理 Windows Server 2003 公钥结构 是 Windows^® PKI 的操作和管理指南。具有 Windows XP 客户端的 Windows Server 2003 提供了一些迄今为止最为简便的 PKI 技术来进行部署和管理，尽管如此，仍需要对 PKI 进行管理。如果没有适当的操作支持，即使是只是中等复杂程度的 PKI 最终也会失败。

本文旨在提供简单明了的参考资料，使您了解为保持 PKI 正确运行而需要完成的管理、监视和支持任务。本文还包含如何规划资源以有效管理 PKI 和分配管理角色的一些指导原则，以及对其他相关 Microsoft 文档的引用。

本文是 Windows Server 2003 PKI Operations Guide（Windows Server 2003 PKI 操作指南）的姊妹篇，该指南中收集了一些可帮助您管理 PKI 的技巧和最佳做法。不过，本文是参照操作参考手册的形式组织的。您应该可以将本文中的指导信息直接作为 IT 操作的一部分实现。您需要使用 Windows Server 2003 PKI Operations Guide 和 Windows Server 2003 产品文档中的“公钥结构”章节作为本文内容的补充（请参见“相关链接”）。为最大限度地在这些资料之间减少重复和可能出现的不一致情形，本文中并未包含某些任务的详细信息，而是让您参见详细介绍该任务的文档。

本文中的指导准则以 Microsoft Systems Architecture version 2.0 Implementation Kit（Microsoft Systems Architecture 版本 2.0 实现工具包）和文章 Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure（Microsoft Windows Server 2003 公钥结构的最佳实现方法）中定义的企业 PKI 设计（使用具有 Windows XP 客户端的 Windows Server 2003）作为依据。上述两个文档描述的是基本相同的 PKI 的设计和构建。不过，对于其他 PKI 设计而言，本文中的大部分指导信息同样适用，稍加修改即可使用。

本文中的许多内容最初是为 Microsoft Solution for Securing Wireless LANs（Microsoft 安全无线 LAN 解决方案）准备的。本指南的概念和框架依据的是 Microsoft 操作框架 (MOF) 和 Microsoft 管理解决方案 (MSM)。有关对所有上述文档的引用，请参见“相关链接”。

概述

本文分为 6 大部分。前 2 个部分讨论规划和初始配置，其余 4 个部分集中阐述如何运行 PKI。

注意：除非另有说明，否则引用所链接的是本文中的相应部分。

范围

本文不包括任何有关以下内容的指导信息：

理解本文内容所需具备的条件

您应该熟悉 PKI 概念，尤其是 Microsoft 证书服务。还需要熟悉 Windows Server 2003（以及相关的 Windows XP）的以下方面：

继续阅读前，建议您先阅读 Microsoft Systems Architecture version 2.0 Implementation Kit 或 Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure 一文中的证书服务规划和构建章节（请参见“相关链接”），以了解本文所依据的解决方案的结构和设计。本文中所描述的大多数操作的前提条件是，PKI 是参照这些文档中所描述的相同规范设计和构建的，因此，了解这些前提条件非常重要。

本文中使用的 PKI 设计

“附录 A – PKI 设计概述”简要介绍了本文中使用的 PKI 设计。这是一个三层的 PKI 层次结构，具有基于 Windows Server 2003 平台的脱机根 CA 及中间 CA。文中描述的大部分任务都适用于更简单的配置（两层或者甚至一层），而无需进行更改或只需稍加改动。

返回页首

规划资源以管理 Windows PKI

这一部分讲述管理 Windows PKI 所需的人力资源规划。此处假定使用的是“简介”及“附录 A – PKI 设计概述”中描述的企业 PKI。尽管这一过程对于较简单的 PKI 安装也很类似，但需要对团队结构，尤其是必须完成的任务的工作量估计数字进行适当的调整。

需要考虑的有 4 个主要方面。前 2 个方面是分配管理角色和规划支持人员所需的培训。第 3 个方面是使 PKI 做好运行准备所需完成的任务。其中包括配置备份，分配管理权限，恢复规划及安排操作任务。第 4 个方面是保持 PKI 成功运行所需完成的有关操作、支持及服务台人员的日常任务。

这一部分不讲述 PKI 服务器或其他基础结构的规划、设计、安装和配置。

分配 PKI 管理角色

在 PKI 的管理中有若干种角色，每种角色代表一个与 PKI 有关的特定功能集。例如，批准证书申请、审核 CA 以及管理备份和存储就分属于不同管理角色的职责。在高安全性的环境中，可能会将每种角色分配给不同的人员，以防权限滥用。在其他组织中，可能只有一名管理员来负责所有的 PKI 任务；而大多数组织则介于这两种极端情形之间。

CA 管理角色具有一个通用标准配置文件。“附录 B — 通用标准管理角色”讨论了此配置文件与本文中使用的管理模型之间的关系。

确定管理模型的精细度

本文中使用的管理模型可满足多种不同的组织需求，从划分得非常细的管理角色到极为简单的职责划分，均可适用。PKI 管理功能已分为多个角色组，每个组对应一个域或本地安全组。本文中的所有过程均指明了执行这些过程所需的管理安全组成员身份。

借助这一方法，不同的组织就可以通过向所需的组中添加 IT 人员帐户来实现所需的角色精细度。例如，只由一名管理员负责所有 PKI 操作和支持任务的组织可向所有 PKI 角色组中添加该人员的帐户。对于需要在 PKI 管理员、备份操作员、审核员及应用程序所有者之间划分职责的更复杂组织，可将这些人员的帐户仅添加到完成各自的工作所需的 PKI 管理角色组中。

如果您尚未给 PKI 分配管理责任，则需要在 PKI 进入生产状态前完成分配。可使用表 1 来确定您需要为 PKI 管理人员分配哪些功能。“配置 PKI 操作环境”的第一组任务包括创建和填充 PKI 角色安全组以及为这些组分配适当的权限。

将功能角色映射到安全组

表 1 中描述了每个 CA 范围及企业范围内的 PKI 管理角色的功能，以及用于实现该角色的安全组。这些安全组用于描述本文中各过程的安全要求。每个过程都有一个“安全要求”部分，其中列出了操作人员需要成为哪些安全组的成员才能完成该过程。

该表也分为多个部分，分别对应于常见的管理边界。这种划分尽管很常见，但决非普遍适用，因此可能与您的组织并不完全匹配。例如，“应用程序所有者”可能是业务部门中的某个人而非支持组织。

脱机 CA（根 CA 及中间 CA）不能使用域组，而只能使用本地安全组。对于这些 CA，必须在 CA 自身上创建各个本地帐户，然后使用它们来填充本地管理组。对于联机 CA（属于域成员），将使用域安全组来应用适于每种角色的权限。域帐户用于填充角色组。

表 1：将证书服务角色映射到安全组

培训员工

操作和支持人员的培训内容差别很大，具体取决于他们的经验及其各自的角色和职责。以下部分列出了适合大多数大型 IT 组织不同职责级别人员的培训类型（包括 Microsoft Official Curriculum 课程）。有关这些课程的更详细信息，请参见“相关链接”。

PKI 管理员和第三层支持

在这一级别工作的 IT 人员极有可能是 Windows 2000 或 Windows Server 2003 的 Microsoft 认证系统工程师 (MCSE)，或具有同等知识和经验的人员。

以下课程非常有用。

操作员和第二层支持

为服务台提供支持并定期执行操作和监视任务的 IT 人员可能是 MCSE 或具有同等知识的人员。

以下课程对基本掌握 PKI 及 Windows Server 2003 平台中的其他安全技术特别有用。

服务台

服务台培训需求取决于服务台人员是提供全面支持，还是只为特定应用程序或系统提供支持。为 PKI 应用程序服务台支持人员进行客户端平台 (Windows XP) 和客户端应用程序（例如，Microsoft Office）的基本培训，对他们会大有帮助。重要的是，为服务台人员提供定期更新的常见问题解答 (FAQ)、文章及常见问题解决方法，这样他们就可以尽可能多地解决客户反映的问题，而不必向第二和第三层支持提交这些问题。

用户

用户培训的重要性往往被忽略，尽管这通常并不是 IT 运行部门的责任。由于用户对应用程序的工作方式的混淆不清，因此就不可避免地会产生支持需求。重要的是，提供有关应用程序或服务的正确使用方法的培训，包括用户在要求服务台提供支持前可以尝试的自助工具。还应就组织安全策略的相关方面对用户进行适当培训，使他们了解自身的职责。例如，他们应该知道报告丢失或被窃计算机或智能卡的程序，如何选择有效密码，如何防止他们的数据和凭据被滥用以及如何防范病毒。

操作环境配置任务

表 2 中列出了使您的 PKI 做好运行准备所要完成的任务。每项任务描述了如何配置 PKI 管理系统的某个方面，使之为进入生产环境做好准备。完成每项任务所需小时数的估计也包括在内。有关每项任务的描述，请参见“配置 PKI 操作环境”。

您不必执行所有这些任务，但在作出此项决定前，应该检查每项任务的细节。您可能需要重复执行其中的一些任务；例如，如果利用备份重建 CA，则可能需要为其重新配置备份和监视作业。

注意：工作量（小时数）为估计值，具体取决于组织的安全要求和操作方法。

表 2：初始设置任务

日常操作任务

表 3 中列出了保持 PKI 正常运行而需要定期执行的任务。它还包括可能的支持工作量估计，该值基于 Microsoft 内部 PKI 操作部门。有关这些任务的详细信息，请参见本文的“操作 PKI”及后续部分。

包括每项任务所需小时数、任务频率及年总工作量估计。“任务工作量”指的是任务的一个实例，而“年次数”指的是所有 CA 的总和。将两者相乘，便可得到该任务的年总工作量。

这些任务均与 PKI 结构服务有关，并且不包括 PKI 应用程序支持的工作量，因此，它们大都由第三和第二层支持人员来完成。对于不同的 PKI 应用程序，其支持工作量也千差万别。不过，在“示例：Microsoft OTG PKI 操作资源”中提供了 Microsoft 的操作和技术组 (OTG) 使用的支持资源，用于为 Microsoft 的 60,000 位 PKI 用户部署的应用程序提供支持（作为一个指南）。

注意：工作量（小时数）为估计值，具体取决于组织的安全要求及操作方法。

表 3：PKI 操作和支持任务

示例：Microsoft OTG PKI 操作资源

如前所述，表 3 中不包含 PKI 应用程序的支持要求。Microsoft OTG 部署了大量依赖于数字证书的应用程序。其中有：

表 4 中列出了这些应用程序和证书结构的支持资源。由于智能卡及相关照片 ID 和进门系统的物理管理开销很大，因此智能卡管理的工作量非常大。

表 4：支持资源

OTG 还使用单独的呼叫筛选中心来记录呼叫，并将它们发送到相应的服务台人员。服务台数字中未包含此项。

考虑到以下几点，您可以根据这些数字推定贵组织所需的人员数量。

返回页首

配置 PKI 操作环境

配置系统的操作环境是部署任何 IT 项目必不可少的步骤。它包括部署计划作业，配置监视和警报参数，创建性能测量基线和制订定期维护作业的时间表。如果不执行此步骤，进入生产环境的任何系统都无法达到性能预期值并最终失败。

这一配置阶段适用于 PKI，也同样适用于任何其他结构组件。这一部分描述了创建操作时间表；准备目录；为系统可用性做准备；配置监视和警报；并描述了将 PKI 投入生产而需要完成的其他基本任务。

配置任务清单

一般

准备目录

安全管理

系统管理

配置可用性和恢复选项

配置监视和警报

作业计划

创建操作时间表

创建操作时间表是部署 PKI 时最主要的部分之一。某些 PKI 维护任务每几个月或几年才执行一次。因此，如果未正确地安排这些任务，就可能存在实际需要执行任务时将其遗漏的风险。

可使用“日常操作任务”中的列表作为起点，为您的 PKI 制订一个操作时间表。该时间表应列出需要定期执行的所有任务，描述每项任务的频率并指定负责完成每项任务的人员。

该时间表应具有以下特点。

部署 PKI 支持服务

在部署 PKI 结构和依赖于该 PKI 的应用程序时，您应该确保已将该 PKI 的支持资源联机。您应将结构（CA 及支持服务）和 PKI 应用程序的部署时间错开，以便根据新的需求调整支持服务时间。以下步骤显示了如何配合 PKI 部署来实现这一目的。

准备目录

为证书服务管理准备域组织单元 (OU) 结构

此项任务的目的是，创建一个合适的 OU 结构来管理证书服务安全组。

安全要求

具有在 Active Directory 的指定部分创建 OU 权限的帐户

任务详细信息

此项任务只是对如何组织 PKI 的相关安全组的建议。实际使用的 OU 结构取决于现有 OU 结构及目前的管理策略和过程。表 5 中提供了一个简单 OU 子树的示例，可使用它来帮助组织本指南中创建和提及的安全组。应为 Enterprise PKI Admins 组授予为这些 OU 创建和删除组对象的权限。

表 5：安全组在 OU 结构内的位置

安全管理

安全管理涵盖与 IT 结构的安全组件有关的任务。

创建 PKI 管理组

管理角色和功能是使用域用户帐户和安全组定义的。

注意：该解决方案定义了多个安全组，分别对应于不同的管理角色。这样，您在委派 CA 管理职责时就可以拥有相当大的控制权。不过，如果它们不适合您的管理模型，则不必使用所有或任何角色。在极端情况下，如果您只有一名 PKI 管理员，他负责服务的各个方面，则可将此帐户添加到 CA 的所有角色组中。实际上，大多数组织使用某些角色分离功能，但很少会有组织使用 Windows 证书服务的所有角色分离功能。有关详细信息，请参见“分配 PKI 管理角色”。

在域中创建 PKI 管理组

如果您的每个企业 CA 都需要单独的 CA 管理员、证书管理员，审核员以及备份操作员组，请为每个 CA 创建单独的域组，而不是为每个角色创建单个组（如此处所示）。将它们命名为“CANameCA Admins”（其中，CAName 是 CA 的名称）或这些行中的其他内容。

这些组被创建为“通用”组，因为它们需要具有全林性作用域（可见性），并且可能包含来自多个域的成员。如果您只需要来自单个域的组成员，则可以使用域全局组。您只能在具有 Windows 2000 本机模式或更高版本的域功能级别的域中创建通用组。（有关域功能级别的详细信息，请参见“相关链接”。）如果您的域处于混合模式，则必须使用全局组。

您可以并且应该限制能够更改这些组成员的人员。以下过程将此功能限定为 Enterprise PKI Admins 组的成员。在执行此过程之前，您应该将至少一个有效的域帐户添加到 Enterprise PKI Admins 组中。以下过程使用名为 PKIGroupOwner 的帐户。该帐户被指定为 PKI 管理组的所有者，即从默认 Administrators 转让所有权。名称并不重要，您可以根据需要使用其他名称。

限制可以修改 PKI 管理组成员的人员

注意：无法防止域或企业管理员修改这些组。但是，此过程中的步骤（尤其是从内置 Administrators 组删除组所有权）有助于确保可以对任何未经授权的修改进行审核，因而不会出现无意中进行未经授权修改的情况。

脱机 CA 不能使用域组，因此需要在 CA 本身中为其创建等效的本地组。Enterprise PKI Admins 或 Enterprise PKI Publishers 组没有等效的本地角色。

在脱机 CA 中创建 CA 管理组

为 PKI 管理组分配权限

要在 CA 中使用管理角色（如审核员和证书管理员），您必须为每个角色授予安全组的适当权限。

注意：虽然本文使用了多个管理角色，但您也可自行将相同的帐户添加到多个角色中，以获得更简单的管理模型。有关详细信息，请参见“分配 PKI 管理角色”。

任务详细信息

第一项任务是使用域组为联机颁发 CA 设置权限。第二项任务是使用本地组为脱机 CA 设置权限。

为联机颁发 CA 配置管理角色

为脱机 CA 配置管理角色

委派企业 PKI 权限

全林性的 PKI 配置信息存储在“Active Directory 配置”容器中一个称为“公钥服务”的子容器内。默认情况下，仅限 Enterprise Administrators 安全组拥有此容器及其所有子容器和对象的写入权限。

此任务将“公钥服务”容器的权限授予 Enterprise PKI Admins 和 Enterprise PKI Publishers 组，以使他们能够行使通常为 Enterprise Admins 保留的某些职责。Enterprise PKI Admins 被授予管理大部分全林性 PKI 配置的权限。其中包括管理模板和 PKI 策略对象标识符 (OID)，指定根 CA 信任关系和颁发机构信息访问 (AIA) 以及目录中的 CRL 发布点。Enterprise PKI Admins 唯一不能执行的任务是将新的企业 CA 添加到林中。（本过程的后面部分详细介绍了如何将此任务委派给 Enterprise PKI Admins 组）。Enterprise PKI Publishers 具有更有限的一组权限，它可以将证书吊销列表和 CA 证书发布到目录中。

注意：此过程委派对 Active Directory 非常敏感的部分的控制权，它影响整个林范围内的用户和计算机。授予“公钥服务”容器控制权时要慎重。除其他功能外，具有修改此容器及其子容器权限的用户可以添加和删除受信任的根 CA，在“NT 验证”容器中添加和删除企业 CA 项，以及使用此权限为林中的任何用户创建有效的登录凭据。

安全要求

具有 Enterprise Admins 的成员身份

任务详细信息

为 Enterprise PKI Admins 授予权限

为 Enterprise PKI Publishers 授予权限

委派权限以安装企业 CA

将企业 CA 添加到林中是一项极其敏感的操作。企业 CA 可以为林中的任何帐户（包括任何域或企业管理员）颁发登录凭据，因此它只能由 Enterprise Admins 的成员进行安装。Microsoft 推荐并支持采用这种方法，并且它已经过了全面测试。除非您有委派此任务的特殊需求，否则，不要执行此操作。

但是，在有些情况下，您可能需要将此任务委派给不是 Enterprise Admins 成员的管理员。可通过执行下列两个过程为 Cert Publishers 组授予适当的权限，并为 Enterprise PKI Admins 组授予“还原文件和目录”用户权限来实现此目的。

重要信息：通过委派此任务，您可以不必在 Enterprise Admins 和 Enterprise PKI Admins 之间划定严格的安全边界；第二组的成员可将其权限提升到 Enterprise Admins 组的权限。您应将此委派过程视为一个用来支持管理策略的步骤，而不应视为一种严格的安全控制。

安全要求

具有要安装企业 CA 的域的 Domain Admins 成员身份

任务详细信息

Cert Publishers 安全组包含某个域中所有企业 CA 的计算机帐户。此组具有向用户和计算机对象发布证书以及向 CDP 容器（在前面过程中提到的）发布 CRL 的权限。在安装了联机 CA 后，需要将其计算机帐户添加到此组中。默认情况下，只有 Domain Admins、Enterprise Admins 以及内置的域 Administrators 组具有修改 Cert Publishers 成员的权限。要允许 Enterprise PKI Admins 成员安装企业 CA，您必须将此组添加到 Cert Publishers 的权限中。对于要安装企业 CA 的每个域，必须重复此过程。

为 Cert Publishers 授予“修改成员”权限

要安装企业 CA，您还需要在安装 CA 的域中具有“还原文件和目录”权限。证书服务安装过程需要使用此权限，将证书模板安装到域中。更具体地说，必须具有此权限才能将模板中的安全描述符以及其他目录对象合并起来，并进而为目录中存储的 PKI 配置对象授予正确的权限。在默认情况下，内置的域组 Administrators、Server Operators 以及 Backup Operators 具有此权限。通常，只有在林中安装第一个企业 CA 时才会用到此权限。对于要安装企业 CA 的每个域，需要重复此过程。

为 Enterprise PKI Admins 授予“还原”权限

重要信息：如果任何其他 GPO 在域控制器中设置了“还原文件和目录”用户权限，则必须对具有最高优先级的 GPO（而非“默认域控制器策略”）执行先前的过程。用户权限设置不是累计的，只有设置了此权限并且最后应用的 GPO（即具有最高优先级的 GPO）有效。

创建证书注册组

可以使用证书注册组，方便地控制哪些用户可以注册特定证书类型，或者哪些用户可以自动注册特定证书类型。您不必对证书模板的安全设置进行编辑，而只需在安全组中添加和删除用户或计算机，即可实现此目的。您也可以为某些管理人员委派这些组成员身份的控制权（这些管理人员无权直接编辑证书模板的属性）。您可能希望使用此过程，使程序所有者能够控制哪些用户可以注册特定的证书类型，而不必授予其修改模板本身的权限。

安全要求

具有 Enterprise PKI Admins 的成员身份（以更改证书模板的权限）以及在 OU 中创建所需安全组的权限

任务详细信息

为每个证书模板类型创建一个注册组，或至少为自动批准证书的所有证书模板类型创建一个注册组。在对证书类型使用显式注册过程的情况下，可能不需要使用此机制。如果要自动注册证书类型，可创建一个单独的组来控制哪些用户和设备自动注册该证书。

注意：您必须使用域全局组或通用组来设置模板权限，因为它们是在整个林中唯一可见的组类型。但是，全局组只能包含来自创建此组的域中的成员。要使用来自多个域的成员，请为每个域创建全局组（您可以在其中添加来自每个域的所需用户和计算机）和通用组以设置模板权限。然后，将全局组添加到通用组中。

为证书模板创建注册组

注意：您可以委派这些注册组的控制权，以使证书应用程序所有者能够指定哪些用户可以注册（和自动注册）此证书类型，而哪些用户不能进行注册（和自动注册）。

在 Web 服务器上设置 CRL 和证书发布权限

您必须在 IIS（或其他 Web 服务器）上创建一个虚拟目录，并将其作为 CA 证书 (AIA) 和 CRL 发布 (CDP) 的超文本传输协议 (HTTP) 位置。此任务专用于 IIS 6.0（在 Windows Server 2003 中），但也可对其进行修改以用于 IIS 早期版本及其他 Web 服务器。

安全要求

具有 Web 服务器的本地 Administrators 成员身份

任务详细信息

此任务创建虚拟目录，并为 Enterprise PKI Publishers 组和联机 CA 授予向此位置发布文件的权限。

创建 IIS 分发点

如果您要使用多个 IIS 服务器来发布 CRL 和 CA 证书（例如，您在不同的服务器上拥有内部和外部 PKI 发布点），则需要重复此任务。

配置颁发 CA 以将 CRL 发布到 Web 服务器

颁发 CA 通常会颁发 CRL（增量 CRL 为每日甚至每小时一次）。因此，找到一种方法将 CRL 自动发布到分发点 (CDP) 是非常重要的。企业 CA 自动将 CRL 发布到目录，而不是发布到 Web 服务器上的 HTTP CDP。但是，如果颁发 CA 和目标 Web 服务器之间存在连接，则可以将 CA 配置为自动直接发布到 Web 服务器。

注意：此方法不适用于直接发布到连接到 Internet 上的 Web 服务器，因为它需要直接连接并使用 CA 和 Web 服务器之间共享的服务器消息块 (SMB) 文件。要发布到 Internet 服务器，您可以使用此任务中描述的方法，先将内容发布到一个中间位置，然后再使用标准方法将其安全地发布到 Web 服务器。要记住，应考虑到这一额外步骤造成的延迟，它可能会降低 CRL 的时效性。

安全要求

具有 CA 的本地 Administrators 成员身份

任务详细信息

注意：出于打印考虑，其中的某些命令可能显示为多行，但实际应在单行输入。

自动发布 CRL

certutil.exe -setreg CA\CRLPublicationURLs "+65:file://\\pki.contoso.com\WWWPKIpub\%3%8%9.crl\n"

重要信息：如果 CA 无法访问目标 Web 服务器共享，它将禁止发布 CRL，并可能禁止将 CRL 发布到其他 CDP。（这将导致在 Windows 事件日志中记录一个事件。）如果无法保证 Web 服务器的可用性，您可以考虑使用计划任务将 CRL 从 CA 配置文件夹 (%systemroot%\system32\certenroll) 复制到目标位置，而不必执行此任务。

启用 CA 审核

有关设置 CA 审核的完整描述，请参见“相关链接”中的 Windows Server 2003 PKI Operations Guide。

安全要求

具有 CA Admins 组的成员身份

任务详细信息

启用 CA 审核

您还应考虑在下列位置启用文件系统和注册表审核，以便将未经授权对 CA 数据或配置信息进行的修改记录下来。

禁用对中间 CA 的吊销检查

CA 必须能够检查其自身证书以及它所颁发证书的吊销状态。虽然这对联机颁发 CA 是很有益处的，但会给脱机 CA 带来麻烦。因为它是脱机的，所以无法访问根 CA 的任何发布 CDP，也无法访问其自身的任何 CDP。这使 CA 无法启动和颁发证书。

此问题的一种解决办法是，将 CRL 从根 CA 及其自身发布到计算机的本地证书存储区。但是，这一过程非常麻烦，而且在大多数情况下，它不会明显地改善安全性能。（此吊销检查与联机用户执行的证书吊销检查没有任何关系。）

此处所使用的方法是，使 CA 停止执行这些强制的吊销检查。在 CDP 脱机的情况下，可通过将 CA 配置为跳过吊销检查来实现此目的。

注意：在 Windows Server 2003 Service Pack (SP) 1 以前，下列过程没有完全禁用吊销检查。尽管该过程可使 CA 跳过对它所颁发的证书的吊销检查，但它在启动时仍会对其自身的证书进行检查，因此需要从其父 CA 访问 CRL。SP1 版本以前的一个修复程序可以消除此缺陷。如果您无法更新 CA，则必须继续将根 CA CRL 发布到中间 CA 证书存储区。

安全要求

具有中间 CA 的本地 Administrators 成员身份

任务详细信息

禁用中间 CA 的吊销检查

Certutil.exe -setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

您可以使用下列命令撤消此更改。

Certutil.exe -setreg ca\CRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE

系统管理

系统管理包括与 CA 操作系统维护有关的任务。

配置操作系统更新

像大多数其他计算机一样，联机颁发 CA 也存在恶意软件或人员试图利用系统漏洞对其进行攻击的风险。要减少受到这些威胁的风险，找到一种及时为系统部署安全更新的方法是非常重要的。部署修补程序管理系统的内容已超出了本文的范围。有关实现此目的的其他方法的详细信息，请参见“相关链接”中的 Microsoft Solution Accelerator for Patch Management（Microsoft 修补程序管理解决方案加速器）。

只要不打算将脱机 CA 连接到网络（它们绝不应该连接到网络上），则不需要像联机系统那样始终保持最新。但是，最低限度您应该跟踪 Service Pack 和操作系统版本升级，使服务器始终以受支持的配置运行。本文还建议您定期安装安全更新，以使其始终保持最新。

表 12：安全更新摘要

重要信息：虽然操作系统更新已经过 Microsoft 的全面测试，但在系统中部署更新之前，您自己也一定要进行测试。您可使用单独的 SUS 服务器或单独的 SMS 目标组来控制 CA 的安全更新。您可能无法使用与其他系统相同的时间表来测试 CA 更新；有些更新可能并非针对 CA。

配置可用性和恢复选项

这一节中的任务旨在确保您的 PKI 具有良好的故障适应性，并使您能够迅速从可能遇到的故障中恢复。

为高可用性 PKI 进行规划

PKI 可用性的两个最重要的方面是：

如果注册服务中断，您将无法为用户颁发证书。这会影响到新用户以及现有证书即将到期的用户。Windows Server 2003 的默认设置是，在自动注册的证书到期前 6 周自动进行续订，因此实际上只有新用户会受到严重影响。您必须确定贵组织允许注册服务中断的最长时间，并相应地规划服务可用性和恢复措施。

无法访问证书吊销信息所带来的潜在影响会更加严重。如果当前吊销信息不可用，检查证书吊销状态的应用程序将会失败。这可能会影响组织内的所有用户。因此，必须采取适当措施，确保吊销信息始终可用。本文附带的监视脚本中包括了对到期、即将到期以及不可用 CRL 进行的专门检查。在“常见支持任务”中还给出了一种补救过程以延长 CRL 的有效期。有关吊销检查问题的详细信息，请参见“相关链接”中的文章 Troubleshooting Certificate Status and Revocation（证书状态和吊销疑难解答）。

在可用性计划过程中，应该特别注意以下方面。

配置颁发 CA 数据库备份

此任务的目的是备份 CA 私钥和证书、证书数据库以及证书服务配置信息的副本。证书服务配置信息包括 CA 依赖的所有操作系统配置和其他状态信息。备份这些项目的最佳方式是使用 Windows 系统状态备份。Windows Server 2003 提供的“Windows 备份”实用工具以及多种商业备份系统都支持此操作。您应与您的备份解决方案供应商进行核实，看其是否支持 Windows 系统状态备份或等效功能。

注意：如果您未使用 HSM 来保护 CA 密钥，则 CA 备份数据是高度机密的，因为它包含 CA 自身的私钥材料。（它可能还包含用户的存档私钥。）在传送和存储此数据时，要采取必要的安全措施，因为它与 CA 同等重要。在这种情况下，您可以考虑对 CA 使用单独的备份系统。

如果贵公司的备份系统不支持 Windows 系统状态备份，则可以使用“Windows 备份”将 CA 备份保存到一个文件中，然后再使用公司的备份系统保存该文件。在还原 CA 时，需要先将该备份文件还原到服务器，然后再使用“Windows 备份”从存档文件中还原 CA。

由于每天多次运行 CA 的完整备份通常是不切实际的，因此也可以每小时执行一次差异备份。它将复制数据库日志，其中记录自每日完整备份以来的所有事务。

安全要求

CA 的本地 Administrators。可以使用 CA 的“Local System”帐户来运行备份作业，但也可以使用不同的帐户来运行备份，只要它是 CA Backup Operators 组的成员即可。

任务详细信息

此任务配置一个计划作业，每夜对 CA 服务器进行备份。

注意：如果您使用 HSM，则此过程不适于备份受 HSM 保护的密钥。您可能需要备份某些受保护的 CA 密钥材料。但是，您还需要确保拥有相同的 HSM 和所需的 HSM 访问密钥，以备将来还原 CA 之需。按照 HSM 供应商的说明进行备份操作，或妥善保管好密钥材料和访问密钥。

配置 CA 的每日完整备份

要估算所需的时间，可在服务器开始颁发大量证书之前，在服务器上运行系统状态备份（启用验证功能）。在“证书服务”服务关闭的情况下运行备份。（这可防止此次测试备份操作截断 CA 日志。）它将备份大约 500 MB 的系统状态数据。记录此次操作的时间，并计算 CA 数据库外加系统状态备份大约花费的时间（如下所示）：

总时间 = 系统状态时间 x (500 + ((用户数 + 计算机数) x 证书数 x 20KB)) ÷ 500

此公式假定在最坏情形下（即每年为每个用户和每个计算机颁发 5 个证书），5 年后的总存储量。如果每个证书 20 KB，则每个用户每 5 年的存储量为 1 MB。在此公式中，如果单独备份系统状态所需的时间为 5 分钟，则对拥有 10,000 个用户的 CA 备份需要 105 分钟。（它将要备份包含 500,000 个证书的 10 GB 数据库。）

这只是一个粗略的指标。该时间并不是一成不变的，具体取决于用户和计算机数以及为每个用户和计算机颁发的证书数。

安全地存放备份媒体。将备份数据与 CA 本身存储到不同的地点。这样，在该地点的所有计算机设备损坏或无法访问时，仍可以对 CA 进行恢复。

差异备份保存自上次执行完整备份以来的所有信息。差异备份使用 certutil.exe 实用工具，将证书服务数据库日志文件复制到一个文件夹（每小时复制一次）。

配置每小时执行一次的 CA 数据库差异备份

cacls c:\CABackup /G system:F administrators:F "Backup Operators":C "CA Backup Operators":C

SCHTASKS /Create /RU system /SC daily /ST 01:00 /TN "CA Differential Backup" /TR "certutil -backupdb c:\CABackup incremental keeplog"
SCHTASKS /Create /RU system /SC daily /ST 02:00 /TN "CA Differential Backup" /TR "certutil -backupdb c:\CABackup incremental keeplog"
SCHTASKS /Create /RU system /SC daily /ST 03:00 /TN "CA Differential Backup" /TR "certutil -backupdb c:\CABackup incremental keeplog"
SCHTASKS /Create /RU system /SC daily /ST 04:00 /TN "CA Differential Backup" /TR "certutil -backupdb c:\CABackup incremental keeplog"

注意：在计划差异备份时，要避免其与完整备份的时间过于接近。使用前一过程中给出的计算方法，估计完整备份所需的时间，并随着 CA 数据库的增加监视此时间的变化情况，确保它不会与差异备份作业重叠。

配置脱机 CA 数据库备份

此任务的目的是准备备份时所需的 CA 私钥和证书、证书数据库以及证书服务配置信息。证书服务配置信息包括 CA 依赖的所有操作系统配置和其他状态信息。与颁发 CA 不同，脱机 CA 的备份过程是手动完成的。有关详细信息，请参见“备份脱机 CA”。

安全要求

具有 CA 的本地 Administrators 组成员身份

任务详细信息

通常情况下，根 CA 只颁发少量的证书，因此，CA 数据库肯定不会很大。数据也很少会发生变化；几个月甚至几年才会改变一次。任何其他脱机 CA 也是如此，如脱机中间 CA。

由于这些 CA 是脱机的，所以您需要一个本地备份设备（如磁带机或可写 CD 或 DVD 驱动器）来存储备份文件。如果您使用“Windows 备份”或其他能够对系统状态进行备份的系统，则可使用它直接备份到可移动媒体上。如果您选择的备份系统并不执行 Windows 系统状态备份，则应该使用“Windows 备份”将 CA 和操作系统备份到一个文件，然后将该文件备份到可移动媒体。

注意：如果使用的是 HSM，则此过程可能会备份加密密钥材料（取决于 HSM 的工作方式），但如果没有相同的 HSM 和 HSM 访问密钥，则在还原的计算机上无法使用备份的密钥。按照 HSM 供应商的说明妥善保管好密钥材料和访问密钥。

配置监视和警报

操作人员可通过服务监视来实时观察 IT 服务的状态。

这一节描述如何对系统监视工具集进行配置，以提供 PKI 的正确警报类型和状态信息。在本文中，假定您正在使用 Microsoft Operations Manager (MOM) 等系统监视工具，它可以根据事件日志条目生成警报。有关 MOM 部署的详细信息，请参见“相关链接”中的 Microsoft Operations Manager 2000 SP1 Deployment Guide（Microsoft Operations Manager 2000 SP1 部署指南）。

为监视警报分类

您的监视系统只应就非常严重的事件向操作人员发出警报。如果所有很小的错误都生成事件警报，那么操作人员将很难辨别出紧急事件。

任务详细信息

表 13 中的警报类别是一些常见警报分类级别的示例，MOM 默认使用这些类别。这些警报类别是按照重要程度由高到低排列的。在这些类别当中，只有前三个类别（服务不可用、违反安全规程以及严重错误）应在操作控制台生成警报以提醒操作员立即采取措施。错误和警告并不被视为紧急事件，但应向 PKI 操作支持人员咨询解决方案。

表 13：警报类别

监视服务可用性

除证书注册以外，CA 不直接向用户提供联机或实时服务。这与 Active Directory 或 Microsoft SQL Server 等应用程序不同，它们必须持续联机才能提供有用的服务。需要对 PKI 服务某些方面的可用性进行不间断的监视，以使 PKI 应用程序能够正常工作。

对于大多数应用程序而言，前两项要比后两项重要得多。

安全要求

MOM（或监视系统）管理员

任务详细信息

对证书服务而言，表 14 中的事件是最重要的。此表描述了各种事件类型的重要性，以及应为该事件分配哪种警报严重程度（用于操作控制台）。表 15 中列出的是检测这些事件的方法；大多数事件是使用本文附带的监视脚本进行检测的。

“严重程度”栏与先前在“为监控警报分类”过程中定义的“警报类别”有关。

表 14：评估证书服务事件的严重程度

您可以使用 CAmonitor.vbs 脚本来检查这些情况。可从 TechNet 脚本中心获取该脚本。（请参见“相关链接”）

在检测到任何错误时，该脚本就会将事件项写入 Windows 应用程序日志中。随后，MOM 代理或其他监视解决方案可将这些事件挑选出来。您需要设置一些筛选规则来检查表 15 中所列脚本生成的事件来源和事件 ID。该脚本可发送电子邮件来响应警报情况，并创建事件日志条目，也可只发送电子邮件而不创建事件日志条目。

该脚本只能在联机颁发 CA 上工作；不需要在脱机 CA 上运行它，也不需要从中获得什么好处。但是，该脚本确实可以自动检查父 CA（及父 CA 的父级，直至根 CA）的 CA 证书和 CRL 状态。该脚本必须在 CA 本身中运行，它并不是为远程执行检查而设计的。

重要信息：该脚本要求服务器中安装了 CAPICOM 2.0 或更高版本

如果使用了 MOM（或其他基于代理的监视系统），则应由 MOM 客户端代理执行该脚本。如果没有能够执行此操作的管理代理，可使用 Windows 任务计划程序来运行这些检查，每小时至少运行一次；可通过电子邮件发送警报，也可以使用事件日志监视工具。

表 15 中列出的是来自表 14 的事件，但这次要说明的是用来检测每种事件类型的 Windows 事件或其他指示器。此表列出了 CAMonitor.vbs 监视脚本生成的事件 ID 以及该脚本检测出来的各种问题。

表 15：证书服务监视脚本

CAMonitor.vbs 的语法如下：

cscript CAMonitor.vbs {/CAAlive | /CACertOK | /CACRLOK | /KRAOK} [/smtp /smtpserver:MyServer.Dom _ 
    /smtpto:"recip1@co.dom, recip2@co.dom"] [/noeventlog]

第一个参数表示要运行的一项或多项检查的类型（至少必须有一项，也可同时使用多项）。第二个参数指定将要发出 SMTP 电子邮件警报。如果使用此参数，则必须指定 SMTPServer 和 SMTPTo 参数。前者定义电子邮件服务器的主机名称或 IP 地址；后者则是将要接收此邮件的收件人列表（收件人之间以逗号分隔）。最后一个参数禁止将警报写入 Windows 事件日志。

此脚本旨在为您提供一个范例。我们鼓励用户对其进行修改和完善，以便更好地满足用户自己的需求。就其目前的形式而言，它还有一些局限性。

配置 CA 安全监视

证书服务可生成多种安全事件（审核）日志条目来响应不同的安全事件。大多数日志条目都是日常操作任务产生的结果。但是，某些事件指出进行了一些较大的配置更改，您可能需要做进一步的调查。后面的操作任务“检查审核日志中是否有安全事件”使用本过程中的预备工作，并且着重强调了一些需要引起注意的更严重的安全事件。

安全要求

具有 CA Auditors 的成员身份（检查安全日志）

为通过 MOM（或类似工具）进行监视而指定的安全监视帐户

任务详细信息

表 16 中列出了由证书服务生成的审核事件以及建议的警报分类（遵循在“为监控警报分类”过程中定义的分类）。对监视系统进行配置以查找这些事件，并提升相应的警报级别。或者，如果您没有集中的事件监视系统，可定期检查 CA 服务器安全日志（理想情况是每天一次）以检查这些项目。

“成功”审核事件的默认警报类别是信息。由于可能更改了 CA 安全配置而生成的任何“成功”事件均作为警告处理。所有警告级别的事件都属严重事件，在日常操作中通常不会出现此类事件。所有警告事件应与某一批准的更改申请相关联。如果没有此类关联，应将该事件视为可能违反了安全规程的事件，应立即对其进行调查。

通常，在日常操作或在对 CA 进行标准更改期间，不会出现“失败”审核事件。几乎所有此类事件都属严重事件，需要对其进行调查（尽管它可能只表示分配的权限不正确，而不是恶意攻击）。

注意：这也存在一些例外情况，如事件 792“证书服务拒绝证书申请”。当 Certificate Manager 合理拒绝某一申请时，既可以生成成功事件，也可以生成失败事件；但当没有足够权限的人员试图拒绝申请时，只会生成失败事件。

表 16 中列出的更多例外情况与您对 CA 进行配置更改时所采用的不同方式有关。如果使用“证书颁发机构”MMC 进行更改，则只记录事件 789（“更改审核筛选”）、795 和 796（“更改 CA 配置或属性”）。如果有人试图通过直接编辑 CA 注册表（或使用 certutil -setreg 命令）来更改 CA 配置值，则不会记录这些事件。

如果已启用注册表审核（如“启用 CA 审核”任务中所建议的一样），则将这些更改作为普通的事件 560“对象访问审核”项目记录下来。（请参见表 16 中的最后一项。）应该为 CA 注册表配置子项启用审核，并记录成功的更改以及所有失败的访问。要跟踪对 CA 注册表项所做的更改，可结合使用审核事件的“对象名”参数以及“事件 ID”和“事件类型”，创建一个筛选器来生成正确的警报。

除了审核证书服务事件以外，您还必须监视和生成有关标准操作系统安全事件的警报，如登录事件、权限使用以及对象访问等。应该对 CA 注册表和数据库以及日志目录进行配置，为所有失败的访问和任何成功的更改生成安全审核事件。此外，还要考虑在公钥服务容器（在“配置\服务”中）和 PKI 管理组中设置审核，但要注意，来自目录对象的审核事件将被记录到进行访问操作的域控制器的安全事件日志中。将不同域控制器中的这些种类的事件关联起来是一项复杂的任务。如果您有合并和筛选这些日志的工具（如 MOM），则可在所有 Active Directory PKI 配置对象和容器以及 PKI 管理组中启用审核。

注意：有关对运行 CA 的 Windows 操作系统进行安全监视的内容超出了本文的范围，它可能包括对来自专门的入侵检测代理的安全事件进行处理。如果其中的任何来源表明有违反安全规程的情况，应结合这些来源的输出对证书颁发机构审核事件进行彻底调查。

表 16 中列出的“成功和失败警报类别”与“为监控警报分类”过程中定义的警报类别相关。应在当天对所有“错误”和“警告”类别的警报进行调查，以确保其都有合理的原因。“信息”事件不需要进行调查，可继续将其作为常规 PKI 操作的审核记录。有少量的安全事件是特别严重的事件。“检查审核日志中是否有安全事件”操作过程中已着重强调了这些事件。

表 16：证书服务审核事件

计算潜在的 CA 容量限制

检测潜在的容量限制对于将服务保持在最佳水平至关重要。随着子系统逐渐接近其操作容量限制，性能会急剧下降（通常是非线性的）。因此，对容量趋势进行监视并及早发现和处理将来的限制趋势是一项非常重要的任务。

安全要求

使用的性能监视解决方案指出了所需的权限。

任务详细信息

下列性能计数器对确定证书服务中的容量限制非常有用。处理器和磁盘是证书服务使用最频繁的两种资源，因此它们比网络和内存更早地指出容量限制。

表 17：用于证书服务的重要容量监视计数器

有关容量限制和相关性能计数器的更一般性的信息，请参见“相关链接”。

在所有支持的结构中对容量指示器进行监视也很重要。重要的项目有：

为挂起的证书申请配置简单邮件传输协议 (SMTP) 警报

如果您将某些证书类型配置为需要 Certificate Manager 批准，它们将继续在“挂起的申请”文件夹（属于“证书颁发机构”MMC）中排队，直到申请被批准或被拒绝。您可能希望进行配置，以便在每次有申请排队时都发送电子邮件警报。自动批准的申请不会发送电子邮件警报。

也可以为其他 CA 事件配置电子邮件警报。证书服务联机帮助讲述了如何配置这些事件，Windows Server 2003 PKI Operations Guide 的“Configuring the "SMTP Exit Module"”（配置“SMTP 退出模块”）一节中包括一个详细的示例脚本。（请参见“相关链接”）

频率

设置任务

安全要求

具有 CA Admins 的成员身份

任务详细信息

为挂起证书申请启用电子邮件警报

certutil –f -setreg exit\smtp\SMTPServer mail.contoso.com
certutil –f -setreg exit\smtp\SMTPAuthenticate 0
certutil –f -setreg exit\smtp\eventfilter +EXITEVENT_CERTPENDING

certutil –f -setreg exit\smtp\Pending\To "Admin@contoso.com, PKIOps@contoso.com"
certutil –f -setreg exit\smtp\Pending\From "%COMPUTERNAME%@USERDNSDOMAIN%"
certutil –f -setreg exit\smtp\Pending\titleformat "A certificate is pending on %1"

certutil –f -setreg exit\smtp\Pending\BodyArg +"Request.RequestID"
certutil –f -setreg exit\smtp\Pending\BodyArg +"UPN"
certutil –f -setreg exit\smtp\Pending\BodyArg +"Request.RequesterName"
certutil –f -setreg exit\smtp\Pending\BodyArg +"Request.SubmittedWhen"
certutil –f -setreg exit\smtp\Pending\BodyArg +"Request.DistinguishedName"
certutil –f -setreg exit\smtp\Pending\BodyArg +"CertificateTemplate"
certutil –f -setreg exit\smtp\Pending\BodyArg +"Request.DispositionMessage"
certutil –f -setreg exit\smtp\Pending\BodyArg +"EMail"
Certutil –f -setreg exit\smtp\Pending\BodyFormat +"Request ID: %1"
Certutil –f -setreg exit\smtp\Pending\BodyFormat +"UPN: %2"
Certutil –f -setreg exit\smtp\Pending\BodyFormat +"Requester Name: %3"
Certutil –f -setreg exit\smtp\Pending\BodyFormat +"Time submitted: %4"
Certutil –f -setreg exit\smtp\Pending\BodyFormat +"Distinguished Name: %5"
Certutil –f -setreg exit\smtp\Pending\BodyFormat +"Certificate Template used: %6"
Certutil –f -setreg exit\smtp\Pending\BodyFormat +"Request Disposition Message: %7"
Certutil –f -setreg exit\smtp\Pending\BodyFormat +"Requester Email: %8"

监视客户证书是否到期

监视单个客户的证书是否到期通常不适用于客户数量很大的情况。但是，您需要确保证书续订没有被遗漏。有多个选项可供使用。

作业计划

在 MOF 过程模型中，作业计划是指对作业和过程进行编排以形成一个高效的序列，使系统达到最大的吞吐量和利用率。此处的目标是类似的，但是更简单一些。为了避免作业之间发生潜在的冲突，记录下系统中运行的所有自动作业的时间是至关重要的。可通过 Windows 任务计划程序、管理代理或其他应用程序和服务（如病毒扫描程序）对作业进行计划。

安排联机 CA 上的作业

需要在 CA 上运行许多重复性的任务，以保持 PKI 的平稳运行。这些任务都是自动运行的，以便减少操作负担。

安全要求

CA 的本地 Administrators

任务详细信息

表 18 中列出的是颁发 CA 上运行的一些自动作业。这些作业是在本文其他地方的任务中定义的（如“引用的任务”一栏所示），此表仅供参考。

只有颁发 CA 运行自动作业。脱机 CA 可能会长时间关机，因此无法在这台计算机中进行可靠的时间安排。

表 18：颁发 CA 上的计划作业列表

返回页首

操作 PKI

这一节描述的是保持 PKI 运行所需的维护任务。其中的很多任务有明确的时间安排，而其他一些任务则是根据需要来执行。这一节中的任务与 MOF 过程模型“操作”部分相对应。

操作任务清单

安全管理

监视

CA 数据库和设置管理

安全管理

安全管理涵盖与 IT 结构的安全组件有关的任务。

为用户或计算机启用证书类型的注册（或自动注册）

此任务使用注册安全组，以便为用户、计算机或包含用户和/或计算机的安全组手动注册证书类型或启动自动注册。

注意：还必须在 GPO 中为目标用户或计算机启用了自动注册。有关详细信息，请参见 Windows Server 2003 产品文档的“证书服务示例实现：设置用户证书的自动注册”主题中的“制订 Domain Users 的自动注册策略”过程。

频率

根据需要

安全要求

修改证书注册组成员的权限

任务详细信息

为用户或计算机启用注册或自动注册

为用户或计算机禁用证书类型的注册（或自动注册）

如果为用户或计算机颁发证书，通常就会为证书所有者启用某些功能；您可能需要随后吊销此功能。

频率

根据需要

安全要求

具有修改证书注册组成员身份的权限

任务详细信息

为用户或计算机禁用注册或自动注册

注意：对于每个要禁用的证书用户，您还需要吊销该用户的证书。要吊销最终实体证书，请参见 Windows Server 2003 产品文档中的“吊销已颁发的证书”过程。

检查和批准挂起的证书申请

可以随时将证书申请提交到颁发 CA。使用 Active Directory 作为 RA 或使用指定 RA 中的预定义签名集，可自动颁发大多数的证书。如果将任何证书类型设置为需要 Certificate Manager 手动批准，则这些申请将会一直排队等候，直到被 Certificate Manager 批准或拒绝为止。

频率

每日一次

安全要求

具有 Cert Managers 的成员身份

任务详细信息

每天对申请文件夹进行检查，看是否有排队的申请。颁发证书前，应对申请仔细进行检查，确保申请者和申请内容都正确无误。验证使用者名称、使用者备用名称、密钥用法、策略以及扩展均与预期保持一致。如果有任何怀疑，则不要批准该申请。

您也可以对 CA 进行配置，使其针对不同的事件发送电子邮件警报。挂起申请到达即属于其中的一种事件。请参见“为挂起的证书申请配置简单邮件传输协议 (SMTP) 警报”过程。

检查挂起的申请

吊销最终实体证书

可能由于多种原因而需要吊销证书，如：

频率

根据需要

安全要求

具有颁发 CA 的 Cert Managers 成员身份

任务详细信息

有关吊销最终实体证书使用（即，颁发给 CA 以外任何对象的证书）的过程，请参见 Windows Server 2003 产品文档中的“吊销颁发的证书”过程。要吊销 CA 证书，请遵循“支持任务”中的过程。

注意：要避免使用“证书保留”吊销原因代码。虽然以后重新启用证书是一个不错的想法，但是将证书永久吊销然后再颁发一个新证书会更简单，更能减少混淆。

如果您试图吊销已不在证书数据库中的证书，请参见“吊销孤立证书”中的任务。如果 CA 数据库很大，则“证书颁发机构”MMC 的性能可能会较差，致使查找要吊销的证书这一过程变慢。在这种情况下，使用 certutil.exe 来执行吊销任务通常会更快一些。

吊销存档的私钥

加密证书的私钥可以存档在 CA 数据库中。通过在证书模板中选择相应选项，可为特定证书类型启用密钥存档。如果用户无法访问其私钥，并且该密钥已存档，则可以恢复该密钥，并将其以受密码保护的 PKCS#12 文件的形式返给用户。

频率

根据需要

安全要求

您需要具有 CA Admins 的成员身份以从 CA 数据库中提取存档的密钥，并拥有 KRA 证书（和私钥）来解密存档的密钥

任务详细信息

有关如何使用命令行和密钥恢复工具来恢复已存档私钥的详细过程，请参见“相关链接”中的“Key Archival and Management in Windows Server 2003”（Windows Server 2003 中的密钥存档和管理）。

重要信息：为防止滥用权力，应该将从数据库中提取加密密钥与解密提取的密钥这两种职责分开。

密钥恢复过程并不会强制规定如何为用户还原密钥。例如，即使原密钥的证书模板强制将密钥存储在智能卡上，也没有类似的方法防止将恢复的 PKCS#12 还原到软件 CryptoAPI 密钥存储区中。为防止意外降低密钥的安全性，您可能需要采用一种手动过程来获得更高安全保证的密钥。例如，可将恢复的密钥发送给受信任的代理（用户向此代理提供其智能卡），然后再还原密钥并销毁 PKCS#12 文件。

续订 CA 证书

您必须定期续订 CA 证书，以允许最终实体和从属 CA（如果有）继续使用此 CA 注册证书。CA 及其从属 CA 颁发的证书的到期日期不能晚于此 CA 证书的到期日期。另外，还有一些其他原因，导致在正常续订日期之前续订 CA 证书。对于联机 CA 而言，最常见的原因是为了：

每次续订时，务必 更改 CA 密钥。

频率

根 CA 为每 8 年一次

中间 CA 为每 4 年一次

颁发 CA 为每 2 年一次（如果您要续订以分割 CRL，您可能会决定更频繁地执行此操作，例如每年或每 6 个月一次。）

安全要求

具有被续订 CA 的本地 Administrators 的成员身份、父 CA（仅限颁发 CA 和中间 CA）的 Cert Managers 成员身份、域中 Enterprise PKI Admins 的成员身份

任务详细信息

CA 层次结构的每个级别都具有 CA 证书有效期，其长度是它下一级的二倍；在 MSA 方案中，根 CA 的有效期为 16 年，中间 CA 为 8 年，颁发 CA 为 4 年。各个 CA 需要在有效期过半后进行续订。此情况如图 1 中所示。如果 CA 在其有效期一半时未进行续订，则会限制该 CA 及其从属 CA 颁发的证书的最长有效期。

图 1：CA 级别层次结构

如图 1 所示，如果颁发 CA (CA111) 未续订其证书 (Cert 2)，则它无法颁发完整有效期为 2 年的最终实体证书（第 5 年的 EE Cert 2）。它所能颁发的证书的有效期最长为颁发 CA 证书 Cert 2 的到期日期（第 6 年）。如果续订 CA 证书 (Cert 3)，则它可以向用户颁发完整有效期长度的证书。在图 1 中，您还会注意到 CA 层次结构各个级别的续订点都是对齐的；这可使续订任务更易于管理。

贵组织中的 CA 续订任务列表与表 19 类似。

表 19：续订任务列表

有关续订根 CA 证书的过程，请参见“相关链接”中的 Windows Server 2003 证书服务产品文档中的文章“Renew a Root Certification Authority”（续订根证书颁发机构）。在续订 CA 的过程中，还必须执行大量的辅助任务。

图 2：在根 CA 续订期间根 CA 与其他系统的交互

续订根 CA

有关续订中间 CA 证书的过程，请参见“相关链接”中的证书服务产品文档中的文章“Renew a Subordinate Certification Authority”（续订从属证书颁发机构）。（根据选项“如果没有联机的父 CA”。）

图 3：续订中间 CA 期间的交互

续订中间 CA

有关续订颁发 CA 证书的过程，请参见证书服务产品文档中的文章“Renew a Subordinate Certification Authority”。（根据选项“如果没有联机的父 CA”。）颁发 CA 续订期间的交互如图 4 所示。

图 4：续订颁发 CA

其中只显示了与一个颁发 CA 的交互。这些流程对每个颁发 CA 都是相同的。

在续订联机 CA 期间，自动将其新证书和 CRL 发布到目录中。此时假设 CA 是一个企业 CA，此独立的 CA 并不一定会自动发布到目录中。您应使用“配置颁发 CA 以将 CRL 发布到 Web 服务器”过程，将 CA 配置为自动将 CRL 发布到 Web 服务器。唯一需要完成的手动任务是将 CA 证书发布到 Web 服务器。

对于所有 CA，在整个续订周期完成后，应对 CA 数据库进行备份。

发布脱机根 CA 证书

您必须将脱机根 CA 的证书发布到：

此过程假定已使用与 Web 服务器发布点对应的 AIA 位置配置了 CA。有关如何进行配置的详细信息，请参见“相关链接”中的 Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure 和 Microsoft Systems Architecture version 2.0 Implementation Kit 中的证书服务建立指南。

频率

这些过程只作为根 CA 续订的一部分来使用。（请参见“续订 CA 证书”。）

安全要求

具有 CA 的本地 Administrators 成员身份或 Enterprise PKI Publishers 成员身份

任务详细信息

将脱机根 CA 证书发布到 Active Directory

Copy %systemroot%\system32\certsrv\certenroll\*.crt d:\path

For %i in (d:\path\*.crt) do Certutil –f –dspublish %i RootCA

For %i in (d:\path\*.crt) do certutil –f –addstore Root %i

copy d:\path\*.crt \\WebServerName\WWWPKIpub

将中间 CA 证书发布到 Web 服务器

您必须手动将脱机中间 CA 的证书发布到 Web 服务器 AIA 发布点，以使证书用户可以获取 CA 证书来帮助建立链。企业 CA 自动将其 CA 发布到目录中。

此过程假定已使用与 Web 服务器发布点对应的 AIA 位置配置了 CA。有关如何进行配置的详细信息，请参见“相关链接”中的 Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure 和 Microsoft Systems Architecture version 2.0 Implementation Kit 中的证书服务建立指南。

频率

这些过程只作为 CA 续订的一部分来使用。（请参见“续订 CA 证书”。）

安全要求

具有 CA 的本地 Administrators 成员身份或 Enterprise PKI Publishers 成员身份

任务详细信息

将 CA 证书发布到 Web 服务器

Copy %systemroot%\system32\certsrv\certenroll\*.crt d:\path

copy d:\path\*.crt \\WebServerName\WWWPKIpub

将颁发 CA 证书发布到 Web 服务器

必须将颁发 CA 证书发布到 HTTP（超文本传输协议）AIA 位置，以使证书用户（尤其是非域客户）可以建立一个从最终实体证书到受信任的根 CA 的信任链。

此过程假定已使用与 Web 服务器发布点对应的 CDP 位置颁发了 CA。有关如何进行配置的详细信息，请参见“相关链接”中的 Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure 和 Microsoft Systems Architecture version 2.0 Implementation Kit 中的证书服务建立指南。

频率

对于颁发 CA，每 2 年执行一次此任务，但只需作为该 CA 证书续订的一部分来执行。（请参见“续订 CA 证书”。）

安全要求

具有 Enterprise PKI Publishers 的成员身份

任务详细信息

CA 证书很少需要更新，因此每次在续订 CA 证书后，将其手动发布到 AIA 并不麻烦。

将颁发 CA 的证书发布到 Web 服务器

Copy %systemroot%\system32\certsrv\certenroll\*.crt \\WebServerName\WWWPKIpub

将脱机 CA 的 CRL 发布到 Web 服务器

必须将脱机 CA 的 CRL 发布到 Web 位置，以使证书用户可以检查整个 CA 链的吊销状态。一个 CA 可以发布两个或更多 CRL，具体取决于 CA 证书的续订次数。您必须发布当前的所有 CRL。

此过程假定已使用与 Web 服务器发布点对应的 CDP 位置颁发了 CA。有关如何进行配置的详细信息，请参见“相关链接”中的 Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure 和 Microsoft Systems Architecture version 2.0 Implementation Kit 中的证书服务建立指南。

频率

根 CA 为每 6 个月一次；中间 CA 为每 3 个月一次

安全要求

具有 CA 的本地 Administrators 成员身份或 Enterprise PKI Publishers 成员身份

任务详细信息

将脱机 CRL 发布到 Active Directory

Copy %systemroot%\system32\certsrv\certenroll\*.crl d:\path

copy d:\path\*.crl \\WebServerName\WWWPKIpub

将根 CA 的 CRL 发布到脱机中间 CA

Windows Server 2003 Service Pack 1 之前的版本需要使用此过程，在这些版本中，您已选择禁用对 CA 的吊销检查。（请参见“禁用对中间 CA 的吊销检查”。）

您必须将根 CA 的 CRL 发布到每个脱机从属 CA 的本地证书存储区。由于这些 CA 是脱机的，因此，它们无法访问根 CA 发布的 CDP 位置，并且无法检查其自身证书的吊销状态。这将使其无法启动。

频率

每 6 个月一次（每次从根 CA 发布新的 CRL 时）

安全要求

具有根 CA 和中间 CA 的本地 Administrators 成员身份

任务详细信息

将根 CA CRL 发布到 Active Directory

Copy %systemroot%\system32\certsrv\certenroll\*.crl d:\path

For %i in (d:\path\*.crl) do certutil –addstore –f Root %i

强制颁发联机 CRL

联机企业 CA 的 CRL 是自动颁发和发布的；通常情况下不需要强制颁发联机 CRL。但是，如果出现严重的吊销情况（如 CA 颁发的所有证书），并且需要在尽可能短的时间内发布新的 CRL，则可能必须执行此操作。

注意：无法向客户发布新的 CRL；他们将保留其现有的缓存副本，直到这些 CRL 到期为止。但是，强制发布新的 CRL 可确保此时申请 CRL 的任何客户都会收到新的 CRL（如果不考虑传播延时）。

频率

根据需要

安全要求

具有 CA 的本地 Administrators 成员身份

任务详细信息

将脱机 CA CRL 颁发和发布到 Active Directory

监视

这一节包含监视 PKI 所需的一些过程。这些过程描述了一些特殊的计划任务（如运行审核），而不是讲述如何针对警报和错误情况执行日常监视任务。假定对 PKI 的运行状态和性能进行监视。

检查审核日志中是否有安全事件

您应定期检查 CA 的审核日志，尤其是联机 CA。如果记录的事件与 CA 中应该发生的事件的记录不相符，则可能表明存在安全问题。

频率

CA 为每周一次；脱机 CA 为每 3 个月一次

安全要求

具有 CA 的 CA Auditors 成员身份

任务详细信息

检查每个 CA 的安全事件日志中的所有严重事件，查看是否存在意外事件。表 20 中列出了需要监视的一些重要项目。（要查看证书服务生成的安全事件的完整列表，请参见“配置 CA 安全监视”和 Windows Server 2003 PKI Operations Guide 以了解有关这些事件的详细信息。）

表 20：严重安全事件

如果任何项目与更改控制记录不符，应立即进行调查。既要调查失败事件，也要调查成功事件，因为它们都有可能会指出危及安全的企图。您可能决定创建由其中的某些事件触发的警报，并将其在操作监视控制台上标记出来。例如，如果您不希望在标准事件过程中更改 CA 审核策略，则可以对操作监视系统进行配置，使其在 CA 中记录事件 ID 789 时触发警报。

审核 PKI

应定期对您的 PKI 进行审核以确保其按预期的方式工作。尽管前一项任务（检查审核日志中是否有安全事件）可能会成为此审核的一部分，但不应将二者混为一谈。审核旨在确认系统正在按照所实施的策略和准则运行，并找出所有与该策略不相符的情况。

但是，此任务并非旨在取代法律或规章制度方面的审核要求。如果要求您遵守外部审核标准，则应咨询您的审核员或其他合格的专业人员并听取他们的建议。

频率

每年一次（频率可能会发生变化，具体取决于规章制度要求、组织特定的标准及其他因素。）

安全要求

可能需要具有 CA 的 CA Auditors 和本地 Administrators 成员身份，以及域中 Enterprise PKI Admins 的成员身份。

任务详细信息

审核信息安全系统是一门专业学科，本文无法深入地探讨这一主题。但是，下面的列表详细说明了 PKI 审核应该包括的一些内容。

检查性能和容量数据

应定期对容量变化趋势进行检查，确保 CA 不会出现资源不足的情况。这只适用于颁发 CA，对于频繁使用的 CA 尤为重要。

频率

每年一次

安全要求

具有 CA 的本地 Administrators 成员身份

任务详细信息

尽管运行监视警报会在资源（如磁盘空间或内存）接近容量极限时发出警告，但时常会出现收不到足够警告信息的情况，致使您无法正确地对容量需求进行规划。因此，您应定期检查 CA 的容量变化趋势。有关容量规划的深入介绍已超出了本文的范围。如果贵组织中有容量规划方面的专业资料，应利用它来帮助您对 CA 的资源需求进行管理。

下列准则非常有用。

CA 数据库和设置管理

这一节介绍存储管理任务，如执行备份、测试备份以及存档日志。

备份脱机 CA

此任务的目的是创建 CA 私钥和证书、证书数据库以及证书服务配置信息的备份副本。证书服务配置信息包括 CA 依赖的所有操作系统配置和其他状态信息。

频率

每次颁发新的（从属 CA）证书或吊销证书时

安全要求

具有 CA Backup Operators 的成员身份

任务详细信息

通常情况下，脱机 CA 只颁发少量的证书，因此数据量肯定不会很大。数据也很少会发生变化，有可能几年才会改变一次。脱机 CA 还需要某种本地备份设备，如磁带机或可写 CA。

注意：如果使用的是 HSM，则此过程可能会备份加密密钥材料（取决于 HSM 的工作方式），但如果没有相同的 HSM 和 HSM 访问密钥，则在还原的计算机上无法使用备份的密钥。按照 HSM 供应商的说明进行备份操作，并且妥善保管好密钥材料和访问密钥。

备份脱机 CA

ntbackup backup systemstate /R:yes /F C:\CABackup\CABackup.bkf /J "CA Full Backup" /L:s /V:yes

ntbackup backup systemstate /R:yes /t "CA Backup /J "CA Full Backup" /L:s /V:yes

注意：此备份数据是高度机密的，因为它包含 CA 自身的私钥材料（如果您未使用 HSM）。在传送和存储此数据时，要采取必要的安全措施，因为它与 CA 同等重要。将备份数据与 CA 本身存储到不同的地点。这样，在该地点的所有计算机设备损坏或无法访问时，仍可以对 CA 进行恢复。

备份 CA 密钥和证书

除了备份证书数据库外，还要单独备份 CA 证书和密钥。在 CA 服务器出现故障且短期内无法恢复的情况下，可能需要使用 CA 私钥和证书来签署 CRL 或证书。

频率

每年一次或每次续订 CA 证书时，取两者较早的时间

安全要求

具有 CA Backup Operators 的成员身份

任务详细信息

CA 密钥和证书只占用几 KB 的存储空间，因此可以将其保存到磁盘中。此任务适用于组织中的根 CA、任何和全部中间 CA 以及颁发 CA。如果要将密钥备份到长期存储媒体（如 CD 或 DVD），则无需每年都进行备份。如果使用磁性媒体（如软盘或磁带），则每年都应备份密钥和证书，而且在每次续订 CA 证书后也应进行备份。随着时间的推移，磁性媒体中记录的信号会逐渐减弱，尤其是暴露在电磁场中。尽管可能要经过许多年后，信号才会减弱到无法辨认的程度，但最好还是要防患于未然。

注意：如果使用的是 HSM，此过程可能不会按预期方式工作。按照 HSM 供应商的说明进行备份操作，并且妥善保管好密钥材料和访问密钥。

将证书和密钥导出到磁盘

certutil -backupKey -p Password TargetFolder

测试 CA 数据库备份

此过程将对 CA 备份进行测试，以确保备份过程和方法均正确无误。您只能将 CA 还原到一台与 CA 同样可靠的计算机上。例如，不要将脱机根 CA 还原到一台联机计算机上。用于测试还原的计算机必须在物理上是安全的，在理想情况下应是永久脱机的。

频率

在 CA 投入使用前，联机 CA 每 3 个月一次，脱机 CA 为每年一次；只要备份方法或过程发生变化，就需要重新进行测试

安全要求

具有测试计算机上的本地 Administrators 或 Backup Operators 的成员身份

任务详细信息

必须将系统状态备份还原到具有相同磁盘布局的系统中。例如，必须将 Windows 安装在与备份系统相同的目录路径下，并使用相同的驱动器布局来存储 Windows 文件（如页面文件）。CA 数据库和日志必须与备份的源 CA 相同。

警告：从开始进行系统状态还原起，用于还原的测试服务器应始终保持脱机状态。这是为了防止不必要地泄露还原的 CA 密钥，它还可以避免测试服务器和原始服务器之间出现重复名称和 IP 地址冲突现象。在任何情况下，都不能在测试时将脱机 CA 还原到联机服务器。

重要信息：如果使用的是 HSM，则此过程无法完全还原 CA。取决于 HSM 的工作方式，如果没有相同的 HSM 和 HSM 访问密钥，还原的计算机将无法工作。这可能不会对常规测试产生影响，但您应定期使用 HSM 恢复执行完全还原，以确保您的过程和备份方法都正常无误。按照 HSM 供应商的说明进行备份和还原操作，并且妥善保管好密钥材料和访问密钥。

还原 CA

重要信息：如果您选择只删除密钥（而不是清除服务器），请运行 cipher 命令来清除磁盘中未分配的部分。

Cipher /W:%AllUsersProfile%

要执行此操作，必须是本地 Administrators 组的成员。应使用 %allusersprofile% 路径，以便在存放密钥材料的驱动器上执行 cipher 命令。如果使用的是 HSM，则无需执行此操作。

测试 CA 密钥备份

定期检查 CA 密钥备份，确保其有效以备不时之需。

频率

对于颁发 CA 为每 6 个月一次；对于脱机 CA 为每年一次

安全要求

具有测试计算机上的本地 Administrators 成员身份

任务详细信息

您可以在任何系统中安装 CA 密钥和证书（但考虑到这些密钥的高度机密性，此系统应是物理安全的并且处于脱机状态）。为确保将密钥材料的所有痕迹从计算机中彻底清除，可在计算机上创建一个单独的临时本地用户帐户（专用于此目的）。

注意：如果使用的是 HSM，此过程可能无法工作。按照 HSM 供应商的说明进行备份和还原操作，并且妥善保管好密钥材料和访问密钥。

还原 CA 密钥

对于当前的每个 CA 密钥和证书，重复此过程。

测试还原的密钥

Certutil -sign CRLFileName.crl NewCRL.crl
Certutil -sign CertFileName.cer NewCertFile.cer

C:\>certutil -sign "Contoso Issuing CA 111.crl" "Contoso Issuing CA 111xxs.crl"
ThisUpdate: 2/10/2003 10:52 PM
NextUpdate: 2/25/2003 3:11 PM
CRL Entries: 0
Signing certificate Subject:
CN=Contoso Issuing CA 111
DC=contoso, DC=com
Output Length = 970
CertUtil: -sign command completed successfully.

对于要测试的每个 CA 密钥和证书，重复此过程（使用该密钥签署的 CRL 或证书）。

现在，您必须将密钥从测试系统中清除。

将密钥从系统中清除

Cipher /W:%AllUsersProfile%

注意：可指定 %allusersprofile% 作为路径，确保 cipher.exe 命令在保存用户配置文件的驱动器上执行。此命令清除整个驱动器，而不是只清除指定的路径。

存档 CA 中的安全审核数据

应依照法律或规章制度要求或者内部安全策略，存档和存储审核日志。如果您拥有审核事件合并系统（如 MOM 或 Windows 审核收集系统），则可能您已经掌握了自动收集和存档审核日志的方法。有关如何配置系统以实现此功能的信息，请参见该文档。

频率

对于颁发 CA 为每月一次；对于根 CA 和中间 CA 为每 6 个月一次

安全要求

具有 CA 的 CA Auditors 和本地 Administrators 的成员身份

任务详细信息

存档安全事件日志

返回页首

容量规划和优化

容量管理是指规划、调整以及控制服务解决方案容量的过程，以使其在事先约定的性能级别满足用户的需求。这一节中的这些任务与 MOF 过程模型中的“优化”部分相对应。

确定颁发 CA 的最大负载

这一节提供了有关计算颁发 CA 的最大负载的信息。

尽管 CA 通常很少会遇到高负载的情况，但有些时候负载可能会急剧升高。通常，CA 最高负载出现在登录高峰时，或首次部署新证书类型时的开始一段时期内。类似地，如果发生大量的证书吊销或 CA 证书吊销情况（尽管这种情况非常罕见），用户和计算机重新注册时也会出现反常的负载高峰。

任务详细信息

Microsoft 的内部测试表明，对于典型的企业 CA，在高负载情况下出现的性能瓶颈都是由于与 Active Directory 的交互造成的。与执行目录查找以检索证书主题信息并可能再将证书发布到 Active Directory 的任务相比，签署和颁发证书的工作要相对轻松得多。

在典型的高负载方案中，已启用了一种新的证书类型，所有用户和计算机都需要注册此类型的证书。

10,000 个用户和 10,000 台计算机最少需要 11 分钟才能完成注册。

重要信息：如果还需要将颁发的证书发布到目录（这不是默认行为，通常只有电子邮件加密证书需要执行此操作），则最大颁发速度会降为每秒钟 15 个证书，这样，特定证书类型的总注册时间就会加倍。

您可以使用这些数字来确定组织中可能出现的最大高峰注册负载，然后计算总的注册时间。如果时间太长而令人无法接受，而且无论如何都无法将注册时间错开，请考虑部署其他的颁发 CA 来分散负载。应将这些 CA 部署到不同的 Active Directory 站点，以使其使用单独的域控制器。

确定颁发 CA 的存储和备份要求

您可以通过执行此任务，来计算联机磁盘和脱机备份存储的将来存储要求。对于较大的安装而言，提供足够的存储空间和性能是 Windows CA 面临的一个最大的容量管理难题。

任务详细信息

在本任务中给出的容量数字均基于下列假设。

表 21 中列出了相同规模组织的预期容量值。某些峰值数字表示最坏或接近最坏的情况，即所有用户在同一天内自动注册同一类证书。可通过调整证书注册的持续时间来改善这些峰值。

表 21：关于存储和备份的容量值

也可以通过 CA 数据库和数据库日志大小，了解完整备份和差异备份的存储需求。在“配置颁发 CA 数据库备份”任务中，提供了执行备份所需时间的示例计算。

返回页首

管理更改和配置

管理 IT 结构中的更改是至关重要的。管理更改是指，完成规划和准备、记录以及最终发布更改这一可控的循环过程。完成这一循环过程有助于最大程度地减少更改在客观上对您的环境造成的影响，并且您还可以在需要时方便地撤消更改。在配置管理数据库中记录对 PKI 所做的更改，有助于使环境始终处于已知的状态。

这一节涉及三个功能。在“更改”部分的 MOF 过程模型文档中，更全面地介绍了这些功能。

更改和版本管理

更改管理

更改管理对任何 IT 环境的平稳运行至关重要。通常，将更改定义为以某种重要方式来改变 IT 环境的行为，例如，部署新的证书类型，升级操作系统或收回 CA。另一方面，执行计划备份等操作尽管在技术上改变了环境，但通常并不认为它们属于此处所说的更改。有一些项目还存在着一些争议，例如，可将向域中添加用户帐户视为一个日常操作，但为某一帐户授予管理权限几乎毫无疑问要完成更改管理过程。

更改管理过程的主要目标是，确保受到特定更改影响的所有各方都知道将要发生的更改，并且了解更改将会产生的影响。由于 IT 系统之间经常是密切相关的，对系统的一个部分所做的任何更改都可能会对其他部分造成极大的影响。为了减少或消除任何不利的影响，更改管理过程尽量在更改部署之前找出所有将会受到影响的系统和进程。通常，“目标”或受管理的环境是指生产环境，但它也应该包括重要的集成、测试及临时环境。

对 PKI 的所有更改都应遵循标准的 MOF 更改管理过程，如下所述：

版本管理

版本管理的重点是便于将软件和硬件版本引入到受管理的 IT 环境中。通常，这包括生产环境和受管理的生产前的准备环境。版本管理是版本开发/项目团队和负责在生产中部署版本的操作组之间的协调点。

版本管理负责下列事项：

对 PKI 所做的重大更改

下面是一些可能需要对 PKI 所做的更改，它们应遵循正式的更改和版本管理过程。注意，这并不是一个完整的列表。

配置管理

配置管理可标识、记录、跟踪和报告称为配置项目 (CI) 的重要 IT 组件或资产。捕获和跟踪的信息取决于特定的 CI，但通常包括 CI 的描述、版本、构成组件、与其他 CI 的关系、位置/分配以及当前状态等。

可将 PKI 配置管理归类到 5 个主要领域。

下列部分详细描述了其中的每个项目，并且包括用于显示与该领域相关的配置信息的一些命令。您可能已经在组织中建立了一个配置管理数据库。可以使用这些命令的输出结果来填充该系统（但可能需要重新设置输出结果的格式）。可通过将这些命令的输出结果重定向到文本文件来创建 PKI 的基本配置管理数据库。您可以使用文本比较工具（如 Windows Resource Kit 中的 Windiff），将新配置中的内容与先前的记录进行比较，以便更容易地发现任何反常的情况。

有关配置管理的详细信息，请参见“相关链接”。

收集企业 PKI 配置信息

整个企业范围内的配置信息存储在 Active Directory 中。这包括受信任的根 CA 发布、企业 CA 配置以及公布信息。它还包括证书模板，但这些内容将在“收集证书模板配置信息”中单独阐述。

频率

每年一次或者根据需要

安全要求

具有 Domain Users 的成员身份

任务详细信息

保留 Active Directory 中存储的下列信息的记录。

在以下过程中，给出了用于收集此信息的命令。对于其中的某些命令，您必须将示例根域可分辨名称 (DN) DC=contoso, DC=com 替换为您的 林根域的 DN。

注意：出于打印考虑，下列某些命令显示为多行，但实际应在单行输入。

显示受信任的根证书颁发机构

certutil -store -enterprise Root

显示 NT 验证存储

certutil -store -enterprise NTAuth

显示企业 CA

certutil -dump

显示当前企业 CA 的证书

certutil -store -enterprise "ldap:///cn=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,
DC=contoso, DC=com?cACertificate?one?
objectClass=pkiEnrollmentService"

显示中间和交叉证书

certutil -store -enterprise CA

显示其自身的中间 CA 证书

certutil -store -enterprise "ldap:///cn=AIA,CN=Public Key Services,CN=Services,CN=Configuration, DC=contoso, DC=com?cACertificate?one?
objectClass=certificationAuthority"

显示其自身的交叉证书

certutil -store -enterprise "ldap:///cn=AIA,CN=Public Key Services,CN=Services,CN=Configuration, DC=contoso, DC=com?cRossCertificatePair?one?
objectClass=certificationAuthority"

显示当前发布的 CRL

dsquery * "cn=CDP,cn=Public Key Services,cn=Services, cn=Configuration,DC=contoso, DC=com" -attr cn -scope onelevel

dsquery * "cn=CDP,cn=Public Key Services,cn=Services, cn=Configuration, DC=contoso, DC=com" _ 
    -attr cn –filter (objectclass=crlDistributionPoint)

certutil -store -enterprise "ldap:///cn=Contoso Root CA 1,cn=RT-CA-01,cn=CDP,CN=Public _ 
    Key Services,CN=Services,CN=Configuration, DC=contoso, DC=com?certificateRevocationList?base?objectClass=cRlDistributionPoint"

您可以编写一个命令文件（批处理）脚本来自动运行这些命令，从而简化其运行过程。

收集证书模板配置信息

证书模板存储在 Active Directory 中。对于每个模板的配置以及用于每个模板的证书注册权限，都保留一份记录。

频率

每年一次或者根据需要

安全要求

Domain Users

任务详细信息

可以使用以下命令收集此信息。

注意：出于打印考虑，其中的某些命令可能显示为多行，但实际应在单行输入。

生成在 Active Directory 中配置的模板的列表

Certutil -template

转储这些模板的配置

Certutil –dsTemplate

转储模板的权限

Dsacls "cn=TemplateName,cn=Certificate Templates,cn=Public Key Services,cn=Services,cn=Configuration,DC=contoso, DC=com"

目前还没有一种工具，能够以易于阅读的形式导出完整的模板权限。Dsacls.exe 可显示模板的权限。但是，当前版本并不显示扩展权限“自动注册”，尽管它可以显示“注册”以及其他扩展权限。这意味着，您必须手动保留一份“自动注册”权限记录。或者，您可以使用 Active Directory Services Interface (ADSI) 编写一个脚本或工具以正确读取和显示所有权限。

收集 CA 配置信息

这一节将阐述在每个 CA 本地存储的配置信息；对于企业 CA，则阐述存储在 Active Directory 中的某些信息。

频率

每年一次或者根据需要

安全要求

CA 的本地 Administrators

任务详细信息

保留下列信息的记录。

可以使用以下命令收集此信息。

显示 CA 注册表配置

certutil -getreg
certutil -getreg CA

显示当前（最新）的 CA 证书

certutil -f -ca.cert %temp%\CAcert.cer > nul && certutil -dump %temp%\CACert.cer

目前还没有一种工具，能够以便于使用的格式转储 CA 权限。应手动保留此信息的记录。

显示当前为此 CA 分配的模板

certutil -CATemplates

在维护 CA CPS 文件时应使用适当的版本控制，以便于确定和检索在任意给定时间有效的 CPS。

收集 CA 和 PKI 管理组信息

PKI 管理组成员是非常重要的配置信息，因为这些组控制了 CA 和企业 PKI 信息的方方面面。

频率

每年一次或者根据需要

安全要求

Domain Users

任务详细信息

对于每个 PKI 和 CA 管理组，列出并记录当前的成员。如果有任何成员自身就是一个组（在其名称前面用一个星号来表示），则依次列出该组的成员，直到您得到一个所有 PKI 组成员包括的完全用户列表。

默认的组有：

列出每个组的成员

net groups groupname /domain

net localgroup groupname

收集证书客户端配置信息

此任务将查阅使用组策略部署的客户端配置信息。如果您使用任何其他机制（例如，SMS 或登录脚本）来部署与 PKI 相关的客户端设置，则在此处也将其记录下来。

频率

每年一次或者根据需要

安全要求

具有 GPO 管理权限的 Active Directory

任务详细信息

使用组策略管理控制台 (GPMC) 或“GPO 策略的结果集”MMC 来收集并列出 PKI 客户端配置信息。有关如何获取和使用 GPMC 的详细信息，请参见“相关链接”。

返回页首

常见支持任务

疑难解答和支持属于 MOF 的“支持”部分。支持过程是反应性任务，旨在将 PKI 服务还原到预期的级别。疑难解答是 MOF 问题管理的一部分，其目的是跟踪故障的来源并在源头消除故障。影响大的服务中断几乎总会涉及这两种服务管理功能。

MOF 的“支持”部分还阐明了服务台的运行，服务台将接收故障报告并启动相应的支持过程。本文不再对服务台的组织进行详细阐述。有关详细信息，请参见“相关链接”中 Microsoft 操作框架过程模型文档对服务台的描述。

这一节将列出一些可能会对 PKI 产生影响的常见支持事件或具有很大影响的支持事件。同时还列出了一些支持过程，这些过程可帮助您处理其中的一些支持事件。这些支持过程在其他资料中没有涉及。

这一节的内容与“配置监视和警报”内容密切相关。服务监视可提供一些必要信息，供操作和支持人员来检测问题。特别是，“监视服务可用性”中描述的警报事件指出了目前或将要发生的服务故障。这一节将对这些故障加以介绍。

表 22 中描述了在 PKI 管理过程中可能会遇到的许多主要支持事件。“支持任务或参考”栏列出了下面的某一项内容：

支持任务

这一节包含某些 PKI 支持任务的详细信息，在其他资料中都没有全面地介绍这些任务。

从备份中还原 CA

如果由于服务器软件或硬件损坏而无法启动 CA，则需要从备份中还原服务器和密钥材料。这是指还原系统状态备份，而且可能需要重新安装 Windows。

频率

根据需要

安全要求

具有 CA 的本地 Administrators 的成员身份（如果只执行还原操作，则需要具有 CA Backup Operators 的成员身份）

任务详细信息

执行下列步骤从备份中还原 CA。

注意：如果使用的是 HSM，此过程可能不会按描述的方式工作。按照 HSM 供应商的说明进行备份和还原操作，并且妥善保管好密钥材料和访问密钥。

从备份中还原 CA

Certutil –restore C:\CARestore

将 CA 证书和密钥对还原到临时计算机

如果无法及时还原失败的 CA，致使 CA 无法颁发新的 CRL（或续订关键证书），您需要在一台临时计算机上安装 CA 证书和密钥。在这台计算机上，您可以使用它们来重新进行签署，并延长由失败的 CA 所颁发的现有 CRL 或证书的有效期。

注意：如果使用的是 HSM，此过程可能不会按预期方式工作。按照 HSM 供应商的说明进行备份和还原操作，并且妥善保管好密钥材料和访问密钥。

频率

根据需要

安全要求

具有临时计算机上的本地 Administrators 的成员身份

任务详细信息

此任务描述如何将 CA 证书和私钥还原到一台临时计算机。

重要信息：尽管这台计算机安装了 CA 密钥，但应采取与 CA 相同的安全预防措施。如果要还原脱机 CA 的密钥，应确保该计算机处于脱机状态。在完成此任务后，可以考虑重新格式化计算机磁盘以删除密钥数据。

将 CA 密钥和证书还原到一台临时计算机

现在，您就可以执行还原的 CA 密钥所需的任何重新签署任务。请参见“重新签署 CRL 或证书以延长其有效期”。完成后，使用下列过程从计算机中清除密钥。（如果使用的是 HSM，则无需执行此操作。）

将密钥从系统中清除

Cipher /W:%AllUsersProfile%

注意：可指定 %allusersprofile% 作为路径，确保 Cipher.exe 在存放用户配置文件的驱动器上执行。此命令清除整个驱动器，而不是只清除指定的路径。

重新签署 CRL 或证书以延长其有效期

如果由于服务器的某种故障导致 CA 不可用，您可以通过重新签署 CRL 或证书文件来延长 CRL 或证书的有效期。为使服务或应用程序能够继续工作，您可能必须执行此操作。

频率

根据需要

安全要求

在 CA 密钥还原期间创建的临时帐户

任务详细信息

重新签署证书或 CRL 将会延长其有效期。默认情况下，将使用现有的有效期，而有效期从签署日期重新算起（例如，如果 CRL 的原有效期是一个月，则新有效期为从重新签署之日算起的一个月）。如果需要不同的有效期，可在 certutil 命令中进行指定。

重新签署 CRL 或证书

Certutil -sign OldFile.ext NewFile.ext

如果是 CRL，则现在必须将其发布到 CDP。（请参见“操作 PKI”中有关发布 CRL 的过程。）也需要将 CA 证书发布到目录、Web 服务器以及可能的中间 CA。请参见“续订 CA 证书”，了解需要将每个 CA 证书发布到什么地方。

吊销孤立证书

在出现某种服务器故障后，在从备份中还原 CA 时，证书数据库中可能没有自上次备份到发生故障这段时期内颁发的证书。这些证书就是所谓的“孤立”证书。在从备份还原后，如果 CA 日志损坏而且无法为 CA 数据库重新运行这些日志，则可能会出现这种情况。如果出现这种情况，将无法使用常规过程来吊销其中的任何“孤立”证书。

频率

根据需要

安全要求

具有 Cert Managers 的成员身份

任务详细信息

要吊销孤立证书，必须获取一个要吊销的证书的副本，或者获取该证书的序列号。

吊销孤立证书

Certutil -sign SerialNumber CertToRevoke.cer

Certutil -importcert CertToRevoke.cer

重要信息：certutil 存在一个问题，在 Windows Server 2003 Service Pack 1 之前的版本中创建虚拟证书时，它导致创建操作失败。预计在后续版本中将修复此功能，因此将这一过程包含在本文中。同时，如果您找不到原证书的副本，一种备选方法是使用现有的证书，然后使用二进制编辑器将其序列号替换为要吊销的证书的序列号。可使用下列语法，对修改后的该证书重新进行签署。

Certutil -sign ModifiedCert.cer CertToRevoke.cer

然后，可使用步骤 4 将新创建的证书导入到数据库中。

吊销和替换颁发 CA 证书

如果 CA 私钥以某种方式被泄露（或者怀疑被泄露），请吊销 CA 证书，并使用新的密钥对颁发新的 CA 证书。

警告：吊销 CA 可能是极具破坏力的事件，它使该 CA 及其从属 CA 颁发的所有证书均失效。然而，通过遵循仔细规划的过程，有助于最大限度地减少造成的破坏。

频率

根据需要

安全要求

具有颁发 CA 及其父（中间）CA 的 Cert Managers 组的成员身份。要续订颁发 CA 证书，您需要具有该 CA 的本地 Administrators 组的成员身份。

任务详细信息

由于中间 CA 具有很长的 CRL 发布期，所以只吊销颁发 CA 证书和发布新的 CRL，也会导致在吊销过程开始和证书用户收到该吊销通知之间有较长时间的延迟。为了确保尽早拒绝先前由已泄露的颁发 CA 颁发的所有证书，也可以单独吊销此 CA 颁发的所有证书。

重要信息：使用吊销 CA 颁发的证书的所有用户必须使用此过程，重新注册新的证书。

吊销颁发 CA 证书及其颁发的证书

证书用户现在可以使用续订的颁发 CA 重新注册。自动注册的证书将会自动进行注册。

吊销和替换中间 CA 证书

如果 CA 私钥以某种方式被泄露（或者怀疑被泄露），请吊销 CA 证书，并使用新的密钥对颁发新的 CA 证书。

警告：吊销 CA 可能是极具破坏力的事件，它使该 CA 及其从属 CA 颁发的所有证书均失效。然而，通过遵循仔细规划的过程，有助于最大限度地减少造成的破坏。

频率

根据需要

安全要求

具有中间 CA 及其父（根）CA 的 Cert Managers 组的成员身份。要续订中间 CA 证书，您需要具有该 CA 的本地 Administrators 组的成员身份。

任务详细信息

由于根 CA 具有很长的 CRL 发布期，所以只吊销中间 CA 证书和发布新的 CRL，也会导致在吊销过程开始和证书用户收到该吊销通知之间有较长时间的延迟。为了确保尽早拒绝先前由已泄露 CA 的从属 CA 所颁发的所有证书，也可以单独吊销由从属 CA 颁发的全部证书。

重要信息：使用吊销 CA 颁发的证书的所有用户必须使用此过程，重新注册新的证书。

吊销中间 CA 证书及其颁发的证书

证书用户现在可以使用续订的颁发 CA 重新注册。自动注册的证书将会自动进行注册。

吊销和替换根 CA 证书

如果根 CA 的私钥以某种方式被泄露（或者怀疑被泄露），您必须从其信任点删除 CA 证书，然后吊销它及其所有从属 CA 颁发的全部证书。您必须使用新密钥续订根 CA 证书及其从属 CA 的所有证书，然后将它们发布到 Active Directory。

警告：吊销根 CA 可能是极具破坏力的事件，它使该 CA 及其所有从属 CA 颁发的所有证书均失效。然而，通过遵循仔细规划的过程，有助于最大限度地减少造成的破坏。

严格来说，无法以这种方式吊销根 CA 证书。通常，就像此时的情况一样，根 CA 证书并不包含 CDP，更为重要的是，CA 证实其自身的吊销是没有意义的。它必须使用同一证书的泄露密钥来签署包含其自身吊销证书的 CRL。

频率

根据需要

安全要求

具有根 CA 的 Cert Managers 组的成员身份。要续订根 CA 证书，您需要具有该 CA 的本地 Administrators 组的成员身份。

任务详细信息

注意：在完成此过程后，所有证书用户必须重新注册新证书。

吊销颁发 CA 证书

证书用户现在可以使用新的 CA 重新注册。自动注册的证书将会自动进行注册。

返回页首

摘要

管理 Windows Server 2003 PKI 中描述了如何建立并运行 Windows Server 2003 PKI 的操作环境。该文章的第一部分阐述了 PKI 操作框架的规划和部署，如下列章节所述：

第二部分的重点是阐述使 PKI 保持平稳运行所需的一些任务，如下列章节所述：

每个 IT 环境都是不同的；没有通用的指南可以完全涵盖每个组织的操作特点。但是，本文可以作为一个坚实的基础，您可以基于它来量身定做自己的 PKI 操作手册。

使用本文作为一个起点，在部署和增强您的 PKI 时对其进行修改。您需要针对组织中使用 PKI 的特定情况，添加一些操作和支持过程。您可能还需要将某些手动步骤编制成脚本来简化本文中的过程。最重要的是，要注意这些过程是否符合 IT 组织的做法和文化，并随时准备修改它们以达到更好的效果。如果这些操作符合 IT 组织的做法和文化，它们就会收到很好的效果，当然您的 PKI 也会如此。

返回页首

相关链接

请参见下列资源以了解更多信息。

返回页首

附录 A － PKI 设计概述

本文基于文章 Microsoft System Architecture version 2.0 Implementation Kit（Microsoft System Architecture 版本 2.0 实现工具包）和 Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure 中描述的 PKI。PKI 设计基于虚构公司 Contoso。

在此只对 Contoso 方案进行简短描述。有关 Contoso PKI 设计和创建的详细描述，请参见这些文档。下一节将列出实现特定的设置，在本文的示例中将使用这些设置。

Contoso PKI 设计

Contoso 是一家国际化的公司，它已部署了 Active Directory 和 Windows Server 2003 PKI。Contoso 拥有各种类型的客户，他们运行的是 Windows 2000 系列产品或 Windows XP Professional。它使用多种充分利用 Windows Server 2003 PKI 的集成应用程序，包括基于安全/多用途 Internet 邮件扩展 (S/MIME) 的电子邮件安全性、EFS、L2TP/IPsec VPN 连接、802.1X 无线访问以及启用安全套接字层 (SSL) 的 Web 服务器。Contoso Active Directory 林具有多个域，并在 Windows Server 2003 林功能模式下运行。每个域在 Windows Server 2003 域功能模式下运行。

Contoso 使用一个三层的 PKI 拓扑结构，以最好地满足其安全需求。本文中的操作指南就是以此拓扑结构为模型。但是，对于更简单的两层结构而言，这些操作几乎完全相同，因此本文对很多组织都非常有用。

图 5 阐述了 Contoso 公司的证书服务结构。

图 5：Contoso PKI 设计

Contoso 独立根 CA 从不连接到网络上，它始终处于脱机状态，因此是物理安全的。根 CA 将为层次结构中的中间 CA 颁发和吊销证书。CA 证书和 CRL 是手动发布的，并通过 IIS Web 服务器上的 HTTP 分发点提供。

中间 CA 是物理安全的，它通过脱机方式进行操作，这一点与根 CA 类似。图 5 中只显示了一个中间 CA，但在更复杂的层次结构中可能使用其他的中间 CA。根和中间 CA 可以是 Windows Server 2003 Standard Edition 或 Enterprise Edition。

颁发 CA 负责最终实体的证书注册，它们均作为企业 CA 进行安装。这些 CA 服务器都是联机的，它们可以随时处理服务请求。颁发 CA 是 Windows Server 2003 Enterprise Edition。

本文并不介绍有关 HSM 管理的内容，因为该过程随供应商的不同而变化非常大。但是，我们预计层次结构中的所有 CA 都将配备 HSM。

Active Directory

Active Directory 可用于多种功能。

IIS Web 服务器

IIS 用于发布 AIA 信息（链建立期间所需的中间 CA 证书）和 CRL。Web 服务器也是发布证书实施细则（如果需要）的最佳位置。根据证书客户端所处位置的不同，您可能需要一台面向 Internet 的服务器或一台内部 Web 服务器来发布 PKI 信息。

与 MSA 指南的不同之处

尽管本文中的指南均基于 MSA 2.0 中所描述的参考 PKI，但它们还是有一些细微差异（主要是在美学方面）。最显著的功能差异是，颁发 CA 证书具有 4 年的有效期。MSA 颁发 CA 的有效期为 2 年，它将这些 CA 所颁发的证书的有效期限制为只有一年。由于在某些方案中证书续订的费用非常昂贵（例如，智能卡续订），因此客户通常更希望采用 2 年或更长的续订期。

本文中介绍的其他细微差异有：

详细的 PKI 配置

下列各表包含 Contoso PKI 使用的实现参数。本文中的过程将使用这些值。这些参数分别放在两个表中。表 23 中列出了安装特定的值。当这些值在过程中出现时，您需要将其替换为贵组织的详细资料。表 24 中列出了解决方案特定的值。这些值基于 MSA 和最佳做法方案中推荐的配置。只有在您的实现中使用不同的值时，才需要对这些值进行更改。这些表只列出了与本文中的过程相关的值，它们只是 PKI 实现的完整参数列表的一个子集。要获得完整列表，请参见“相关链接”中的 Microsoft System Architecture 2.0 Build Guide（Microsoft System Architecture 2.0 建立指南）的“Certificate Services”（证书服务）一章中的附录 14.16。

表 23：组织特定的配置项

表 24：常规配置项

返回页首

附录 B － 通用标准管理角色

证书颁发和管理组件的通用标准 (CC) 保护配置文件（相关链接）在最高安全级别定义了 4 种重要角色：Administrator、Officer、Operator 和 Auditor。这些 CC 角色是在 Windows Server 2003 证书服务中实现的，可通过它们将角色强制分离，从而使一个帐户无法被配置为多个角色。有关 Windows Server 2003 证书服务角色和功能的详细信息，请参见 Windows Server 2003 Operations Guide（Windows Server 2003 操作指南）中的“Windows Server 2003 PKI and Role-Based Administration”（Windows Server 2003 PKI 和基于角色的管理）一节（相关链接）。

尽管如此，CC 角色有时还是无法提供足够强大的功能。CC 角色与 CA 级别的功能有关。但是，Windows 企业 CA 是在整个企业范围内的配置对象中存储配置信息。为此，Windows PKI 还需要整个企业范围内的管理角色来管理此信息。对于大型组织而言，它们通常都希望能够委派特定角色的部分职责。例如，它们可能希望允许个别应用程序所有者决定可以为该应用程序注册证书的人选，而不是将此责任委派给整个组织范围内的 Officer 或 Certificate Manager 角色。表 25 中列出了此扩展角色集的定义以及它们映射到 CC 角色的方式。

这些角色不可能精确地映射到您的 IT 组织中的各个工作角色。最有可能的情况是，这些个人将会填补其中的多个功能角色。而且，其中的某些角色可能由系统进程填补，而不是由个人填补，例如，运行 CA 的备份代理的帐户。

表 25：核心证书服务角色

如果您在 CA 中使用 HSM，则还会为该组件定义特定的功能角色，如密钥卡控制和操作员卡持有者。此列表也未列出与 PKI 交互并提供支持的其他技术领域的相关功能角色，如操作控制台监视以及 Active Directory 管理。

返回页首