颁发 CA
虽然对颁发 CA 有一些性能要求，但由于这种 CA 的工作负载通常不高，因此，要求相对较低。 性能测试表明，即使在负载很高时，对于企业 CA 来说，其限制通常在于与 Active Directory 的交互（而不是 CA 本身）。 因此，硬件性能要求很低。 与根 CA 一样，可靠性和可维护性是选择硬件时的主要考虑因素。
证书服务使用与 Active Directory 相同的数据库技术，因此适用许多相同的性能标准。 对于大多数组织来说，一条好的原则是使用与 Active Directory 域控制器相同的硬件规范。
有关 CA 性能的详细信息，请参阅本章末尾参考的“设计公钥基础结构”一章中的“CA 容量、性能和可伸缩性”一节。
第 7 章“实施公钥基础结构”提供了建议的硬件配置。 除了适用于根 CA 的以上原则外，在指定颁发 CA 的服务器硬件时，Microsoft 还建议考虑下列事项：
使用 NIC 协作的冗余网络接口卡 （NIC）。
为了可以在独立的物理存储单元中存储 CA 日志，建议至少使用两个冗余独立磁盘阵列 （RAID 1） 卷。 这同样具有性能方面的增益，并提高了对硬件故障的适应性。
可以考虑使用三个 RAID 1 卷（而不是两个），分别在独立的物理卷上存储操作系统、证书服务数据库和证书服务日志，以获得更高的性能。
高性能 SCSI（小计算机系统界面）驱动器和控制器优于对等的 IDE（集成设备电路）产品，原因是性能更高，复原性更好。 除与 Active Directory 的交互操作外，磁盘子系统的性能可能是决定 CA 总体性能的最重要的因素。
应考虑使用 HSM 来得到证书颁发期间的附加安全性或更高的签名操作性能。
与根 CA 相反，颁发 CA 要求 Windows Server 2003 Enterprise Edition 的附加功能，以支持可编辑证书模板和用户证书自动注册。
使用多个颁发 CA 以提高服务适应性
本节讨论安装多个颁发 CA 的技术方面原因。 使用不同的颁发 CA 注册不同的证书类型还有一些安全和策略方面的原因。 本章后面章节将考虑这些原因。
硬件配置很低的单个颁发 CA 就已足够向上万客户端颁发前面所述的证书类型，因此不大可能仅因性能原因而需要多个颁发 CA. 但是，应考虑颁发 CA 的可用性要求是否意味着必须部署多个 CA 来注册同样的证书类型。
CA 的可用性问题与许多服务不相同。 客户端在使用或验证证书时无需联系 CA. 只有在要求 CA 进行下列操作时，客户端才直接与 CA 联系：
注册新证书。
续订证书。
吊销证书。
发行新 CRL.
续订 CA 证书本身。
下表详细说明各自的可用性要求。
表 4.8：CA 服务可用性要求
CA 服务
可用性要求
注册服务 ― 新证书
如果它可能阻碍新用户访问要求证书的网络或其他服务，这可能是一个重要的因素。 您必须评估从备份恢复 CA 所需的时间是否比在新用户可以注册证书前组织所能等待的时间要长。 大多数组织认为，等待 CA 恢复的成本低于管理额外 CA 的成本。 否则，您需要为相关证书类型配置多个颁发 CA。
注册服务 ― 续订证书
如果将自动续订用于所述证书类型，默认情况下，在上一次证书过期前六个星期，自动续订就会进行。 相反，从备份恢复 CA 的时间通常以小时计算。 手动续订的证书由所有者续订。 您可能想要建立一个自动警告系统，以便在重要证书需要续订时提醒所有者。
否则，可用性条件与注册新证书相同。
吊销证书
证书通常只能由颁发它的 CA 吊销 ― 其他 CA 无效。
如果吊销的时间十分紧急（即需要在恢复 CA 之前完成），只要具有要吊销的证书的序列号和 CA 私钥（还原到其他计算机上），就可在当前 URL 中插入吊销条目。
注意，CRL 通常有一天或一天以上的滞后时间。 除非 CA 的恢复时间长于下一次 CRL 发布的时间间隔，否则手动更新 CRL 的用处不大。
发布 CRL
CRL 对于 CA 是唯一的 ― 其他 CA 并不能使 CRL 发布的复原能力更强；而只能使 CRL 发布失败的影响降至最低（因为并不是所有颁发的证书都依赖于失败的 CRL）。
访问当前吊销状态对于许多证书应用来说是最基本的。 这意味着发布的 CRL 分布点 (CDP) 上必须有一个未过期的 CRL。 如果没有，则对吊销敏感的证书应用将失败。
CA 恢复时间应不长于上一个 CRL 过期与新的 CRL 发布之间的重叠期。 即使出现相反情况，仍然可以重新签署 CRL，并延长其有效期。 “操作指南”中介绍了此过程。
续订 CA 证书
其他颁发 CA 不能帮助完成此任务。
此操作不应太晚，以免 CA 恢复时间过于紧张。 即使是发生了这样的情况，仍可使用父 CA 密钥重新签署 CA 证书，延长其有效期。
注：在上表中，CA 恢复时间和 CA 可用性包括影响 CA 向最终用户提供服务的能力的任何事项。 这不限于服务器故障。 实际上，站点间的网络问题是一个可能性更高的服务故障原因。 在确定所需的服务可用性级别时，应考虑可能影响向用户交付服务的所有因素。
只要能很好地管理 CA 的备份和恢复，那么只有注册和一些续订要求会影响是否使用多个 CA 来提供服务复原的决策。 必须衡量这些服务不可用的成本和提供附加 CA 的安装和管理成本。
除可用性提高外，使用多个颁发 CA 还能提供更好的证书颁发性能，并使 CRL 的大小减半。 在本指南的解决方案中，这些因素都不重要。 本解决方案通过小心管理 CA 并通过足够的备份和恢复操作来处理复原问题。 因此，本解决方案只需要一个颁发 CA.
使用 HSM 保护 CA 密钥
使用 HSM 来保护所有 CA 的私钥，可以显著增强本指南提供的基本解决方案的安全性。 虽然这些措施通常很昂贵 ― 一般比 CA 服务器更昂贵 ― 但它们为您的环境带来的增强的安全性是显著的。 采取此措施使您可以将对 CA 密钥操作的访问仅限制为授权用户。 敏感的操作（如导出和备份 CA 密钥）通常使用多个智能卡保护。 这比仅信赖基于软件的密钥要安全一些，本地 Administrators 或 Backup Operators 组的成员可以从 CA 复制基于软件的密钥。
除了存在巨大的安全优势外，HSM 还可通过将 CPU 负载转移到专用的密码加速处理器来加速 CA 操作。
CA 安全性
本节讨论 CA 的安全性，包括操作系统和物理安全性、安全审核和监控以及使用角色委派 CA 的管理责任。
操作系统安全性
CA 的安全是通过使用 Windows 安全策略确保的。 这些设置基于“Windows Server 2003 安全指南”中的证书颁发机构服务器角色。
有关此角色中使用的设置的详细信息，请参阅第 7 章“实施公钥基础结构”。
根 CA 的安全设置是使用安全模板直接应用的，而颁发 CA 的设置是使用组策略应用的。
物理安全性
CA 服务器的物理安全性至关重要。 除非可以控制对这些服务器的基本物理访问，否则任何网络或操作系统安全都没有效用。
根 CA 应当放置在对服务器的访问受到严格控制的位置。 对 CA 的访问应当尽可能限制（每年二至三次），并且只有这些时候才需要打开服务器电源。 这意味着可将服务器存储在不具备服务器室的标准计算机设施的安全存储室。 例如，存储室不需要网络连接、复杂的服务器配套装置或特殊的电源和温度管理。
颁发 CA 也应放置在物理访问受到严格控制的位置。 物理安全性很重要，这是因为如果攻击者可以物理访问计算机，那么破坏安全性的方法就有很多种（超过通过网络可能进行的攻击）。 由于此服务器需要持续联机，因此应当存储在具有标准计算机服务器室设施（温度控制、电源管理、空气过滤以及消防等功能）的位置。
如有可能，应为两种服务器都选择可免受外部风险损坏（如火灾、水灾等）的位置。
同等重要的是，控制对备份、密钥材料和其他配置数据的物理访问，并确保它们的物理安全。 应将这些信息存储在服务器本身以外的位置，以便能够在整个站点不可用的情况下（如发生自然灾害或火灾时）进行 CA 恢复。
CA 的安全性管理
证书基础结构可能是价值非常高的资产。 具体价值取决于您的组织使用证书的用途 ― 不仅是现在，而是在未来五年或更长的时间里。 因此，您应当使用比安装其他 IT 基础结构更严格的安全和验证措施来安装、配置和管理 CA. 这些措施至少应与用于域控制器的措施同等严格。 有些情况下，可能需要更高的安全级别。
您对 CA 的信任取决于您对 CA 已得到安全的设置和管理的高度信心。 如果无法保证 CA 的私钥是否被秘密复制，将永远无法确定应当由该 CA 颁发的证书是否是赝品。
这种确定性或信任级别在事实发生后就无法轻易地增加了；必须从一开始就将此特殊状况构建在所有与 CA 的交互操作中。 例如，如果您有一些审核记录或其他证据证明所有对 CA 的访问都是合法的，则您的组织对于 CA 私钥未被泄露这一事实的信心将要高得多。例如，在 CA 上的所有管理操作都被除管理员以外的人员目击或有视频记录。 如果是脱机 CA，那么它从未与网络连接的事实可大大减少被泄露的可能性。
如果您的组织曾经因所颁发的证书的有效性而有过法律纠纷，则可能特别需要这种高确定性。 这些情况下，如果您具有 CA 未被泄露的证据，胜诉的几率就较高。 对此问题的全面讨论超出了本指南范畴，您应当咨询审核人员和法律顾问，以就该主题进行深入探讨。
以下是一些可用来显著提高 CA 的确定性的步骤示例：
确保 CA 的物理安全性，以便未经授权的人员无法访问 CA 硬件或备份媒体。
在有目击证人在场的情况下，执行所有安装和配置步骤 ― 记录主要的安装步骤，并让目击者连署，证明这些步骤已成功执行。 （另一种方法是视频录制安装过程，并将该视频副本委托给受信任方。）
在类似条件下执行根 CA 上的所有证书颁布和吊销操作。 最好所有对根 CA 的操作都应有目击证人在场。
确保所有对 CA 具有管理访问权的人员都各自有唯一可追踪的帐户。 审核所有对 CA 的操作。
建议对 CA 启用角色隔离。 （本章稍后将对此作详细讨论。）
对于根 CA 服务器来说，这些类型的措施特别重要。 视颁发 CA 所需颁发的证书的类型而定，它所需要的确定性低很多。 例如，如果 CA 颁发的证书价值不高（只是标准证书，如计算机和用户网络身份验证），则无需为该 CA 应用比域控制器更高的安全性。
只要根 CA 具有较高的确定性，您就可以选择在以后添加确定性更高的颁发 CA，以颁发价值更高的证书。 您可以与现有的标准 CA 一起维护高确定性 CA. 但是，如果根 CA 是在安全性相对较低的环境中安装和配置的，而后来希望颁发高价值证书，则很可能需要重新安装根 CA，或者创建新的根 CA.
安全监视和审核
在所有 CA 上都使用操作系统和证书服务审核。 为达到效果，您必须监视审核过程和所有可疑项。 有关证书服务审核事件条目的重要性的讨论，请参阅第 11 章“管理公钥基础结构”。
管理角色
证书服务使您可以极大程度地控制管理角色的委派。 本解决方案中利用了这一能力，在管理 PKI 的方式方面提供了较大的灵活性。 证书服务定义的各个核心管理论角色都是通过使用域安全组（或者，对于脱机 CA 来说，通过使用本地安全组）实现的。 此外，本解决方案中还定义了两个额外的角色和安全组，以协助将管理职责委派给 Active Directory 的 PKI 组件。
这些角色和您的组织中的不同 IT 人员之间并不一定是一对一的映射关系，了解这一点很重要。 大多数组织都允许同一个人承担多个可用角色。 将该人员添加到下表列出的任一或全部安全组，便可轻易地实现这一方案。 相反，如果您的组织的管理责任分隔更复杂，则已经可以使用这一功能来实现了。
下表所示为实现的角色和这些角色与安全组（实现时）的映射关系。
表 4.9：核心证书服务角色
角色名称
安全组
范围
描述
Enterprise PKI Administrator
Enterprise PKI Admins
Active Directory 林
负责整体 PKI ― 定义企业的证书类型、应用策略和信任路径等。
Enterprise PKI Publisher
Enterprise PKI Publishers
Active Directory 林
负责向目录发布受信任的根证书、从属 CA 证书以及 CRL。
CA Administrator
CA Admins
CA
负责 CA 配置。 通常与 Enterprise PKI Administrator 和 Administrator 角色中的人员相同。
可能会由多个 CA 管理员负责不同的 CA，前提是证书的使用需要。
Administrator
Local Administrators
CA
管理 CA 操作系统和服务器。 负责安装 CA 和续订 CA 证书。 通常与 CA Administrator 角色共享。
CA Auditor
CA
CA Auditor
CA
管理 CA 的审核事件日志和可审核事件策略。
Certificate Manager
Certificate Manager
CA
审批要求手动审批的证书请求和吊销证书。
可能有多个 Certificate Manager 负责不同 CA 的审批，前提是证书的使用需要。
Registration Authority或Enrollment Officer
没有定义
证书配置文件
这是 Certificate Manager 角色的扩展。 负责在带外 ID 验证之后批准和签署证书申请。
可以是人、IT 进程或设备（如指纹扫描仪和数据库）。
可以为不同的证书配置文件（模板）指定不同的注册颁发机构，并且可以支持多个 CA。
Key Recovery Agent
没有定义
CA
保存用于解密存档在 CA 数据库中的私钥的密钥。
CA Backup Operator
CA Backup Operator
CA
负责备份和恢复 CA 服务器以及确保备份媒体的安全存储。
这些安全组是作为域通用组来实现的，可以应用于颁发 CA 和目录。 对于根 CA 来说，等效组是作为本地组实现的（但是，对于脱机 CA 来说，没有 Enterprise PKI Admins 和 Enterprise PKI Publishers 的等效组）。 本解决方案假定同样的安全组将用于企业内的所有 CA. 如果这对您的组织不合适的话，对于 CA 而言，应当为每个属于 CA 的所有角色实施分离的组。 （显而易见，必须相应地重命名这些组，例如 CA Admins ― Issuing CA 1.）
由于本解决方案没有实施注册颁发机构（或注册官）和密钥存档及恢复，因此这些角色并没有确定的安全组。
可能需要强制分离 CA 的 CA 角色。 启用此选项时，任何属于多角色组的用户都不会具有所有角色组的特权。 本解决方案中未实施角色分离。
Active Directory 集成
可以这两种模式之一安装 CA：企业模式（或集成的 Active Directory）或独立模式。 这两种模式之间的主要区别在于企业 CA：依靠 Active Directory 存储配置信息；可以使用 Active Directory 作为注册颁发机构；可以自动将已颁发的证书发布到该目录中。 独立 CA 可以将证书和 CRL 发布到该目录，但是不依赖于 Active Directory 的存在。
有关这方面的详细说明，请参阅本章末尾的“更多信息”一节。
由于根 CA 是脱机的，因此您只能将根 CA 配置为独立服务器。 如果计划在您的环境中部署脱机中间 CA，情况也同样如此。
出于下列原因，颁发 CA 将配置为企业 CA：
本解决方案中使用的证书类型需要证书自动注册和自动审批。
解决方案中需要证书模板 ― 它们通过简化对多种证书类型的管理（通常跨多个 CA）而产生可观的效益。
IAS 需要 Active Directory 执行受信任证书映射，以便对无线客户端进行身份验证。 必须在 NTAuth 存储中注册 CA，才能允许此操作。
可以将证书自动发布到对应的用户或计算机对象（但本解决方案中不要求这样）。
CA 需要受信任来源，以便获取证书申请和颁发的证书中使用的使用者名称信息 ― Active Directory 可以从该目录中存储的用户和计算机属性提供此信息。
将来可能需要智能卡登录证书 ― 使用企业 CA 更容易实现。
注：尽管企业 CA 默认提供这些功能，您也可以通过正确配置的独立 CA 提供其中一些。 证书服务产品文档中对此进行了更详细的介绍。 请参阅本章末尾的参考。
在域中安装 CA
如果您的组织有一个多域林（甚至有多个林），则必须决定要将 CA 安装到哪一个或几个域。 您的决定可能受许多因素的影响，例如向不同域管理员委派控制的需要、影响向组织中的不同部分提供证书的国家或地区法规。
最常用的方法是将 CA 安装到林根域中或安装到专用域中，以用于管理目的。 应该将它们安装到可长时间保持稳定的域。 （安装后，您不能更新 CA 的名称、域成员身份和 DNS 域名。）还应避免将 CA 安装到不能保证计算机帐户的安全或完整性的域。 虽然将 CA 安装在同一个域便于集中式管理，但您不必这样做。
在本解决方案中，CA 服务器帐户（仅企业颁发 CA）安装在林根域中，或如果这是单一域林，则安装在此域中。
将证书实施声明映射到 CA
如果计划发布 CPS，必须确定 CPS 的范围。 可以为整个 CA 层次结构或为部分层次结构创建 CPS，也可以为每个 CA 创建一个 CPS.
后一选项给予您更多的灵活性，但是它也增加了管理多个 CPS 的费用。 标准做法是为具有共同证书策略、使用者类型和安全级别的每个 CA 或 每组 CA 创建一个单独的 CPS. 如果 CA 之间这些属性大不相同，您可能需要使用多个 CPS. 显然，如果您出于适应性和性能原因而部署许多相同的 CA，则这些 CA 应该具有相同的 CPS.
如上所述，创建 CPS 但不发布是合法的。 例如，如果感觉 CPS 包含的操作和安全信息具有内部性质，则可能需要避免向外部发布 CPS. 您还可以决定发布 CPS 的缩略版本，此版本列出 CA 的重要操作策略，但不公开任何内部操作细节。
如果决定发布 CPS 并希望在 CA 证书中公布其位置，则必须从国际标准组织 （ISO） 为您的组织分配的正式 OID 名称空间中获取证书策略的对象标识符 （OID）。 证书策略对组织是唯一的，因此需要全局唯一 OID 来标识它。
此 CP OID 将作为证书扩展编码到组织的每个证书中。 “证书扩展”是一种证书数据字段。 此扩展中包括一个 URL，指向颁发给定证书的 CA 的 CPS.
通常会加入文本形式的用户通知，该通知指示出证书用途或起源（但是这限制在 200 个字符，因此，显然它不能替代独立的 CPS 文档）。
有关证书策略 OID 和 CPS URL 如何编码到证书中的确切信息，请参阅本章末尾“更多信息”一节中的 RFC 3280“Internet X.509 Public Key Infrastructure Certificate and CRL Profile”。
获得 CP OID 并确定要发布 CPS 的 URL 之后，可以将它加入到 CA 证书中。 第 7 章“实施公钥基础结构”介绍了此过程。
支持 IT 基础结构
本解决方案中的 PKI 依靠其他基础结构服务来正确操作。 下图说明了主要基础结构 ― Active Directory 和 IIS ― 以及它们如何与 CA 和证书客户端交互。
图 4.3 CA 与 IT 基础结构的交互(点击小图看大图)
虽然图中未显示监视、警告和管理基础结构，但这些组成部分对于证书服务的成功操作也至关重要。 第 11 章“管理公钥基础结构”详细介绍了此基础结构。 以下各节描述了 Active Directory 和 IIS 为 PKI 提供的服务。
Active Directory
如前面的“Active Directory 集成”一节中所述，Active Directory 为 PKI 提供了许多不同的重要服务。 这些服务包括证书发布、证书注册、证书帐户映射以及信任和配置信息的存储。
所有这些服务自动提供给企业 CA. 联机独立 CA 也可以使用其中一些服务。 但是，脱机 CA 不能直接与 Active Directory 进行交互，从而存储和检索信息。
在本解决方案中，脱机根 CA 的 CA 证书发布到 Active Directory 的受信任根存储区中。 这将导致根 CA 证书自动分发到林中所有 Active Directory 客户端的受信任根存储区中。
根 CA 还可以使用 Active Directory 实现以下发布服务（虽然本解决方案中未使用）：
CRL 发布 ― 整个林中的域客户端可从已发布到 Active Directory 的本地域控制器检索 CRL.
交叉证书发布到域客户端 ― 发布到 Active Directory 的交叉证书自动分发到林中每个 Active Directory 客户端的本地证书存储区中。
颁发 CA 将 Active Directory 用于“Active Directory 集成”一节所述的所有服务。
将 Active Directory 用于非 Active Directory 客户端
在支持属于其他不受信任的 Active Directory 林或不属于任何 Active Directory 林的 PKI 客户端时，需要考虑一些事项。
如果想要允许这些类型的外部客户端使用轻型目录访问协议 （LDAP） 检索 CA 证书和 CRL，则必须考虑下列事项：
外部客户端要求为 CDP 和 AIA 路径配置明确 LDAP 主机名。 有关详细信息，请参阅本章后面的“配置 CDP 和 AIA 路径”一节。
默认情况下，外部客户端不会在 Active Directory 上执行匿名 LDAP 查询。 必须更改林的 dsHeuristics 值，并向 Anonymous 帐户授予明确访问权。 关于本主题的更多信息，请参阅本章末尾的“更多信息”一节。
警告：这将在林中的所有域控制器上允许匿名 LDAP（但是未经身份验证的客户端只能访问 Anonymous 帐户具有明确权限的项目）。 在进行此操作之前，仔细考虑允许对您的目录进行未经身份验证的访问会意味着什么。
外部客户端不会继承在该目录中配置的受信任根信息 ― 您必须使用一些其他方法配置此信息。
Internet 客户端的考虑事项
对于组织外客户端（如 Internet 客户端）的 CDP 和AIA 配置，也有一些重要的考虑事项。 本章中的“配置 CDP 和 AIA 路径”一节对此进行了介绍。
如果需要为 Internet 客户端提供证书查找，例如为支持电子邮件证书查找，则可能需要为 Internet 客户端创建单独的 LDAP 目录。 出于安全方面的考虑，Microsoft 强烈建议您不要使用上一节所述的方法对内部 Active Directory 林启用匿名 LDAP. 相反，应创建单独的 Active Directory 林，并使用 LDIFDE 工具、元目录产品（例如 Microsoft Metadirectory Services）或其他目录同步产品从内部林复制信息。
Internet 信息服务
IIS 为本设计中的 PKI 提供两种服务：
它发布 CA 信息，例如 CRL、CA 证书以及可能还有 CPS 文档。
它提供使用 Web 界面注册证书的能力 ― 虽然本解决方案中不使用此功能，但它对于 非 Windows 客户端特别有用。
使用 IIS 发布 CA 信息
在本解决方案中，根 CA 和颁发 CA 的 CDP 和 AIA 信息被发布到 Web 服务器。 使用 HTTP 发布使最大范围的客户端可以检索到需要的信息。
在用于此用途的颁发 CA 上安装 IIS 是很常见的，但并不总是最佳方法。 如果可以使用另一 IIS 服务器来发布 CRL 和 CA 信息，则改为使用另一 IIS 服务器。 尝试限制用户可以访问 CA 的方法，因为 CA 上的每个附加协议和服务都可能再次为攻击者提供攻击服务器的入口点。 在 CA 上使用 IIS 还可以避免 CA 由于维护而中断工作，因为对于许多客户端，这是唯一有效的 CRL 位置。
在“构建指南”中，颁发 CA 用于为 CRL 和 CA 发布宿主 IIS. 执行此操作的目的是简化构建过程和降低额外硬件的需求。 但是，Microsoft 建议，可能的话单独放置它们。
使用 IIS 注册页面注册证书
IIS 注册页面在几种情况下很有用：用于非域客户端注册、非 Windows 客户端注册或 Microsoft Internet Explorer 以外的浏览器客户端。
但是，CA 上不需要 Web 注册页面。 本解决方案中，它们默认安装在颁发 CA 上，但您可以改为安装在单独的 Web 服务器上（该服务器必须运行 IIS 5.0 或更高版本以支持 ASP 页）。 虽然这些注册页面简化了一些注册任务，但是如果您不需要，则不必安装。 有关安装和使用 Web 注册页面的详细信息，请参阅本章末尾的“更多信息”一节。
配置 CDP 和 AIA 路径
客户端需要访问最新的 CRL，以确定证书是否已被吊销。 客户端还可能需要检索 CA 证书，以验证最终实体证书是否链接到受信任根。 每个 CA 需要将一个或多个 URL 编码到其证书中，客户端可使用 URL 提供的位置获取有关这些证书的信息。
对每个 CA 配置的 CDP 和 AIA 取决于将使用证书的客户端类型。 例如，这些证书是否仅供您的 Active Directory 林的成员用户和计算机使用还是外部用户或设备也需要使用这些证书本章前面某一节描述了如何定义证书客户端。
根 CA
本解决方案的根 CA 配置如下：
CDP 和 AIA 的主（第一列出的）路径是 HTTP URL. 根 CA CRL 通常非常小（1 至 2 KB），而发布时间间隔很长（六个月），因此，在一个位置发布它对于客户端检索 CRL 不会有严重限制。
辅助路径配置为 LDAP URL，以创建 HTTP 位置的备份。 未使用 LDAP 主机名，所以，同一林中的客户端将从本地域控制器检索信息。 林外的客户端无法访问此位置。
在此配置下，Active Directory 林以外的客户端默认使用 HTTP 路径，所以它们可以使用 CA 和从属 CA 颁发的证书。
颁发 CA
本解决方案中的颁发 CA 进行了优化，供内部 Active Directory 客户端使用。 CA 的配置如下：
CDP 和 AIA URL 的主路径是 LDAP 目录路径。
CDP 和 AIA URL 中未指定 LDAP 主机名，这使客户端可以使用其默认 LDAP 服务器。 对于 Active Directory 客户端，默认 LDAP 服务器是它们的本地域控制器。 但是，其他 LDAP 客户端在查询这些 LDAP 路径时可能失败。
对于和 CA 同处一林的客户端，此配置是最佳的。 基本 CRL 按周发布，增量 CRL 按日发布。 由于这两种 CRL 的默认位置都是 Active Directory，客户端将从最近的域控制器检索它们。 这提供了复原能力并优化了网络通信。
设置 CDP 和 AIA 以支持外部客户端
对于属于其他 Active Directory 林或者不属于任何 Active Directory 林的客户端（例如路由器），前面的安排并非最佳。 由于这些外部客户端无法访问 LDAP CDP 和 AIA（颁发机构信息访问），外部用户在尝试检查吊销和 AIA 信息时，将遇到长时间延迟。 这些延迟可能导致这些外部用户的应用失败。
如果证书可能由 Active Directory 林以外的客户端使用，则必须将 CDP 和 AIA 值配置为使用 HTTP URL 作为主路径代替 LDAP URL.
要包括外部客户端使用的 LDAP URL，必须执行以下操作：
为 CDP 和 AIA 路径配置明确的 LDAP 主机名 ― 不能使用默认的空路径 （LDAP:///）。 要更改 CA 的 CDP 或 AIA 路径，需要重新颁发（续订） CA 证书。
按本章前面所述启用匿名 LDAP 访问。
Internet 客户端的考虑事项
如果计划在组织外分发证书以将它们用于 Internet 上，则还有其他考虑事项。
带有内部 LDAP URL 的证书可以提供有关内部 Active Directory 和 CA 结构及名称的信息。 要避免这样，则应该：
只将 HTTP URL 用于根 CA 和链中从属 CA 的 CDP 和 AIA 值。
从单独的 CA 颁发供外部使用的证书。 此 CA 只使用 HTTP CDP 和 AIA URI.
在两种情况下，都应该为 CRL 检索提供辅助 HTTP 位置，以便客户端在主位置不可用时可以回到此位置。
有关使用 CRL 和 CDP 的进一步讨论，请参阅本章末尾的“更多信息”一节中包含的参考。
扩展 CA 基础结构
“定义证书安全要求”一节讨论了按照安全级别和使用者类型分类的证书类别。 区分不同使用者类型的主要原因是很可能会有不同的证书策略和操作做法（如 CPS 中所述）应用于这些使用者类型。
通常，每个 CA 应用一个 CPS. 虽然在单个 CA 中可以容纳管理不同使用者类型的不同策略，但这会使 CPS 非常复杂且通常很难正确实施。 为颁发不同策略和安全要求涉及的证书而扩展此 PKI 的策略是为主要使用者类型创建其他颁发 CA. 下图中对此做出说明。
注：此图只是说明可能如何扩展前面的 CA 层次结构。 为了满足将来的需求，您的组织可能需要更复杂或更简单的层次结构。 应根据您的安全要求设计额外的 CA 和证书能力 ― 不存在绝对正确或绝对错误的 PKI 设计。 当研究如何扩展 PKI 以包括其他证书需求时，应该遵循此处为简单 PKI 设计列出的类似方法。
图 4.4 扩展 CA 层次结构
此图显示如何扩展本章前面提供的简单 CA 层次结构，以处理更广泛的证书要求。 新 CA 和证书功能在灰色背景下显示。 此图还说明高价值证书（密钥和锁符号）的使用，以及在用户证书 CA（内部和外部）联机后，它们将从第一个 CA 接管颁发标准用户证书的角色。
用于扩展 CA 基础结构的这个策略包含一些假设：
CA 基础结构管理将集中化 ― 也就是说，不需要按组织或地理划分来委派 CA 的控制。
在整个组织中使用通用证书标准 ― 也就是说，给定类型的证书的用途和策略通常在整个组织中已被接受和认可。
不需要与现有 PKI 的互操作性。
对于所示的不同证书类型（以及可能需要的任何其他证书类型），需要不同的安全级别和策略。
如果这些假设对于您的组织无效，那么您可能需要其他结构。 有关用来扩展 CA 基础结构的不同选项和方法的详细讨论，请参阅本章末尾的“设计公钥基础结构”参考。
限定从属证书
您可以使用创建的证书定义来定义证书模板和颁发证书，而不必进行任何自定义。 但是，在扩展 PKI 时，您可能需要通过限定颁发 CA 证书的委派来限制 CA 可以颁发的证书的范围。
在本章前面讨论的限定从属可用于在您的组织内控制信任范围和用途，方法是在您的 CA 基础结构与外部组织的 CA 基础结构之间创建交叉证书。 可以使用此技术限制您自己的 CA 层次结构中的证书类型和某些证书属性。 此主题的进一步讨论不在本章范畴之内。 有关此主题的详细信息，请参阅本章末尾的参考文章“Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003”。
本解决方案中的 PKI 不要求使用 CA 层次结构中的限定从属。
配置证书配置文件
本节讨论如何配置证书来满足本章前面定义的需求。
定义证书参数
对于需要的每个证书类型，应该为每种类型证书准备证书配置文件。 然后，可以将配置文件参数配置到证书模板中，从而控制将由您的 CA 颁发的证书类型。
注：独立 CA 不使用证书模板。 您必须通过以下方法创建请求：使用工具（例如 Certreq.exe）、使用 Web 注册页面中的表单或以编程方式构建请求。 如果是使用单机 CA，仍应为每个证书类型定义证书配置文件，并在构建单机 CA 的证书申请时使用这些配置文件。
证书配置文件定义包括所有下列内容：
模板名称和显示名称（应该为这些名称定义命名标准）
证书密钥长度
证书有效期
可选证书扩展
注册和续订策略
与有效期相关的策略
与应用程序使用相关的策略
与密钥使用相关的策略
与密钥存档相关的策略
证书授权
使用者名称创建
证书注册代理
密钥创建
密钥和 CSP 类型
密钥长度、有效期、密钥创建选项以及注册和授权策略都由本章前面说明的所需的证书安全级别和应用要求决定。
定义证书和密钥生存期
有很多因素影响证书生存期，例如证书类型、组织的安全要求、行业中的标准做法以及政府规定。 一般而言，密钥越长，支持的证书生存期和密钥生存期就越长。
对于密钥长度和密钥类型，有以下限定：
兼容性 ― 有些证书应用可能不支持长度大于 2048 位的密钥。 密钥类型也可能影响兼容性；通常，RSA 密钥的兼容性最好，而有些应用则可能需要其他密钥类型。 由于应用需要处理链中的所有证书，所以必须考虑链中所有 CA 的密钥长度和密钥类型兼容性。
性能 ― 与较短的密钥相比，较长密钥的签名和加密操作需要更高的处理能力。 因此，长于 2048 位的密钥一般不用于证书颁发率高的颁发 CA 上。
存储 ― 密钥越长，创建的证书越大，在证书数据库中需要的存储越多。 如果证书发行到 Active Directory，其存储要求还将提高。 备份大小和时间将成比例增加。
当选择证书和密钥生存期时，必须考虑密钥被窃取的容易程度以及被窃取的后果。 下列因素影响您为证书和密钥选择的生存期：
私钥长度 ― 密钥越长，越难破解，因此经过证明它们都有较长的密钥生存期。
CA 安全 ― CA 及其私钥越安全，安全生存期越长。
使用专门加密的硬件 ― 智能卡和 HSM 使私钥更安全，可选择较长的生存期。
对证书使用者的信任 ― 对于员工和内部计算机，允许的证书生存期可能比外部用户和计算机的证书生存期要长。
使用 CA 密钥签名的证书数量 ― 访问密钥的次数越多且 CA 公钥分发的范围越广，则密钥越可能受到攻击并可能被窃取。
下表显示了本解决方案中使用的 CA 和最终实体的密钥生存期和续订期。
表 4.10：证书和密钥生存期
证书使用者
密钥长度
密钥生存期
续订时间间隔
根 CA
4096 位
16 年
八年
颁发 CA
2048 位
八年
四年
最终实体
1024 至 2048 位
六个月到两年
有效期的 90%
就密钥长度而言，目前认为 1024 位密钥超出了实际的密码破译能力。 这些密钥的安全密钥生存期应该超过建议的两年最终实体值。 除非用于安全要求非常低的应用，否则使用 512 位的密钥通常不再安全。 因此，本解决方案中未使用 512 位密钥。
颁发 CA 密钥强度在安全要求和性能要求之间进行了折中。 此大小的密钥的当前密钥生存期大大超出了四年续订期。
根 CA 没有实际性能限定，所以密钥强度可以设置为最大值 16 千位。 出于兼容性原因，本解决方案中设置为远远低于此值的级别。 即使这样，4096 位密钥的安全密钥生存期仍大大超出了八年续订期。
所有 CA 都使用 RSA 密钥，虽然最终实体的密钥类型由它们的应用程序需求确定。
虽然可以续订具有相同密钥的证书，但是在正常情况下，不建议采用此操作。 本解决方案中，在每个证书续订时生成新的密钥对。
CA 颁发的证书的有效期不能超出颁发 CA 和一直到根的所有高级 CA 的剩余有效期。 例如，如果 CA 证书将在六个月后过期，则只能颁发最大生存期为六个月的证书。 因此，本解决方案规定 CA 证书将在证书生存期过半后续订。 CA 颁发的所有证书应该具有不长于颁发 CA 证书生存期的一半的有效期。
这使最终实体、颁发 CA 和根 CA 的嵌套最大有效期分别为四年、八年和 16 年。 在本解决方案中，最终实体证书的最大有效期为两年。 这允许引入附加中间 CA 层，而不会对证书生存期层次结构产生太大影响。
将安全要求映射到证书参数
下表列出了本章前面说明的证书类型以及每种类型的安全类别如何映射到证书配置文件参数。
表 4.11：证书参数
证书类型
颁发策略
审批方法
密钥
有效期
密钥存储
密钥导出
CSP
客户端身份验证 - 用户
低
自动（域授权机构）
1024
一年
软件
否
已命名
客户端身份验证 - 计算机
低
自动（域授权机构）
1024
一年
软件
否
已命名
IAS 服务器身份验证
中
手动（证书管理器）
1024
一年
软件
否
已命名
注：
“颁发策略”栏中列出的“低”策略是指证书服务中预定义的“低确定性”证书策略。 等同于本章前面所指的标准确定性或安全级别。
CSP（加密服务提供程序）栏中的“已命名”值表示应在模板中指定证书类型允许的 CSP，而不应留待客户端决定。 客户端计算机和服务器证书具有特定的 CSP 要求。
将证书要求映射到证书模板参数
应用程序通常希望以精确的方式配置证书。 它们可能要求以某种方式设置使用者名称的格式，以及包括特定应用程序策略 OID 或者使用特定颁发策略颁发证书。 如果没有其他内容，则应用程序至少需要正确定义密钥用途。 必须从应用程序所有者（或供应商）获取这些所有参数，以便定义证书配置文件。
下表所示为本解决方案中所需证书列表的应用程序需求。 这些表格说明了证书属性和 CA 参数（如证书模板中配置）。 未列出所有可能的属性。
注：下面详细说明的每种证书类型都严格基于某一种内置模板类型。 请勿编辑原始模块，而是复制内置模板并编辑副本来达到所需的设置。 这使您在需要时可以很容易地恢复到已知未修改的内置模板。
表 4.12：客户端身份验证 - 用户
证书参数
所需的值
证书模板名称
客户端身份验证 - 用户
Active Directory 发布
否
密钥用途
数字签名
密钥存档
否
密钥最大大小
1024
使用者名称
常用名称
使用者备用名称
用户主体名
应用程序策略/扩展密钥用途
客户端身份验证
加密服务提供程序 (CSP)
Microsoft Base Cryptographic Provider v1.0
Microsoft Enhanced Cryptographic Provider v1.0
来源模板
经过身份验证的会话
表 4.13：客户端身份验证 - 计算机
证书参数
所需的值
证书模板名称
客户端身份验证 - 用户
Active Directory 发布
否
密钥用途
数字签名
密钥加密
密钥存档
否
密钥最大大小
1024
使用者名称
常用名称
使用者备用名称
DNS 名
应用程序策略/扩展密钥用途
客户端身份验证
加密服务提供程序 (CSP)
Microsoft RSA SChannel Cryptographic Provider
来源模板
工作站身份验证
表 4.14：802.1X 服务器身份验证
证书参数
所需的值
证书模板名称
802.1X 服务器身份验证
Active Directory 发布
否
密钥用途
数字签名
密钥加密
密钥存档
否
密钥最大大小
1024
使用者名称
常用名称
使用者备用名称
DNS 名
应用程序策略/扩展密钥用途
服务器身份验证
加密服务提供程序 (CSP)
Microsoft RSA SChannel Cryptographic Provider
来源模板
RAS 和 IAS 服务器
创建证书模板
Windows Server 2003 中的 Active Directory 包含一组为许多常用功能预定义的证书模板。 当安装企业 CA 时，默认情况下，将它配置为颁发这些内置证书类型中的某些类型。 在 Windows Server 2003 Enterprise Edition 产品文档中可以找到所有内置模板的说明。 （有关准确信息，请参阅本章末尾的“更多信息”一节）。
在本指南所示的解决方案中，这些默认模板大多数已从 CA 删除；也就是说，从证书颁发机构管理控制台的模板文件夹中删除 ― 不能从目录删除模板定义。
如果预定义模板符合您的需要，则可以选择使用预定义模板，这些模板涵盖了大多数基于 Windows 证书的应用（如加密文件系统、VPN 身份验证及其他应用）。 如果需要颁发其他类型的证书，通常最好创建专门符合您的要求的模板。 如果使用预定义模板，而不了解它们的功能，则有启用不需要的功能的风险。 例如，原本用于简单客户端身份验证的计算机证书也可以用作 Web 服务器证书。
要创建新模板，应该查找与您的证书配置文件需求类似的预定义模板，然后复制该模板，作为新模板的基础。 配置模板是一个选择属性以与本节中定义的证书配置文件匹配的简单过程。
注：不能从头开始创建新模板；从现有模板制作副本，然后根据需要编辑。 必须始终从计算机模板中派生计算机模板，从用户模板派生用户模板 ― 两者不能互换。
当创建和修正模板时，应详细记录模板参数，将其作为配置管理系统的构成部分。
创建证书管理计划
为组织配置证书后，必须创建在整个证书生存期中管理证书的计划。 创建证书管理计划包括进行下列方面的决策：
如何处理新证书和证书续订请求
如何将证书映射到用户帐户
如何管理和分发 CRL
用于恢复加密数据的策略
选择注册和续订方法
可以使用一些不同的方法执行证书注册（也可能使用所有这些方法续订证书）：
Windows 自动注册。
使用证书注册向导的联机注册（通常从证书管理控制台启动）。
使用应用程序或脚本中的 CryptoAPI 或 CAPICOM 接口的联机注册。
使用 Certreq.exe 工具创建和提交申请，以及检索已颁发的证书。
注：前四种方法实际上只是同一联机注册接口的不同接口。
网页注册。
手动脱机注册（这包括使用以前定义的方法之一将请求生成为文件、将它发送到 CA、使用证书颁发机构管理控制台提交请求，以及使用管理控制台对其检索）。
所有这些方法都是有效的，适于在某些情况下使用。 本解决方案使用下列注册方法：
Windows 自动注册。 如果可能，首选此方法，以降低证书管理费用。 甚至可以在证书需要手动审批时（但不是需要注册代理签名时）使用自动注册。 即使不立即颁发证书，请求也提交给 CA，注册将在请求批准后完成。
手动脱机注册。 此方法用于根 CA 的所有证书注册和续订。
这些方法中的任何一种都无法满足更复杂的方案，例如，证书申请在提交给 CA 之前需要由第三方签名。 在大多数非 Windows 平台（例如路由器）上，也不支持基于 RPC 的联机注册。 在需要在证书申请中定义使用者名称或备用使用者名称（而不是让 Active Directory 生成它）的任何情况下，也不能使用自动注册。
要适应诸如这些的更高级需求，应该考虑使用下列方法之一：
创建要在客户端独立计算机上运行的 CAPICOM 脚本，例如作为登录脚本的一部分。
在命令或批处理文件中使用 certreq.exe 生成和提交请求，并检索和安装已颁发的证书。
使用 CAPICOM 创建自定义 Web（ASP 或 Microsoft ASP.NET）页面，以构建和提交请求。 使用后一技术，可以为广泛的客户端提供注册服务并可加入复杂的多阶段过程（例如审批请求需要多个签名时）。
将证书映射到身份
证书与证书中指定的使用者之间的映射是较大的主题，超出了本章讨论的范围。 但是，此主题有两个重要方面需要考虑：
在颁发证书之前如何确认证书使用者的身份？
如何从目录中提供的信息发现证书使用者的身份？
第一个问题涉及如何进行证书注册过程。 下一节“创建证书策略”将对此方面进行讨论。第二个问题涉及证书用户（应用和服务）如何将证书使用者的身份正确映射到可以使用的另一身份。 后一问题的示例有：
域控制器如何从用户的智能卡证书中识别用户，以便让用户登录到域中并构建访问令牌？
电子邮件用户如何发现希望向其发送安全电子邮件的收件人的证书？
大多数证书自动映射到 Active Directory 安全主体（用户和计算机），这是注册过程的构成部分。 Active Directory 定义证书的使用者名称和使用者备用名称，以便在证书和证书中命名的安全主体之间创建隐含的映射关系。 使用者备用名称包含用户的 UPN 或电子邮件名称，以及服务主体名称 （SPN），或者计算机或计算机进程的 DNS 主机名。 UPN 和 SPN 值在 Active Directory 林中是唯一的。 电子邮件和 DNS 名称应该是全局唯一的（虽然 Active Directory 不强制这一点）。 其他 Windows 服务（如 IIS 和 IAS）也可执行至用户或计算机身份的证书映射。
注：证书映射与证书发布无关。 证书映射表示证书的某个属性（通常是使用者备用名称）唯一地标识目录中的某个对象。 IAS 服务器可使用这一点来从提交的证书中确定用户或计算机的身份。 IAS 使用此隐含映射代替在目录中查找证书。 证书发布及其必然结果证书查询描述证书在目录中的实际存储位置，并将它作为用户或计算机对象的属性。 这样用户可以在目录中搜索某个人员，并检索属于该人员的证书。
也可以使用 Active Directory 用户和计算机管理控制台将其他证书手动导入或映射到用户或计算机对象。
相反地，也有许多不需要直接映射至目录对象的示例，包括以下各项：
主要标识符是网站的 DNS 主机名的 Web 服务器。
证书颁发到没有等同 Active Directory 的实体（例如其他组织中的路由器或用户）。
本指南的解决方案中的所有最终实体具有至 Active Directory 用户和计算机的直接（且隐含的）映射。
CA 是不需要映射到计算机对象的情况的特例。 但是，这些证书几乎总是映射到 Active Directory AIA 和受信任的证书颁发机构容器中的“证书颁发机构”对象。
创建证书策略
应该至少为每个证书安全类别（高、中和标准）定义证书审批方法，Microsoft 还建议为每个证书使用者类别（计算机、内部用户、外部用户）定义证书审批方法。 不可能需要定义比此级别更详细的策略。 将这些策略决策制成文档，作为证书策略声明和 CPS 的一部分。
使用了不同的证书策略来指示证书审批过程的类型和证书注册中使用的私钥安全级别。 可以（但非必须）使用 OID 将此编码到证书中，以代表不同的策略。 审批过程的严格程度应该反映正在颁发的证书的价值。 审批（或注册）过程的目标是提供适当的信心度，即相信证书的请求者是与证书的使用者相同的实体。 密钥安全强度是对私钥将仍保持私密以及为证书使用者单独拥有的信心度的衡量。
本章前面的“定义证书安全要求”一节中定义了本解决方案中的证书确定性级别。 通过添加与颁发的证书的确定性相对应的证书策略 OID，可以指示这些证书的确定性。 应用（和用户）可以使用该策略确定给定的证书信任度。
前面定义的三个确定性级别映射到 Windows Server 2003 中的三个预定义证书策略（在证书模板 MMC 中称为“颁发策略”）。 下表提供有关本解决方案中如何使用不同证书策略的详细说明。 应在证书模板中（至少在中确定性和高确定性证书中）加入策略 OID，以便识别确定性更高的证书。 没有证书策略的证书被视为标准确定性。
表 4.15：证书颁发策略级别
证书（颁发）策略
注册要求 最低密钥存储要求
低
（标准）
根据域身份验证的成功与否自动审批。
对于独立 CA，这是未经身份验证的审批的级别 ― 即 CA 在未对请求者执行任何检查（或仅执行最低检查）的情况下颁发证书。
软件密钥
中
证书管理员审批。
必须在策略中定义证书管理员在审批证书申请之前必须执行的检查类型。
软件密钥或硬件密钥。
如果使用软件密钥，则考虑使用强密钥保护，除非应用程序不能使用此保护。 （例如，计算机证书不能使用强密钥保护）。
高
指定的注册官签名和证书管理员审批。
必须定义注册官和证书管理员在审批请求之前必须执行的检查类型。
硬件防篡改令牌。
例如，用户的智能卡或通用串行总线 (USB) 加密令牌，或计算机的 HSM。
注：如果定义更多或更少的证书策略和确定性符合组织的需求，则完全可以这样做。
定义证书吊销策略
在某些情况下，可能需要在证书的生存期结束之前使证书无效。 创建证书吊销策略包括下列任务：
定义保证证书吊销的条件。
选择 CRL 发布位置。
选择打算使用的 CRL 类型。
为 CRL 的发布建立时间表。
部分证书策略将包括定义保证证书吊销的条件。 这可能因各种证书而异，并且很可能因证书的确定性和使用者类型不同以及 CA 不同而异。
还应记录证书吊销时如何使用吊销原因代码。 下表描述了不同的原因代码。
表 4.16：证书吊销代码
原因代码
描述
密钥泄露
证书的私钥泄露（或怀疑泄露）。
CA 泄露
CA 的私钥泄露（或怀疑泄露）。
附属更改
使用者已经移动到另一组织。
被代替
已颁发取代此证书的新证书。
操作停止
CA 不再运行。
证书保留
证书使用需要临时挂起（例如，如果用户忘记将智能卡放在何处，但不确定是否丢失）。
未指定
其他代码未涉及的任何原因。
重要：应避免使用“证书保留”原因代码，除非情况表明确实需要使用。 如果先保留证书然后再发布，则不可能在给定的时间确定证书的吊销状态（从而无法确定此证书所做的任何签名的有效性）。
作为吊销过程的一部分，应该确保对下列问题的回答进行记录。 这些问题通常存储在更改管理或事件管理日志中：
吊销此证书的原因是什么？
谁请求吊销此证书？
您是否再次需要此证书（例如用于签名的验证和消息的解密）如果是这样，则需要何种证书（例如用于签名的验证、消息的解密、正常用途）？
对必须以管理员身份履行证书吊销的人员是否有特殊要求（例如是否必须是证书管理员）？
在吊销证书时，是否有任何可供组织使用的、必须遵循的书面操作过程（例如备份）？
还有许多控制证书吊销的技术参数。 Microsoft 也建议将这些参数作为 CA 策略的一部分记入文档。 下表中的参数用于本解决方案的根 CA 和颁发 CA.
表 4.17：根 CA 证书吊销参数
参数
选定的值
原因
CRL 发布位置 (CDP)
内部 Web 服务器的 HTTP 路径
发布到 Web 服务器上允许备份到 LDAP 位置，且允许非 LDAP 客户端访问 CRL。
Active Directory CDP 容器的 LDAP 路径
发布到所有域控制器上允许所有域用户轻松地进行本地访问。
CRL 类型
仅基本 CRL
由于颁发的证书数量很少，因此使用增量 CRL 没有意义。
发布时间表
六个月
这使吊销颁发 CA 证书变得很困难，所以它需要对颁发 CA 安全性有信心。 但是，这种长的时间段会使根 CA 的管理降至最低。
CRL 重叠期（发布新 CRL 与 CRL 过期之间的时间间隔）
10 天
这允许在从根 CA 检索新 CRL 时有一定误差幅度。
表4.18：颁发 CA 证书吊销参数
参数
选定的值
原因
CRL 发布位置 (CDP)
Active Directory CDP 容器（同时用于基本 CRL 和增量 CRL）的 LDAP 路径
发布到所有域控制器上允许所有域用户轻松地进行本地访问。（请参阅后面有关将增量 CRL 发布到 Active Directory 的注释。）
内部 Web 服务器的 HTTP 路径
发布到 Web 服务器上允许备份到 LDAP 位置，且允许非 LDAP 客户端访问 CRL。
CRL 类型
基本 CRL
增量 CRL
增量 CRL 在这种情况下非常有用：为要发布的吊销信息提供相对较短的滞后时间的同时，优化 CRL 检索流量。
发布时间表
基本 CRL ― 七天
此时间间隔需要足够短，这样，不了解增量 CRL 的系统仍可以接收相对较新的吊销信息。
增量 CRL ― 一天
对于可以使用增量 CRL 的现代客户端，它提供相对较短的吊销滞后。
基本 CRL 重叠期（自新 CRL 发布到旧 CRL 过期的时间间隔）
四天
这允许在无法按时发布基本 CRL 时 CA 恢复可以有一定的误差幅度。 选择四天的原因是预料这样一种糟糕的情况：CA 在周末假日的星期五晚上出现故障，而在下星期二之前一直没有人通知。
增量 CRL 重叠期
1 天
增量 CRL 对于服务并不关键，所以如果增量 CRL 发布失败，也不是灾难性的。 进行这样的设置，以使重叠时间大于 Active Directory 复制滞后时间。
注：由于使用的增量 CRL 的寿命相对较短（一天），必须确保最大 Active Directory 复制滞后时间小于增量 CRL 发布期的 50%. 否则，这会导致证书客户端使用旧的吊销信息，且由于网络带宽有限可能对到站点的目录复制流量产生负面影响。 将增量 CRL 重叠时间的值设置为大于在整个林中复制目录信息所花费的最长时间。
如果 Active Directory 滞后时间大于此值或者您不想要额外的目录复制流量，则加长增量 CRL 发布期或避免将增量 CRL 发布到目录。 如果更改增量 CRL 位置，则必须颁发新的基本 CRL.
当使用 HTTP 位置代替 LDAP URL 发布增量 CRL 时，复制滞后时间通常无关紧要。
规划密钥和数据恢复
密钥恢复和数据恢复超出本解决方案的范畴。 如果需要恢复其中之一或两者都恢复，则必须仔细规划和管理，以避免数据丢失和防止加密数据的疏忽泄露。
应阅读 Windows Server 2003 部署工具包中的有关“规划数据恢复和密钥恢复”和“设计公钥基础结构”的章节，以及 Microsoft 技术论文“Windows Server 2003 中的密钥存档和管理”。
总结
本章介绍了安全无线 LAN （WLAN） 的公钥基础结构 （PKI） 的设计过程。 因为许多组织将来很可能将 PKI 用于其他应用，因此在设计本指南中详细介绍的 PKI 时融入了这种思路。 本章介绍的设计非常灵活，可以进行扩展以满足将来的各种需求。 您可以借助此处的信息来设计 PKI，使它足以满足比 WLAN 应用所要求的更严格的安全标准。
本章描述的设计决策将在“构建指面”和“操作指南”中用来实现 PKI. 解决方案指南的第 7 章和 11 章对此信息进行了详细说明。
在“规划指南”的其余各章中，您将了解本解决方案的其他核心组成部分的设计 ― RADIUS 基础结构（使用 IAS 实现）和 WLAN 安全基础结构。
