简介
上一章介绍了依赖于公钥基础结构 （PKI） 的安全无线解决方案的逻辑设计。 本章定义基于 MicrosoftWindows2003 证书服务，为该解决方案设计 PKI 的流程。 为了降低部署和管理成本，该解决方案设计相对比较简单，非常适用于为安全无线客户端和无线局域网 （WLAN） 基础结构颁发证书。
虽然首要目的是设计支持安全 WLAN 的 PKI，但是要记住，PKI 也是组织的整体安全基础结构的重要组成部分 — 环境中的其他各种应用以后可能使用它。 为了保护您对此基础结构的投资，该解决方案设计可以扩展。 这意味着，虽然该设计可能不适用于颁发所有类型的证书，但是它允许您在将来添加其他功能和容量，以满足比此处讨论的更广泛的安全需求。
本章有三个主要目的。 第一个目的是讨论解决方案设计决策以及决策背后的理论依据。 第二个是提供一些背景规划信息，以帮助您确定这些决策是否适用于您的 PKI. 第三个是指出扩展基本解决方案的方法，以帮助您满足本解决方案的范围以外的安全需求。
本章中出现的“本解决方案采用……”或“本设计采用……”等语句，是指该解决方案的“构建”和“操作”各章中实施的解决方案设计的决策。
诸如“您应该决定……”的语句表示您必须根据自已的要求作决策。 这种情况多数出现在文中讨论如何扩展该解决方案以满足组织更广泛的安全需求的时候。 因此，有些主题进行了较详细的讨论，以便帮助您了解该步骤的含义，并且不必参考其他文档。
本章先决条件
应非常了解 PKI 的一般原则和术语。 如果对此技术比较陌生，应先阅读本章末尾“更多信息”一节参考的一些文章。
在继续本章之前，应熟悉 Microsoft Windows Server2003 部署工具包的“设计公钥基础结构”一章。 有关如何获取此信息的详细信息，请参阅本章末尾的“更多信息”一节。 本章沿用部署工具包中“设计公钥基础结构”一章的结构，便于您参考相关背景信息和此处包含的更详细的讨论。
“更多信息”一节还提供了一些链接，指向有关如何规划和设计 Windows Server 2003 PKI 的其他详细信息。
本章概述
规划和部署满足组织当前及将来需求的 PKI 并非轻而易举。 通常，PKI 不是为单个孤立的安全问题提供解决方案。 相反，组织会部署 PKI 来处理许多内部安全需求以及商业安全需求，以便与外部客户或商业伙伴合作。
下面的流程图展示了本章的结构。
图 4.1 规划证书服务的章节结构
这四个主要步骤是：
定义证书要求。 此步骤涉及定义要解决的安全问题。 这是由具体的应用和需要增强安全性的用户、这些用户所在的位置以及所需的增强安全性的程度决定的。 开始创建 PKI 之前，必须先定义安全和业务要求。
设计证书颁发机构的层次结构。 基于各种因素，您必须创建证书颁发机构 （CA） 的基础结构。 此步骤包括定义信任模型、确定需要多少 CA、如何管理这些 CA 以及如何通过引入其他 CA 或与其他组织建立信任关系来扩展 PKI. 此外，此步骤还讨论 PKI 如何与 IT 基础结构中的其他技术（如 Active Directory目录服务和 Microsoft Internet 信息服务 （IIS））集成。
配置证书配置文件。 此步骤包括决定使用的证书类型、与这些证书关联的密钥的强度、证书的有效期以及这些证书是否可以续订。
创建证书管理计划。 此步骤定义如何将证书颁发给最终用户、如何处理证书申请，以及如何管理和分发证书吊销列表 （CRL）。
定义证书需求
本节定义 PKI 颁发证书的用途，以及各个用途的安全要求。
创建证书实施声明
设计 PKI 时，应当记录有关如何在组织中颁发和使用证书的决定。 这些决定称为证书策略，记录这些决定的文档称为证书策略声明和证书实施声明。
正式地来讲，证书策略 （CP） 是一组指导 PKI 如何操作的规则。 例如，它记录证书对特定客户端组或对普通安全需求的应用的适用性。 证书实施声明 （CPS） 是组织用于管理它所颁发的证书的实施声明。 它描述在组织系统体系结构和操作程序环境中，如何解释组织的证书策略。 CP 是组织级的文档。 但是，CPS 是特定于 CA 的（尽管当 CA 执行相同作业时可能使用公用 CPS — 例如，因性能或复原原因将 CA 负载分发到多个服务器时）。
对于某些组织和证书用途，CP 和 CPS 被视为法律文档或法律免责声明。 撰写这些文档通常需要专业的法律意见，这超出了本文范畴。 不过，将哪一个文档作为 PKI 的构成部分并没有严格的要求。 如果没有特定的法律或商业原因，可以不必花费时间和资金来制订和维护正式的证书策略和实施声明。
尽管可能不需要正式的 CP 或 CPS，但仍应将证书策略和操作规范记录成文档。 证书策略应当成为您的组织的整体安全策略的一部分，操作规范应当成为安全管理过程的组成部分。 这可以称为非正式 CPS.
您应当根据 PKI 的预期用途确定是否要制订正式的策略声明和 CPS. 如果需要正式的 CPS，则很可能需要发布它，并在 CA 证书中加以引用。 虽然本解决方案中没有包括有关撰写正式的 CPS 的指导，但是第 7 章“实施公钥基础结构”中提供了如何发布 CPS 的说明。一般情况下不需要发布非正式 CPS.
在本章其余部分中，会经常提到在您的 CPS 中记录决定。 这些说明对于正式和非正式 CPS 同样适用。
本章末尾的“更多信息”一节提供了一些有关如何制订 CPS 的其他信息来源。
确定证书应用程序
PKI 设计过程中的第一步是确定要使用证书的应用程序的列表。 应该记录每项应用所需的证书类型，以及该应用需要的证书的大致数量。 在这一阶段，无需指定证书的任何细节信息，只需提供简短描述即可。
安全无线解决方案需要无线客户端和 Windows 远程身份验证拨入用户服务 （RADIUS） 服务器的证书。 Microsoft RADIUS 服务器是 Windows Server 的组件，称为 Internet 验证服务 （IAS）。
下表显示了所需的证书类型。 虽然本解决方案并不严格要求，但 PKI 还会向域控制器颁发证书（当在林中安装了 Windows 2003 Enterprise CA 时，这是默认值）。
表 4.1：安全无线解决方案的证书要求 应用程序 证书类型 证书数量 安全 WLAN 用户的客户端身份验证证书。 所有需要访问 WLAN 的用户。 计算机的客户端身份验证证书。 所有无线 LAN 计算机。 IAS 服务器的服务器身份验证证书。 所有 IAS 服务器。 Active Directory 域控制器身份验证。 林中的所有域控制器。
将来您可以扩展 PKI，以为下表所示的应用颁发证书。
表 4.2：未来可能的证书要求 应用程序 证书类型 证书数量 客户端访问虚拟专用网络 (VPN) 计算机客户端身份验证 (IPsec) 所有远程 VPN 客户端 分支到分支 VPN VPN 服务器身份验证 (IPsec) 所有 VPN 路由器 IP 安全性 (IPsec) 计算机客户端身份验证 所有要求 IPsec 的客户端和服务器计算机 Web 安全性 对访问 Intranet Web 应用程序的用户的身份验证。 所有用户 Intranet Web 服务器 安全 Intranet Web 服务器 加密文件系统 (EFS) EFS 用户 所有用户 EFS 数据恢复 恢复代理 安全电子邮件 安全/多用途 Internet 邮件扩展 (S/MIME) 签名和加密 所有电子邮件用户 密钥恢复 恢复代理 智能卡 智能卡登录 域用户 代码签名 内部代码和宏签名 代码发布管理员
定义证书客户端
对前一节中列出的应用，应该定义将使用证书的客户端。 这里，术语“客户端”是指任何使用 PKI 颁发的证书的人员、软件进程或者设备。 例如，客户端包括用户、服务器、工作站和网络设备。 为了解如何使用颁发的证书，您必须考虑两个主要客户端类别：证书使用者（或最终实体）和其他证书用户。
最终实体是指具有由 PKI 颁发的证书的客户端。 证书的“使用者”或“使用者备用名称”字段有一个或多个条目，将客户端（如主机名、电子邮件地址或目录可分辨名称）标识为该证书的所有者。 另一类证书用户是指可能需要验证最终实体的证书，或者要在目录中查找证书，但 PKI 并不向其颁发证书的客户端。
以下常见实例可帮助您进行区分：在安全网站上购物的 Internet 用户是该网站的安全套接字层 （SSL） 证书的用户。 但是，该网站是证书最终实体；其身份 — www.woodgrovebank.com — 被编码到证书的“使用者”字段中。 只有证书使用者有权使用证书私钥 — 其他证书用户则不能。 注：证书使用者也几乎总是自已的证书和（通常情况）其他证书的证书用户。
注：“最终实体”是正确的技术术语，但本章的大多数地方都使用更友好的术语“证书使用者”。
对于证书使用者和证书用户，都应当通过回答下列问题来对各个客户端类型进行分类：
客户端是一个人，一台计算机或设备，还是一个软件进程？
证书将在什么平台（操作系统版本）上使用？
客户端的网络位置在哪里例如，它是连接到内部局域网、位于合作伙伴组织中，还是在 Internet 上？
该客户端是域成员吗如果是，是位于与 CA 不同的域中，还是在不同的林中是不受信任的域吗？
该客户端需要执行何种类型的操作例如，注册证书，使用证书签名，验证证书信任，在目录中查找证书，以及检查证书吊销状态。
这种分类将影响许多设计决策，例如如何颁发证书、对给定证书的信任级别，以及如何发布证书吊销信息。
对于本解决方案，下表对客户端类别作了详细说明。
表 4.3：证书使用者（最终实体）类别 证书 证书类型 平台 位置 域 证书操作
无线客户端身份验证
用户 Windows XP 内部网络 域成员 –注册–身份验证无线客户端身份验证
计算机 Windows XP 内部网络 域成员 –注册–身份验证IAS 服务器身份验证
计算机 Microsoft Windows Server檥 2003 内部网络 域成员 –注册–身份验证–安全通道在本应用程序中，证书的用户将是同一组客户端，但角色相反。 例如，IAS 服务器成了客户端证书的用户，需要验证这些证书。 验证通常包括验证证书是否链接到受信任根 CA 以及客户端提供的签名与客户端证书中的公钥是否匹配。 还可能需要对证书进行吊销检查。 有关此主题的详细说明，请参阅文章“证书状态和吊销疑难解答” .本章末尾的“更多信息”一节提供了全面的参考。
表 4.4：证书用户类别 证书 证书类型 平台 位置 域 证书操作
无线客户端身份验证
–计算机 Windows Server 2003 内部网络 域成员 –验证–检查吊销无线客户端身份验证
–计算机 Windows Server 2003 内部网络 域成员 –验证–检查吊销IAS 服务器身份验证
–用户–计算机 Windows XP 内部网络 域成员 –验证从以上表中，可以确定需要支持的平台和操作种类。 虽然在 WLAN 方案中不是这样，但对于您的环境中其他应用，可能需要支持 Internet 上的客户端进行证书查找或验证，或从非 Windows 平台注册。 因为必须在设计过程的较早阶段确定许多这样的事项，所以构思未来可能的证书要求很重要。
本解决方案对未来的要求作下列假设：
很可能需要从非 Windows 客户端进行证书验证。
可能需要从 Internet 进行证书验证。
可能需要在 Windonws XP 和 Windows Server 2003 外的其他平台上同时支持证书使用者和证书用户。
虽然目前不一定满足所有这些要求，但在设计中将它们考虑在内并不困难。
定义证书安全要求
证书的安全性也称为确定性。 可以将其看作绑定证书的使用者和证书本身的强度。 它反映可以在多大程度上相信使用证书的人（或设备）就是证书中命名的使用者。 这个确定性主要衡量两个指标：
注册和证书注册过程的严格程度 — 例如，需要本人亲自到场并出示附带照片的 ID 才可以获得证书，还是只需要拥有一个电子邮件地址就足够了？
存储私钥的方式 — 复制或破解密钥越困难，就越可以肯定原所有人（即证书使用者）仍独自拥有该证书。
这两者之间密切相关，因为如果始终不能真正确定私钥所有者的身份，那么花费高昂代价保护私钥就根本没有意义。 同样地，如果密钥在注册后以不安全的方式存储，那么即使费尽心机地在注册过程中进行广泛背景检查和 DNA 指纹鉴定也几乎毫无价值。
但是，获得较高的证书确定性，需要花费成本，并且对于许多证书使用而言，经常没有必要。 如果除了证书属于授权域用户外，不需要对该证书具有更高级别的保证，那么完全可以使用域凭据作为注册证据来注册证书。
应当记录证书策略和实施声明中所使用的确定性的含义。
对于本解决方案，下表定义了三个确定性级别。
表 4.5：证书确定性级别 级别 注册要求 密钥存储要求
标准（低）
根据域或其他基于密码的识别过程进行自动批准。 软件密钥 中 证书管理员批准，可视 ID 检查（智能卡）或者注册官签名。 软件密钥或硬件防篡改令牌（智能卡或 USB 令牌）。 高 指定的注册官签名和证书管理员批准。 硬件防篡改令牌（智能卡或 USB 令牌）。这些类别之间有些重叠。 这些类别并不是严格的技术上的分类；实际上是策略上的分类。 在您的组织中，这些类别之间的分界依据是您对证书操作方式的决策。 一般说来，高确定性的证书较少见，而标准确定性的证书则比较常见。
重要：本章使用术语“标准值”证书和“标准确定性”证书代替“低值”和“低确定性”。因为后者具有负面意义，而“标准”更能反映实际要表达的含义。
通过划分为不同的使用者类型，可将上表中定义的确定性类别进一步细分。 常见类别有：
计算机 —- 组织中的任何计算机或设备。
内部用户 — 表示全职雇员或者被视为等同的职员（如合同工等）。
外部用户 — 表示任何位于组织外部，但与之有某种业务或法律关系的实体（如业务伙伴或客户）。
进行这种分类的原因是这些不同的使用者类型应用的证书策略通常有很大差别，即颁发、吊销、续订证书等的条件差别很大。 即使您没有给定类别的证书计划，也可能需要记录将要应用于该类别的证书策略，以便能够正确地制订策略和 CPS. 下表描述了确定性和使用者类别的组合结果。
表 4.6：证书安全类别 证书安全类别 安全类别的特征示例 证书类型示例 计算机证书 标准确定性计算机证书 -根据计算机域凭据进行自动批准。-年度续订。 –WLAN 计算机–IPsec
中确定性计算机证书
–要求证书管理员批准。–软件密钥存储。-年度续订。 –Web 服务器-IAS 服务器身份验证 高确定性计算机证书 –证书管理员批准。–硬件安全模块 (HSM) 密钥存储。 –证书颁发机构-安全时间服务–注册机构 内部用户证书 标准确定性内部用户证书 -根据用户域凭据进行自动批准。-年度续订。 EFS 用户 中确定性内部用户证书 –要求证书管理员或注册官批准。–智能卡或软件密钥存储。-年度续订。 –安全电子邮件–低-中等价值的财政授权-智能卡登录-内部代码签名-数据恢复代理-密钥恢复代理 高确定性内部用户证书 –要求对证书使用者进行物理 ID 验证。–要求证书管理员批准。–请求时要求注册官签名。–智能卡密钥存储。–六个月续订。 –高价值财政授权-商业代码签名 外部（用户）证书 标准确定性外部证书 - 根据预先指定的密码自动批准。-年度续订。 客户端身份验证（向 Internet 网站验证） 中等级别外部证书 –要求证书管理员批准。–智能卡密钥存储。–六个月续订。 企业对企业 (B2B) 财政授权 高确定性外部证书 –要求对证书使用者进行物理 ID 验证。–要求证书管理员批准。–请求时要求注册官签名。–智能卡密钥存储。–六个月续订。 价值非常高的 B2B 交易注：如果不需要使用特定分类，则不必创建。 可能要使用更简单或更复杂的分类系统，而且并不是每种组合都要产生您将颁发的证书类型。
对不同的证书使用者类型分别对待，并没有技术上的原因。 但是，您通常会为不同的使用者类型定义不同的安全策略；例如，内部雇员的待遇与其他组织中的职员不同。 不同的证书策略（以及它们在不同 CPS 中的体现）可能会影响有关为颁发这些不同证书类型而如何构建 CA 方面的决策。 本章稍后讨论这一点。
您还应考虑是否由同一个管理员对向这三个类别的证书用户（PKI 术语中称为“最终实体”）颁发的证书负最终责任。 在许多组织中，可以证明一台计算机是合法域成员的人与可以证明合作伙伴公司身份的人不是同一个人。 您应当在 CPS 中记录这些责任关系。
定义应用程序证书安全性
上一节定义的证书安全类别可用于对该设计的证书类型进行分类。 下表中列出了这些类型。
表 4.7：证书安全要求 证书类型 安全类别 平台 逻辑位置 审批 密钥size 有效期 客户端身份验证 - 用户 标准确定性计算机证书 –Windows XP–Windows Server 2003 内部 自动（域控制器身份验证） 中 中 客户端身份验证 - 计算机 标准确定性用户证书 –Windows XP–Windows Server 2003 内部 自动（域控制器身份验证） 中 中 IAS 服务器身份验证 中确定性计算机证书 –Windows XP–Windows Server 2003 内部 手动 中 中
本章后面的“配置证书文件”一节将把这些较为宽泛的要求细分为具体的证书文件。
组合证书用途
可以将多个应用功能（或用途）组合到一个证书中，这样，用一个证书就可以签署电子邮件、登录网络以及授予对某项应用的访问权。 组合用途可以节省证书和目录服务器的管理和存储开支。
当然，多用途证书也有一些缺点。 例如，不同的应用程序可能需要不同的证书审批过程。 使用多个证书的原因大多数是技术性的，但是主要原因是，不同的应用通常要求不同的证书安全级别；也就是说，不同的确定性将证书绑定到证书使用者。 这包括以下其中一项或全部各项中的区别：
证书审批过程
密钥长度
密钥存储机制
证书有效期限
由于这一原因，组合安全性级别相同的证书用途通常是最好的策略。 本解决方案中使用的客户端身份验证证书类型包括其他标准应用（如 IPsec 和计算机身份验证）的用途。 当为其他证书用途定义要求时，可以包括这些用途，然后重新颁发证书（这将要求强制续订，您可以从证书模板定义启动）。
但是，IAS 服务器证书被看作是中确定性证书。 由未经授权的服务器证书带来的威胁比非法客户端证书带来的威胁大得多。 因此，应该更谨慎地处理服务器证书，Microsoft 建议不要将它们与标准确定性应用组合。
设计证书颁发机构层次结构
为了支持组织的基于证书的应用程序，必须建立一个 CA 链接框架，这个框架负责根据需要颁发、验证、续订和吊销证书。 反过来，CA 依赖基本 IT 基础结构，进行证书使用者身份验证、证书发行、以及证书吊销信息发布等事务。
建立 CA 基础结构的目的是，在为组织维持最佳安全水平的同时，为用户提供可靠的服务，为管理员提供可管理性，以及提供同时满足当前和未来需要的灵活性。
选择信任模型
设计 CA 基础结构的第一步是确定最适合您的要求的信任模型。 层次结构信任模型和网络信任模型是两个基本模型，但是，也可能将这两个模型的元素组合成一个混合信任模型。 有关这些模型的进一步讨论，请参阅“更多信息”一节中 Windows Server 2003 部署工具包的“设计公钥基础结构”一章。
本指南中的本解决方案使用层次结构信任模型。 这么做的理由是：
可对脱机 CA 应用比联机 CA 更高的安全级别。 一层或多层脱机 CA 会增加已颁发证书的整体信任级别。
没有目录的情况下，层次结构可以更轻松地工作；在支持对您的内部目录没有访问权限的外部客户端方面，这一点非常重要。 网络信任通常要求有目录，以便用户查询 CA 交叉证书来构建信任链。 层次结构中的信任链始终是显式的。
需要维护并向客户端分发的信任标记较少 — 只需要向您的证书用户分发根 CA 证书。
即使是根层次结构，仍可以选择在未来通过与其他层次结构交叉认证来加入多个信任标记（或根）。 这意味着本设计可以适用于组织兼并以及将特定用途的证书的控制移交给部门等事务。
对于建议的解决方案，单个根已足够。
第三方根与内部根
可以使用内部根作为 PKI 的信任标记，或者使用商业 CA 的服务达到相同目的。 使用第三方根意味着您的颁发 CA 由商业根 CA 认证（通常通过一个或多个中间 CA）。 因此，颁发的所有证书的信任标记最终都来自此外部根 CA.
注：虽然本指南中未明确考虑这一点，但也可以将组织的所有证书要求外包给商业 CA. 您可以使用现场托管服务，也可以直接从证书提供商获取证书。 除非组织规模很小，或者证书使用受到严格限制，否则从财务角度上这通常不可行。 此决策与使用内部根还是使用第三方根的问题完全无关 — 虽然二者经常混淆。
将商业根用于内部颁发的证书有以下若干优点：
商业根使外部各方（例如，访问您的安全网站的客户或接收签名的电子邮件的伙伴组织）更有信心与组织进行安全的交易。 他们通常已信任第三方根 CA，因此无需决定否信任您的证书。
商业根使组织能利用专业服务提供商的专业技能，包括提供商对与证书使用有关的技术、法律和业务问题的理解。 （但是，除非该证书提供商正在颁发您所有的证书，否则您仍将负责证书的颁发和使用方式，并需要将此记录在 CPS 中。）
但是，这种方法也有若干缺点：
证书平均成本通常很高。
证书提供商可能要求将严格的安全和审核措施用于所有从属该商业根 CA 的 CA.
内部用户和设备必须能够访问在 Internet 上发布的第三方 CA 的 CRL.
有些应用可能要求根和中间 CA 证书中含有特定参数或扩展（例如，Microsoft Windows 智能卡登录），而证书提供商可能无法提供这些内容。
您的组织和证书提供商之间的商业协议可能会限制您所能够从从属 CA 颁发的证书的类型。 例如，可能不允许 Web 服务器证书。
如果信任商业根 CA，那么对于您组织的安全需求而言，这种信任范围可能过大。 您可能需要引入特殊检查或再加入一层内部 CA，以便区分您的组织颁发的证书和另一个也从属于同一个根的组织颁发的证书。
尽管有这些缺点，如果您需要颁发大量组织外用户信任的证书，还是建议至少使一部分 PKI 从属于商业根（但这可能需要创建两个独立的层次结构）。
对于组织中使用的大多数证书，本解决方案使用一种基于内部根 CA 的层次结构。 此方法有下列优点：
允许组织直接控制集中信任标记（根 CA）以及掌管颁发和使用其颁发的证书的安全策略。
可以从内部 PKI 以较低的成本颁发大量证书。
对可以颁发的证书类型没有限制。
对内部证书的信任和对外部证书的信任之间不会存在着混淆。
可以根据需要在内部或外部发布 CRL 和颁发机构信息访问 （AIA） 信息。
如果您无法方便地管理证书用户的受信任根，应考虑使用外部根。 本解决方案建议使用第三方证书和外部根来实现以下服务：
Internet Web 服务器
商业代码签名
商业文档签名
外部受信任的安全电子邮件
定义外部证书信任
上一节粗略介绍了对其他组织的证书基础结构的信任。 您需要更全面地考虑这一主题，以便确定如何在您的组织中控制对证书的信任。 此处的“信任”一词具有三个重要条件：
信任的人或实体 — 信任谁？
信任该方执行的操作或活动 — 信任他们做什么？
保持这种信任的时间长度 — 要信任他们多久？
对于证书来说，“谁”是证书颁发机构，“什么”是您需要控制的证书用途和其他证书特征。 “多久”由根 CA 证书的有效期限决定，或者在某些情况下由所创建的特殊交叉信任证书的有效期限决定。
您可能需要在与其他组织建立新的业务关系，或者需要为您的用户启用某些功能（例如，委托 Web 证书启用安全 HTTP 会话）时，将更改您的组织与外部各方的默认信任关系。 例如，您可能需要执行以下操作：
分发伙伴组织（或新的商业证书提供商）的 CA 证书，以使您的某些或全部用户都信任该伙伴或商业 CA 证书。
分发不希望整个组织都信任的特殊用途 CA 或 PKI 的 CA 证书。
替换客户端根存储区中既有的商业根，以便限制信任证书的使用。 例如，您可能决定只信任给定商业根的电子邮件和安全 Web 服务器证书，但是不信任智能卡登录证书。
达到此目的的方法有多种：
在您的内部根和要信任的 CA 证书之间创建受限从属关系（也称为交叉认证）。 这要求您的其中一个内部 CA 对外部 CA 证书进行重新签名。 这样可有效地将该外部 CA 作为签名 CA 的受信任下级添加到您的内部 PKI 中。 您可以限制证书的类型，准确地限制证书的使用和策略、使用者名称的类型或者您将信任的颁发策略。
重要：限定从属或交叉验证是一个复杂的主题，也是最难以成功实现的方法。 请参阅本章末尾“更多信息”一节中的技术论文“Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003”。
创建证书信任列表 （CTL）。 这使您可以定义一个受信任根 CA 的列表，并指定信任这些 CA 的目的（如安全电子邮件）。 然后可以使用 Active Directory 组策略对象 （GPO） 部署 CTL. 虽然这种方法很方便，但它属 Microsoft 专有。 只有运行 Windows 2000 或更新版本的客户端才能使用 CTL. 此选项仅影响应用该 CTL GPO 的域中的客户端。
将根 CA 证书安装到 Active Directory 受信任证书颁发机构存储（位于配置容器中）中。 这会为林中的所有用户和设备在根 CA（以及所有从属 CA）中创建无条件的信任。 但在授予此类型的信任前应特别谨慎。 仅对在您自己的组织控制之下的 CA 使用此方法。
使用组策略将受信任根 CA 证书部署给用户或计算机的子集。 这类似于上一个选项，但能够让您更加确定谁和什么设备将收到受信任的根（即该 GPO 的目标用户或计算机）。 此选项仅影响应用该 GPO 的域中的用户。
使用 Microsoft 根更新服务。 此服务旨在使商业证书提供商能够轻松地向大量用户发布新的根。 如果您要管理您的受信任根 CA，应考虑在公司的所有系统上禁用此服务。
可以使用组策略来禁用第三方受信任根。 与列表中的其他项不同，这是一种限制信任而非增加信任的方法。 每台运行 Windows 的计算机（以及使用这些计算机的用户）都会继承一组默认安装的根。 （这在其他操作系统和许多平台上的 Web 浏览器中也很常见。）可使用组策略禁用这些根中的自动信任。 可以使用前面介绍的其中一种机制来有选择地重新添加您需要的受信任根（根据您的安全需要，附加或不附加限制）。
注：有些根证书无法禁用。 这是因为操作系统依赖它们来维护驱动程序签名策略等事项。 此组策略设置无法禁用这些必需的根。
本解决方案禁用了 CA 上的更新根证书服务。 您应当考虑在组织中的其他计算机上禁用此服务。 还可考虑使用组策略为所有域用户禁用默认的第三方根。 第 7 章“实施 PKI”对这些项进行了更详细的说明。
本解决方案中的 PKI 根 CA 证书是通过导入 Active Directory 分发的，下一节将作讨论。
根 CA 证书分发
根 CA 证书自动分发给 Active Directory 林成员。 通过将 CA 证书导入证书颁发机构容器中，林中所有域的成员（计算机和用户）都将该证书安装到了他们的本地受信任根 CA 存储中。 对于所有需要整林信任范围的内部根 CA，这是建议使用的方法。
通常，除内部根，还需要分发一些信任范围受限更多的根。 有关此主题的详细信息，请参阅本章中稍后的“扩展证书颁发机构基础结构”一节。
要将您的根 CA 证书分发给其他平台上或林之外的用户和计算机，您必须手动安装证书，或者使用其他方法将根证书分发给用户和计算机。
定义证书颁发机构角色
定义信任模型并选择根 CA 策略后，就可以规划 CA 基础结构的其余部分了。 为此，您必须定义 CA 要在您的组织中充当的不同角色。 可将 CA 配置为根 CA 或从属 CA. 而从属 CA 可以是颁发 CA 或中间 CA（中间 CA 指颁发 CA 和根 CA 之间的中间信任步骤）。
根 CA
根 CA 角色在任何组织中都非常重要。 它是您的组织中的所有用户和设备都明确信任的角色。 许多安全决策（例如，是否允许某人登录、是否信任电子邮件，或是否允许价值千万的证券交易）最终都依赖于这个根的安全性和提供其身份的私钥。 由于有这么多操作依赖于根，因此更改根密钥和证书可能非常复杂，并易于出错，可能会导致应用和用户的服务长时间中断。
因此，强烈要求尽可能保护根 CA 私钥。 实现此目的最佳的方法之一是将 CA 与网络断开，使其不易访问（实施此保护措施的同时应采取相应措施来限制对服务器的物理访问）。 可以通过专用的硬件安全模块 （HSM） 来进一步增强对 CA 密钥的保护。 这为脱机 CA 提供了额外的密钥安全，同时极大提高了联机 CA 的安全性。
本指南中定义的解决方案使用脱机根 CA.
重要：应考虑对根 CA 使用 HSM，以增强 CA 密钥的安全性。 您可在安装 CA 后添加 HSM，但在最初即进行此操作要简单且安全得多。 如果要以后安装 HSM，应当使用新的密钥续订 CA，即使许多供应商允许您导入现有密钥。
中间和颁发 CA
如果让根 CA 脱机，那么就不可能利用它进行日常的证书颁发。 要创建可用于进行日常证书颁发的 CA，根 CA 需要允许从属 CA 代表它颁发证书。 这样，从属 CA 就能够继承根 CA 的受信任属性，而不会使根 CA 密钥受到安全性威胁。
此过程可进一步延伸。 从属 CA 不是直接颁发证书，而是继续认证下一层 CA，以向最终实体（用户和计算机）颁发证书。 这不仅为根 CA 密钥提供了额外的安全层，还使得从属 CA 分支能够共同分担风险。 例如，一个中间 CA 可以认证内部颁发 CA，而另一个中间 CA 可以认证可以颁发外部证书的 CA. 此方法有下列优点：
有助于将 CA 泄露的危险限制在整个 PKI 层次结构的一个较小部分。
并能够为 CA 层次结构的所有分支实现不同的证书策略。
降低使用根 CA 密钥的次数，从而降低破解密钥的几率。
虽然附加的中间 CA 层可以增加 PKI 的总体安全性，但同时也增加了复杂程度、额外的硬件和软件成本以及管理开支（后者通常远远高于硬件或软件许可的成本）。 对于许多应用来说，其安全要求并不值得采用三层的层次结构。 特别在使用 HSM 保护 CA 密钥时更是如此。
本指南中定义的解决方案采用两层的层次结构。 本解决方案设计在良好的安全性与负担能力之间提供了一个可以接受的平衡点，同时为将来的证书应用提供了灵活性（有关实例，请参阅本章前面“定义证书要求”一节中的详细说明）。
注：有关政府或法律规定要求必须使用三层层次结构的讨论不在本指南的范畴之内。 这些要求显然优先于其他注意事项。
建议的 CA 层次结构
下图说明建议的层次结构。 当前实施包括根 CA 和一个颁发 CA. 颁发 CA 主要为计算机或用户颁发标准确定性（有时称为“技术”）证书以及为计算机颁发价值更高的证书。
图 4.2 证书颁发机构层次结构(点击小图看大图)
此设计允许您部署一个功能全面的 PKI，能够支持安全无线 LAN 身份验证 （802.1X），而硬件、软件和管理成本的费用相对较低。
注：您可以以多种方式扩展这个简单的基础结构设计，以适应不同要求。 “扩展 CA 基础结构”一节对此主题进行了讨论。
颁发 CA 将被初始配置为颁发下列类型的证书（如上图粗体框中所示）：
客户端身份验证 - 用户
客户端身份验证 - 计算机
IAS 服务器身份验证
前两个是标准证书，可以根据用户或计算机的域凭据自动颁发。 拥有这些证书而与使用者的绑定并不比拥有有效域用户名和密码而与使用者的绑定更牢固。 但是，使用证书代替域名和密码存在安全性和其他技术上的优势，注意这一点很重要。
IAS 服务器身份验证被归类为中确定性的证书，因为 IAS 服务器执行的功能是高安全级的。 颁发这种类型的证书通常包括对请求的有效性进行额外检查，并需要证书管理员的批准。
注：在后面的介绍创建此证书类型的构建章节中，禁用了需要证书管理员批准的要求。 这使得 IAS 服务器能够自动续订过期的证书，从而避免在证书过期时服务被禁用。 只要将足以诊断和审批证书请求的进程布置到位，就应当考虑启用需要证书管理员批准的要求。
CA 的硬件和软件要求
本节讨论 CA 的硬件和软件要求。
根 CA
根 CA 的硬件要求很低。 计算机规格满足运行 Windows Server 2003 的最低要求即可。 根 CA 硬件的重要特征是长期的可靠性和可维护性。 根 CA 通常驻留在寿命很长但大多数时间处于关闭状态的计算机中。 当然，当打开计算机电源时，它要能够稳定启动。 为对可能出现的硬件故障采取措施，您将需要能够方便地更换组件（可能在计算机型号停用几年后）。
考虑到这些，Microsoft 建议：
选择技术支持和长期硬件维护记录良好的知名计算机制造商。 询问在多长时间内可从供应商获得备用部件。
使用服务器而不是使用工作站或便携计算机硬件，这是因为前者标准化程度更高，并且变化的频率较低。
建议维持一个备件系统，使其可以在硬件发生故障并且不能短期内得到修复时承担起根 CA 的角色。
保留原始安装媒体、驱动程序和修补程序的副本，以便在系统出现故障时重建。
建议使用 HSM 以提高安全性。
根 CA 不需要 Windows Server 2003 企业版的附加功能。 因此，本指南中的解决方案使用 Windows Server 的标准版。