摘要
Microsoft® Windows® 2000 证书服务提供集成的公钥基础结构 (PKI)，它使客户能够通过 Internet、Extranet 和 Intranet 安全地交换信息。本文描述如何优化 PKI 部署和 PKI 问题诊断，还提供了 Windows 2000 证书服务的疑难解答。
目录
引言
优化 PKI 部署
Active Directory 复制造成的滞后时间
自动注册和组策略造成的滞后时间
证书模板造成的滞后时间
CRL 生存时间对证书吊销的影响
卸载 CA 时保持良好的自动注册行为
卸载根 CA
卸载从属 CA
Certificate Publishers 组
DSStore - Windows 2000 PKI 的新工具
激发自动注册事件以加速 PKI 进程
管理 Active Directory 中的企业根
检查域控制器证书的状态和有效性
检查智能卡证书的状态和有效性
列出企业 CA 的有关信息
列出计算机的证书信息
列出域中计算机对象的信息
向 Windows 2000 PKI 添加非 Windows 2000 CA 或脱机 CA
用 DSStore 解答证书链的疑难问题
DSStore 报告的常见链接错误
验证域控制器证书
验证智能卡证书
智能卡登录的错误和修正
Error: Status insufficient resources
Error: Revocation server offline
Error: Certificate has been revoked, but still can be used for smart card logon
Error: Client credentials could not be verified
Error: The security database on the server does not have a computer account for this workstation trust relationship
Error: Invalid Handle
Error: The network request is not supported
Error: A certificate chain processed correctly, but terminated in a root certificate which is not trusted by the trust provider
Enrollment Errors and Fixes
Error: Windows could not find a certification authority to process the request
Error: Certsrv web pages inaccessible, and Virtual Roots do not show up in Internet Services Manager
Error: Enrolling for smart card through enrollment station web pages fails with "A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider"
Error: Configuration information could not be read from the domain controller, either because the machine is unavailable, or access has been denied
Error: This operation returned because the timeout period expired
Error: The RPC server is unavailable
Error: Invalid Parameter
小结
其它信息
引言
Microsoft® Windows® 2000 证书服务用于创建管理 Windows 2000 公钥基础结构 (PKI) 的证书颁发机构 (CA)，它可以验证和鉴别电子交易中所涉及的每一方的有效性。这种技术使得在开放网络上（如 Internet、Extranet 和 Intranet）进行安全的信息交换成为现实。本文的重点是为实施和支持 Windows 2000 PKI 的系统管理员提供信息。
本文提供了用于 Microsoft Consulting Services (MCS) 和 Microsoft Product Support Services (PSS) 的指南，旨在诊断在 Windows 2000 目录林中部署 PKI 时存在的问题并排除故障。文中包括与 DSStore（一种有助于确定并解决智能卡登录和 PKI 问题的 Windows 2000 资源工具包工具）有关的详细信息和策略，这些策略用来对智能卡登录和证书注册错误消息作出响应并解决问题。在下面的章节中将讨论以下主题：
- 优化 PKI 部署
- DSStore - Windows 2000 PKI 的新工具
- 智能卡登录的错误和修正
- 注册的错误和修正
本文假定您已经熟悉白皮书“Windows 2000 证书服务”，它解释怎样设计和部署 Windows 2000 证书服务的 PKI。还不熟悉密码系统及 PKI 概念的读者应该从阅读“密码系统和 PKI 基础”白皮书着手。您可以在本文结尾“其它信息”部分找到两篇白皮书的链接。
优化 PKI 部署
有些注意事项可能会影响 PKI 实现的良好性能。理解下列主题有助于优化 PKI 部署：
- Active Directory™ 复制造成的滞后时间
- 自动注册和组策略造成的滞后时间
- 证书模板造成的滞后时间
- CRL 生存时间对证书吊销的影响
- 卸载 CA 时保持良好的自动注册行为
- Certificate Publisher 组
关于设计 CA 层次结构和部署证书服务的其它信息，请参见“Windows 2000 证书服务”白皮书中的“Windows 2000 中的 PKI 设计和部署”部分（在“其它信息”中可以找到它的链接）。
Active Directory 复制造成的滞后时间
Windows 2000 企业 CA（与独立 CA 一样，参见白皮书“Windows 2000 证书服务”中的描述）依赖于 Active Directory 中的容器和对象，因此也遵循 Active Directory 复制的规则。例如，如果您正更改一个证书模板的任意访问控制列表 (DACL)1，您实际上正在更改一个单独域控制器上的对象的安全描述符2。您正在进行 DACL 更改的对象位于由以下可分辨名称确定的容器中：
CN=Certificate Templates,CN=Public Key Services,CN=Services, CN=Configuration,DC=mydomain, DC=com
这一更改在给定的 CA（或特定的客户机）上生效以前，必须跨企业复制到 CA（或客户机）正在从其接收信息的域控制器上。通常情况下，这发生得较快，但是在某些复制拓扑中（比如在不间断的 WAN 连接隔离的两个站点之间 - 见下例），花费的时间可能很长。任何管理操作都要考虑到这种滞后时间。
此外，在某些复制拓扑中，很可能以容器或对象冲突结束，结果就将创建有 CNF <some #><冲突公用名> 前缀的新容器或对象（CNF 代表冲突）。这种冲突造成的最常见问题表现为：在域中安装第一个 CA 时，证书模板对象上出现错误（尤其是在多站点企业中）。
对于证书模板冲突的情况，只须用 Active Directory 站点和服务管理单元删除带有 CNF 标记的证书模板对象即可。
关于 Windows 2000 网络中 Active Directory 复制的全面阐述，请参见“其它信息”中“Active Directory 体系结构”白皮书的链接。关于 Active Directory 复制怎样与 Windows 2000 证书服务证书吊销列表 (CRL) 相互作用的详细信息，请参见“Windows 2000 证书服务”白皮书中的“证书吊销列表”小节。关于复制的详细技术讨论，请参见“其它信息”中 Web 文档“Active Directory 复制”的链接。
示例方案： 在慢速 WAN 链接所分隔的多个站点中部署 PKI
在与慢速 WAN 链接连接的多个站点中部署 PKI 时，出现了一个引人关注的管理问题。这一部署方案是处理布局的一种可能的方式，布局中慢速或不连续的站点间带宽会禁止站点 1 的用户与站点 2 的 CA 之间的 DCOM 或 HTTP 连接。
这一小节讨论的理论部署假定企业包括两个站点，由一个不连续的 56K WAN 链接隔开。它还假定每个站点都包括一个企业 CA。要使这一策略能够工作，下列五个条件必须为真：
- 站点 1 中的所有用户和计算机都是名为 Site 1 Requestors 的组的成员。
- 站点 2 中的所有用户和计算机都是名为 Site 2 Requestors 的组的成员。
- 站点 1 中的所有计算机都是名为 Site 1 Computers 的组织单位 (OU) 的成员。
- 站点 2 中的所有计算机都是名为 Site 2 Computers 的 OU 的成员。
- 站点 1 和 2 都包括全局编录服务器。请注意，如果站点间的 DCOM 连接不可用，Windows 2000 企业 CA 需要在每个站点都有一个全局编录服务器。（Windows 2000 操作系统的全局编录是保存在一个或多个域控制器上的数据库，它在登录用户、查询和复制中发挥重要的作用。）
要限制站点 1 中的用户和计算机，使其只能根据站点 1 企业 CA 注册，请执行下列步骤：
- 启动站点 1 企业 CA 的证书颁发机构管理单元。
- 右击 CA，然后选择属性。
- 选择安全选项卡。
- 对已验证用户，清除注册复选框。
- 单击添加按钮。
- 将需要从站点 1 请求证书的用户和计算机加入每个企业 CA 的 DACL 列表，并清除注册复选框。
- 等待站点间的复制生效。
- 对 Site 2 Requestors 重复步骤 1-7。
如果您希望强制自动注册只在站点边界3内发生，请执行下列步骤：
- 为 Site 1 Computers OU 创建一个新的组策略对象 (GPO)。（关于怎样使用 Windows 2000 组策略的详细信息，请参见“其它信息”中“组策略”白皮书的链接。
- 运行“自动证书申请设置”向导，为站点 1 企业 CA 创建自动注册对象。
- 对 Site 2 Computers OU 重复步骤 1-2。
自动注册和组策略造成的滞后时间
在证书服务的环境中，最重要的滞后时间类型是与自动注册事件相关的类型。当自动注册事件发生时，会触发若干个操作：
- 验证和重新注册。对照自动注册对象验证当前的证书，如果有必要则重新注册。证书吊销、证书过期、证书模板的用法发生变化或者自动注册对象中的颁发者已改变，这些情况下均需要重新注册。
- 下载根证书。根证书从基于 Active Directory 的企业根证书存储区下载到本地企业根证书存储区。（关于存储区的描述，请参见白皮书“Windows 2000 证书服务”附录 A 中“基于 Active Directory 的企业根证书存储区”的部分。）
- 下载企业 CA 证书。 企业 CA 证书从基于 Active Directory 的企业证书存储区下载到本地证书存储区。
- 下列事件触发计算机的自动注册：
- 组策略事件的激发。只有成功应用组策略之后，组策略事件的激发才会触发自动注册。只有应用于所讨论计算机的任何组策略有所更改时，策略才会得以应用。
- DSStore - 激发。可以使用 DSStore 实用工具手动地激发事件（请参见“DSStore - Windows 2000 PKI 的新工具”部分）。
- 重新启动之后。 只要计算机重新启动，就会自动地触发自动注册。
- 每隔八个小时。每隔八个小时，自动地触发自动注册。
下面示例用于说明自动注册滞后时间会对域的服务器或工作站造成何种影响：
证书模板造成的滞后时间
一个组织的服务器和工作站还会感受到与证书模板相关的滞后时间。证书模板信息被维护在一个缓冲区里，有 10 分钟的生存时间。这种缓存信息的例子包括 DACL 和密钥用法（密钥用法指定证书的应用对象）。如果这一缓存超时，就会在注册过程中从 Active Directory 中更新（像上面描述的，Active Directory 又有复制造成的本身的滞后时间）。
此外，CA 还缓存证书模板信息，它在短期内可能没有与注册人的证书模板缓冲区中的 DACL 完全同步。因此，对特定的证书，即使注册人有适当的权限来注册，证书模板上的 DACL 更改也不总是在应用后立即生效。
CRL 生存时间对证书吊销的影响
如果与证书相关的私钥被泄露，标准的做法是吊销该证书。吊销的证书会出现在证书颁发者的 CRL 中。CRL 会定期发行到若干个场所（例如 Active Directory、Web 站点或文件共享）。每个 CRL 有一个与其发行周期大致相同的有效生存时间。Windows 2000 CA 的默认发行周期是一个星期。Windows 2000 CA 还允许管理员配置每隔多久发行 CRL（这样会产生可定制的 CRL 生存时间）。
当应用程序验证一个证书时，它可以选用 CRL 中的信息以确定是否为特定的目的接受特定的证书。例如，如果一个 Web 服务器请求安全套接字层 (SSL)4 客户身份验证，它可以检查以确保客户证书不出现在其颁发者的 CRL 中。
大多数 Windows 2000 功能（包括智能卡登录）的 CRL 检查使用 Microsoft 加密应用程序编程接口 (CryptoAPI) 2.0 证书链接引擎 API。它的一个潜在副作用是，链创建过程中提取的 CRL 被缓存在用户或计算机的环境中5，保存期为 CRL 的生存时间。因此，如果对 CRL 进行了添加或更改，这些更改在 CRL 本地缓存的复本过期之前不会反映在其它计算机的链创建过程中。因此，Microsoft 推荐：负责颁发智能卡登录和智能卡用户证书模板 CA 的 CRL 生存时间应该尽可能短（比如，24 小时）。使用较短的 CRL 生存时间会明显地使智能卡登录证书吊销快速生效。
此外，如果网络通信量是一个考虑因素，则可以将这个 CRL 生存时间较短的 CA 所颁发的证书模板类型限制仅颁发智能卡登录证书。这样做可确保与这个 CA 有关的重复的 CRL 提取和验证只发生在登录操作中。
卸载 CA 时保持良好的自动注册行为
有几条经验法则，可以在从域中删除企业或独立 CA 时保证 PKI 的无故障运行。应根据正在卸载的 CA 的种类确定最佳做法。
要点 如果一个 CA 已被卸栽，它将不再发行 CRL，而且证书链检查通常会返回一个错误，说明吊销服务器处于脱机状态。这一错误在某些情况下有效（例如，对一台膝上计算机从网络断开的情况），并且不触发自动注册以获取刷新的证书。在域控制器上这种情况可能是个问题，在进行智能卡登录的工作站上，它的证书可能由于过期的 CRL 而无法验证。
如果不采用下面两小节描述的步骤，则可能需要从域控制器删除自动注册的证书，这样才能使智能卡登录在一个域上正常工作。请参见 “智能卡错误和修正”部分中的“错误：吊销服务器脱机”，以及“验证域控制器证书”部分。
卸载根 CA
要卸载根 CA, 必须将根证书从 Windows 2000 信任构造中删除。要做到这一点，执行下列步骤：
- 将根 CA 证书从任何手动创建的组策略对象中删除。若需具体指令，请在 Windows 2000 联机帮助中查找“公钥策略”。
- 通过在命令行提示符执行下面的命令，将根 CA 证书从基于 Active Directory 的企业根证书存储区中删除：
dsstore <根域的 DN> -del
- 最后，检查控制台菜单并删除对应于根 CA 的证书。域中的所有计算机都将在自动注册事件的下一次激发时被告知该变更。可以通过从命令行提示符运行 dsstore -pulse，加速这一过程。
卸载从属 CA
当从属 CA 被卸载时，证书应该由其颁发者吊销。应通过颁发 CA 的证书颁发机构管理单元执行这一手动吊销。
在企业中应用两层或三层 CA 层次结构能简化管理，因为使用这一配置意味着您有一个安全的脱机根 CA，它的安全性不会被损害，并且可以在卸载从属 CA 之前吊销它们。
Certificate Publishers 组
所有企业 CA 都在安装过程中加入 Certificate Publishers 组（Windows 2000 提供的一个组）。默认的用户对象 DACL 允许 Certificate Publishers 组对大多数用户对象上的 userCertificate 和 userCert 属性进行“写”访问（例外请参见下面的项目符号）。这允许您向用户对象发布某些证书类型。当使用这些功能时请牢记下列注意事项：
DSStore - Windows 2000 PKI 的新工具
DSStore 是一个随 Windows 2000 资源工具包一起提供的新工具，用于帮助管理基于 Active Directory 的公钥结构。准确地讲，它用于诊断 PKI 和智能卡登录问题。本节分为下列小节，分头描述 DSStore 的功能：
- 激发自动注册事件以加速 PKI 进程
- 管理 Active Directory 中的企业根
- 检查域控制器证书的状态和有效性
- 检查智能卡证书的状态和有效性
- 列出企业 CA 的有关信息
- 列出计算机的证书信息
- 列出域中计算机对象的信息
- 向 Windows 2000 PKI 添加非 Windows 2000 CA 或脱机 CA
- 用 DSStore 解答证书链的疑难问题
激发自动注册事件以加速 PKI 进程
用法： dsstore -pulse
通过激发自动注册事件，可以初始化三个进程：
- 从 Active Directory 下载企业根。
- 从 Active Directory 下载企业 CA 证书。
- 触发证书的自动注册。
关于这些事件的详细信息，请查见前面名为“自动注册和组策略造成的滞后时间”的部分。
管理 Active Directory 中的企业根
用法： dsstore <根域的 DN（必需）> [-display | -del | -addroot]
当企业管理员（或根域的域管理员）在网络中安装根 CA 时，它的证书自动地存储在 Acitve Directory 中的企业根证书存储区中。（关于根证书的位置，请参见白皮书“Windows 2000 证书服务”附录 A 中“基于 Active Directory 的企业根证书存储区”的部分。）
这一选项允许管理员显示、删除或添加 Active Directory 中企业根证书存储区中的证书。将在后面“向 Windows 2000 PKI 添加非 Windows 2000 CA 或脱机 CA”一节中更详细地讨论添加根的内容。
检查域控制器证书的状态和有效性
用法： dsstore [-domain <目标域>] -dcmon
这个命令允许管理员检查域控制器证书是否存在及其有效性。运行时，此命令提供下列四个选项：
1. Display Displays DC certificates (default)
2. Chain Check chaining on DC certificates
3. Delete all Deletes *all* DC certs on all DCs
4. Delete bad Deletes *all* KDC certs which do not chain
- Display 选项只显示在特定的域中每个域控制器拥有的域控制器证书。
- Chain 选项显示在特定的域中每个域控制器的证书链状态。
- Delete all 选项在特定的域中从所有的域控制器删除所有的域控制器证书。
- Delete bad 选项只删除那些没有正确链接的域控制器证书。
注意 最好在一个成员服务器或工作站上运行这个命令，因为如果从域控制器运行这个命令，链失效可能会被掩盖（特别是如果域控制器上安装了 CA）。
检查智能卡证书的状态和有效性
用法： dsstore -checksc
这个命令必须在已配备可运行的智能卡读取器、且已插入智能卡的计算机上运行。它可以验证智能卡子系统是否正在运行，并且与智能卡证书有关的证书链是否正确。
详细信息，请参见后面名为“用 DSStore 解答证书链的疑难问题”的部分。
列出企业 CA 的有关信息
用法： dsstore -tcainfo
可使用这个命令显示 CA 名、DNS 名和证书类型。这里是命令输出的示例：
这个项目显示域上 CA 的名称：
CA Name: W2K NTDEV Ent User CA =============================
这个选项显示 DNS 计算机名（如果不能用这个名称成功地 ping CA，注册将失败，有可能伴随错误消息“The certificate authority cannot be reached”）：
Machine Name: w2kuserca.ntdev.microsoft.com
这一部分显示特定 CA 可以发布何种类型的 CA 以及一个用户能否访问那个 CA。例如，下面显示的用户不能访问管理员证书类型：
:: Supported Certificate Templates ::
CT #1 : User Signature Only
CT #2 : Authenticated Session
CT #3 : Code Signing
No Access!
CT #4 : Trust List Signing
No Access!
CT #5 : Enrollment Agent
No Access!
CT #6 : EFS Recovery Agent
No Access!
CT #7 : Basic EFS
CT #8 : Subordinate Certification Authority
No Access!
CT #9 : Administrator
No Access!
CT #10 : User
#CTs from enum: 10
备注 可以使用 Active Directory 站点和服务管理单元更改证书类型上的 DACL。
列出计算机的证书信息
用法： dsstore -entmon <计算机名>
要点 确保对这个选项使用 SAM 风格的计算机名，也就是 MyDomain\MyMachine$。
这个命令必须由管理员在目标计算机上运行，它显示关于目标计算机的下列信息：
- 该计算机上的企业根证书。
- 该计算机上的自动注册对象。
- 该计算机上的自动注册证书。
- 该计算机的组成员身份。
示例输出：
++++++++ MACHINE :: toddsdevx ++++++++
Enterprise Roots on machine:
NTDEV Offline SA Root
CEP Enrollment CA
Autoenrollment Object:
{25F346B2-AA63-11D2-9F27-00105A24E191}|Machine
Certificates matching autoenrollment object
Issuer:: W2K NTDEV Machine CA 2
Subject:: TODDSDEVX.ntdev.microsoft.com
1 Machine certs (0 archived) for toddsdevx
Group Memberships:
Domain Users
Domain Computers
列出域中计算机对象的信息
用法： dsstore -macobj <计算机名>
要点 确保对这个选项使用 SAM 风格的机器名，也就是 MyDomain\MyMachine$。
尽管可能性很小，使用计算机对象的 ServicePrincipalName (SPN)、DNSHostName 和组成员身份 Active Directory 属性有时会造成问题。
这个命令主要是一个诊断工具，来确定有问题的智能卡登录（或计算机注册）是否与这些属性的使用有关。
向 Windows 2000 PKI 添加非 W_indows 2000 CA 或脱机 CA
用法：
dsstore <根域的 DN（必需）> -addroot <.crt 文件> <ca 名>
dsstore <根域的 DN（必需）> -addcrl <.crl 文件> <ca 名> <计算机名>
dsstore <根域的 DN（必需）> -addaia <.crt 文件> <ca 名>
对脱机 CA 或第三方 CA 可以使用所有这些选项（脱机 CA 或第三方 CA 都不发布给 Active Directory）。这些命令行开关允许您将这些不能感知 Active Directory 的 CA 发布给 Active Directory（像联机企业 CA 那样）。
这里是每一个这些选项的作用：
-addroot 将一个根 CA 证书添加到企业根证书存储区，并将证书添加到 Active Directory 中自定义的颁发机构信息访问 (AIA) 位置。
-addaia 将一个中级 CA 证书添加到 Active Directory 中自定义的 AIA 位置。
-addcrl 将一个 CRL 发布到 Active Directory 中的自定义位置。
当使用了这些选项时，DSStore 的主要用途是将脱机 CA 添加到企业 PKI，或将第三方 CA 添加到受信根的企业 PKI 列表 - 而不需依赖组策略机制。DSStore 工具还允许将 CRL 添加到自定义 CRL 发行点 (CDP) 位置。
DSStore 允许链接引擎验证从脱机根或非 Windows CA 创建的证书链。
新的根证书在下列两个 URL 被加入 Active Directory，一个是基于 Active Directory 的企业根证书存储区，另一个是 AIA 扩展中使用的公用位置（AIA 扩展将被作为自动注册机制的一部分下载）：
- 基于 Active Directory 的企业根证书存储区：
CN=<CA Name>,CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=<root domain in enterprise>,DC=com
- AIA 位置：
ldap:///CN=<CA Name>,CN=AIA,CN=Public Key Services, CN=Services,CN=Configuration,DC=<root domain in enterprise>
新 CRL 将在 CDP 位置被加入 Active Directory：
ldap:///CN=<CA Name>,CN=<计算机名>, CN=CDP,CN=Public%20Key%20Services, CN=Services,CN=Configuration,DC =<root domain in enterprise>
要点 一定要在向从属 CA 颁发证书以前（使用 CA MMC 管理单元）更改已颁发证书的 AIA 和 CDP，使其指向这些位置。如果不这样做，将无法创建作为结果的证书链。其它详细资料，请参见 Windows 2000 联机帮助。
用 DSStore 解答证书链的疑难问题
下面的小节描述怎样用 DSStore 解答证书链的疑难问题。
DSStore 报告的常见链接错误
CERT_TRUST_REVOCATION_STATUS_UNKNOWN
通常情况下，这个错误是由于两个原因之一造成的：CRL 不再是有时效的；或者无法使用链中证书的 CDP 扩展而到达 CRL。请验证所有的 CA 都联机，它们的 CRL 是可以到达的，并且它们的 CRL 都是有时效的。
CERT_TRUST_IS_PARTIAL_CHAIN
这个错误表明不可能创建链，或者因为进行链验证的计算机上不存在证书，或者因为链中的证书不能通过它们的 AIA 扩展到达。
CERT_TRUST_IS_NOT_TIME_VALID
这个错误表明链中的一个（或多个）证书已过期。
CERT_TRUST_IS_REVOKED
这个错误表明链中的一个（或多个）证书已被吊销。
CERT_TRUST_IS_NOT_VALID_FOR_USAGE
这个错误表明试图将证书用于证书不支持的目的。
CERT_TRUST_IS_UNTRUSTED_ROOT
这个错误表明证书链以一个不受信任的根证书结尾。或者通过证书管理单元导入根证书来手动建立信任，或者针对企业范围内根的分发，使用公钥策略组策略或基于 Active Directory 的企业根证书存储区。
验证域控制器证书
您必须是一个域管理员才能运行下列步骤。这些步骤验证所有域控制器上的域控制器证书是否已正确地链接。最好在一个成员工作站或服务器上运行这个选项，因为这样可模拟智能卡登录客户机上发生的链验证过程。
- 从命令提示符，运行 dsstore -dcmon。
- 选择选项 2:
2. Chain Check chaining on DC certificates
- 验证不存在链接错误。
- 如果链接错误的确存在，再一次运行 dsstore -dcmon。
- 选择选项 4:
4. Delete bad Deletes *all* KDC certificates which do not chain
验证智能卡证书
要验证工作站上的智能卡证书，运行：
dsstore -checksc
这转储链中每个元素的错误状态，并显示卡上的证书。这有助于查明丢失的 CRL 或吊销的证书。下面是两个输出示例（事例 1 和事例 2）：
事例 1： 缺少中级和根证书
下面的调试信息显示不能创建整个链，因为运行测试的计算机上缺少中级证书及根证书。
这显示智能卡正在正常地工作：
The Microsoft Smart Card Resource Manager is running.
Current reader/card status:
--- reader: SCM Microsystems SCR300 0
--- status: SCARD_STATE_PRESENT | SCARD_STATE_UNPOWERED
--- status: The card is available for use.
--- card:
=======================================================
Analyzing card in reader: SCM Microsystems SCR300 0
No signature cert for reader: SCM Microsystems SCR300 0
这表明密钥在这个卡上是完整的：
Performing public key matching test...
Public key matching test succeeded.
输出的这一部分显示证书链状态：
Performing cert chain verification...
Chain Context
Trust Status (E=0x10040,I=0x0)
这是整个链的总体状态。请注意，我们缺少吊销信息，而且我们丢失了链中的元素。事实上，我们所有的只是一个叶证书：
CERT_TRUST_REVOCATION_STATUS_UNKNOWN
CERT_TRUST_IS_PARTIAL_CHAIN
Simple Chain Count = 1
Simple Chain [0]
Trust Status (E=0x10040,I=0x0)
CERT_TRUST_REVOCATION_STATUS_UNKNOWN
CERT_TRUST_IS_PARTIAL_CHAIN
这显示链中的所有元素。我们只有叶证书：
Chain Element Count = 1
Chain Element [0]
Subject::
[0,0] 2.5.4.3 (CN) Administrator
Issuer::
[0,0] 2.5.4.6 (C) US
[1,0] 2.5.4.3 (CN) ENT SUB
SerialNumber:: 61 68 BE E1 00 00 00 00 00 0E
SHA1 Thumbprint:: 02567413 D84051F1 CDCE7D5B 773BAFA9 A7302CB9
MD5 Thumbprint:: 895FD36A 2FCC8938 B26C61B9 6AC722E7
Signature Thumbprint:: C44CE505 1BC56A91 4C6BC488 CFBDF369 BC40E5F7
KeyIdentifier Thumbprint:: 059FEB98 8379EF55 1706CBA3 224A1700 9AC70D99
Key Provider:: Type: 1 Name: Gemplus GemSAFE Card CSP v1.0 Flags: 0x1 (SET_KEY_C
ONTEXT_PROP) Container: 3cbdfad8-5478-4fcd-86c2-17162ebb06fe KeySpec: 1
这表明单个证书的信任状态：
Trust Status (E=0x40,I=0x1)
CERT_TRUST_REVOCATION_STATUS_UNKNOWN ( RevError: 80092012 )
CERT_TRUST_HAS_EXACT_MATCH_ISSUER
Chain on smart card is invalid ::
事例 2： 根证书不受信任
下面的输出显示链中的根证书如果不受信任出现的结果。这个事例只显示链信息。
Performing cert chain verification...
Chain Context
Trust Status (E=0x20,I=0x0)
这显示除了缺少根证书，链是正常的：
CERT_TRUST_IS_UNTRUSTED_ROOT
Simple Chain Count = 1
Simple Chain [0]
Trust Status (E=0x20,I=0x0)
CERT_TRUST_IS_UNTRUSTED_ROOT
Chain Element Count = 4
Chain Element [0]
Subject::
[0,0] 2.5.4.3 (CN) Todd Stecher
Issuer::
[0,0] 1.2.840.113549.1.9.1 (E) todds@microsoft.com
[1,0] 2.5.4.6 (C) US
[2,0] 2.5.4.8 (S) WA
[3,0] 2.5.4.7 (L) Redmond
[4,0] 2.5.4.10 (O) NT Distributed Systems
[5,0] 2.5.4.11 (OU) PKS Test
[6,0] 2.5.4.3 (CN) W2K User Enrollment CA
SerialNumber:: 23 51 12 E4 00 00 00 00 01 21
SHA1 Thumbprint:: D80F9D5A 4E6B82C3 EC0D6A33 C77FFF69 67D5E553
MD5 Thumbprint:: 3848D2B6 B08B58DF E0D4D929 FBC0A706
Signature Thumbprint:: 434D7972 24EA0247 27714A85 4EBA2613 31C1FA22
KeyIdentifier Thumbprint:: 059FEB98 8379EF55 1706CBA3 224A1700 9AC70D99
Key Provider:: Type: 1 Name: Gemplus GemSAFE Card CSP v1.0 Flags: 0x1 (SET_KEY_C
ONTEXT_PROP) Container: 3cbdfad8-5478-4fcd-86c2-17162ebb06fe KeySpec: 1
这个叶证书正常：
Trust Status (E=0x0,I=0x1)
CERT_TRUST_HAS_EXACT_MATCH_ISSUER
Chain Element [1]
Subject::
[0,0] 1.2.840.113549.1.9.1 (E) todds@microsoft.com
[1,0] 2.5.4.6 (C) US
[2,0] 2.5.4.8 (S) WA
[3,0] 2.5.4.7 (L) Redmond
[4,0] 2.5.4.10 (O) NT Distributed Systems
[5,0] 2.5.4.11 (OU) PKS Test
[6,0] 2.5.4.3 (CN) W2K User Enrollment CA
Issuer::
[0,0] 1.2.840.113549.1.9.1 (E) todds@microsoft.com
[1,0] 2.5.4.6 (C) US
[2,0] 2.5.4.8 (S) WA
[3,0] 2.5.4.7 (L) Redmond
[4,0] 2.5.4.10 (O) NT Distributed Systems
[5,0] 2.5.4.11 (OU) PKS Test
[6,0] 2.5.4.3 (CN) NTDEV W2K PCA
SerialNumber:: 61 10 12 C8 00 00 00 00 00 54
SHA1 Thumbprint:: 19A9461B A974CB18 55C65880 C51BF0E5 96A86375
MD5 Thumbprint:: 17D1802A 1D1583AF 2A45D0C8 B28EC2B3
Signature Thumbprint:: D7297952 3704D281 71B1CA27 C4A9B428 427AA760
KeyIdentifier Thumbprint:: 44C56E9C 93D11AAF EAFD0A3E DCB4304D D1A9615A
这个中级 CA 证书正常：
Trust Status (E=0x0,I=0x1)
CERT_TRUST_HAS_EXACT_MATCH_ISSUER
Chain Element [2]
Subject::
[0,0] 1.2.840.113549.1.9.1 (E) todds@microsoft.com
[1,0] 2.5.4.6 (C) US
[2,0] 2.5.4.8 (S) WA
[3,0] 2.5.4.7 (L) Redmond
[4,0] 2.5.4.10 (O) NT Distributed Systems
[5,0] 2.5.4.11 (OU) PKS Test
[6,0] 2.5.4.3 (CN) NTDEV W2K PCA
Issuer::
[0,0] 1.2.840.113549.1.9.1 (E) todds@microsoft.com
[1,0] 2.5.4.6 (C) US
[2,0] 2.5.4.8 (S) WA
[3,0] 2.5.4.7 (L) Redmond
[4,0] 2.5.4.10 (O) NT Distributed Systems
[5,0] 2.5.4.11 (OU) PKS Test
[6,0] 2.5.4.3 (CN) NTDEV Offline SA Root
SerialNumber:: 05 5B ED 61 00 00 00 00 00 03
SHA1 Thumbprint:: 98FF4DD7 D386C0B9 2DAE1A3A 476F361D 7D539B68
MD5 Thumbprint:: 627B8EB8 770A1706 78E03B48 BA8F0F16
Signature Thumbprint:: F49751AF 9337CE48 724B6B3A 6266E61B F5D9708E
KeyIdentifier Thumbprint:: 7AFC16DE 561908A3 39215D55 0FF257BE 8F5EC77F
这个中级 CA 证书正常：
Trust Status (E=0x0,I=0x1)
CERT_TRUST_HAS_EXACT_MATCH_ISSUER
Chain Element [3]
Subject::
[0,0] 1.2.840.113549.1.9.1 (E) todds@microsoft.com
[1,0] 2.5.4.6 (C) US
[2,0] 2.5.4.8 (S) WA
[3,0] 2.5.4.7 (L) Redmond
[4,0] 2.5.4.10 (O) NT Distributed Systems
[5,0] 2.5.4.11 (OU) PKS Test
[6,0] 2.5.4.3 (CN) NTDEV Offline SA Root
Issuer::
[0,0] 1.2.840.113549.1.9.1 (E) todds@microsoft.com
[1,0] 2.5.4.6 (C) US
[2,0] 2.5.4.8 (S) WA
[3,0] 2.5.4.7 (L) Redmond
[4,0] 2.5.4.10 (O) NT Distributed Systems
[5,0] 2.5.4.11 (OU) PKS Test
[6,0] 2.5.4.3 (CN) NTDEV Offline SA Root
SerialNumber:: 3C 18 66 29 80 00 69 87 11 D3 1A B0 3F 48 F0 EE
SHA1 Thumbprint:: C7E802C4 4FE87DA7 4B239004 BF27282D EAE971E4
MD5 Thumbprint:: E55A36A0 B7EA4147 49CB2B25 A6662F86
Signature Thumbprint:: 7F3538D4 BCB9314A 587881BA BA62B2A9 7EA57B56
KeyIdentifier Thumbprint:: 2C1CB809 66DC3B75 3E021CA8 CE47B503 2CB186A6
这显示证书是可以（通过其 AIA 扩展）提取的，但是它是一个根证书，并且在这个计算机上不受信任。要使根证书为公钥操作所信任，根证书必须位于基于 Active Directory 的企业根证书存储区中：
Trust Status (E=0x20,I=0xc)
CERT_TRUST_IS_UNTRUSTED_ROOT
CERT_TRUST_HAS_NAME_MATCH_ISSUER
CERT_TRUST_IS_SELF_SIGNED
Chain on smart card is invalid ::
智能卡登录错误和修正
这一节描述智能卡登录错误和怎样纠正它们。
Error: Status insufficient resources
原因：
这个错误的唯一已知原因是客户机和域控制器有各种不同的 Windows 2000 版本。许多协议都是基于与产品一起演变的变动规范，因此就会产生一些互操作性问题。
这也是一般 Kerberos 失败的反映，因此可能其它（未知的）错误条件能够产生这个错误，但是，到目前为止，一个也不知道。
解决方案：
升级所有的域控制器、成员服务器和工作站。
Error: Revocation server offline
原因：
这个错误表明客户机不能验证域控制器证书。有关证书链检查的详细信息，请参见后面的“用 DSStore 解答证书链的疑难问题”部分。
这个错误由两个事件之一造成：
- CRL 已经过期。
- 不能通过成员服务器或域控制器得到 CRL。
解决方案：
确保证书层次结构中的所有 CA 都在运行，并且正确地发行有时效的 CRL。Certutil.exe 被安装在域中每个创建的 CA 上。按下例运行该命令，以转储企业中每个 CA 的 CRL。
Certutil -dsCRL
触发这个错误消息的可能原因是：或者有人从域中卸载 CA 而没有遵循前面标题为“卸载 CA 时保持良好的自动注册行为”部分中详述的步骤；或者是因为 CA 在能够发行新的 CRL 之前宕机。
要解决这个问题，请参见前面的“用 DSStore 解答证书链的疑难问题”部分。解决方案是：运行 dsstore -dcmon，以删除有问题的 KDC 证书，然后运行 dsstore -pulse，在域控制器上触发一个自动注册事件。
Error: Certificate has been revoked, but still can be used for smart card logon
原因：
CRL 缓存在计算机上以阻止不必要的网络通信，直到它们不再有时效。吊销证书（和发行 CRL）不总是意味着吊销立即生效，因为任何有 CRL 缓存版本的计算机，只有在本地缓存的复本失效后才会提取新的。
解决方案：
这个问题存在两个可能的解决方案。要吊销智能卡登录证书，可以禁用用户帐户。另一个方法是，可以为颁发 CA 指派小于默认的一星期的 CRL 周期，这样就可以更快地检测到吊销。但是，缺点是增加了的网络通信，因此最好只在直接负责向用户颁发证书的 CA 上更改 CRL 发行周期。
关于这个问题的更多信息，请参见前面的“优化 PKI 部署”部分。
Error: Client credentials could not be verified
原因：
客户证书不属于智能卡登录证书类型；它被吊销、不受信任，或者处理登录请求的域控制器没有得到吊销信息。
解决方案：
运行 dsstore -checksc 检查客户证书（请参见前面的“用 DSStore 解答证书链的疑难问题”部分）。通过查看证书用户接口的详细信息选项卡，验证证书是智能卡登录还是智能卡用户证书类型。
接下来，运行 dsstore -dcmon（选择 display 选项）来验证所有的域控制器都在智能卡证书层次结构中有根证书的一个复本。验证 checksc 选项列出的根都出现在每个域控制器上。
Error: The security database on the server does not have a computer account for this workstation trust relationship
原因：
智能卡登录的计算机的 ServicePrincipalName (SPN) 属性在 Active Directory 中不正确。
解决方案：
如下使用 DSStore：
dsstore -macobj <计算机名>
该命令转储特定计算机的 SPN、DNSHostName 和组成员身份。您应该看到 host/DNSHostName 形式的 SPN。如果 SPN 的设置不正确，请如下使用 Windows 2000 资源工具包工具 Setspn.exe：
setspn -R <计算机名>
Error: Invalid Handle
原因：
这是一个服务器端（域控制器）错误，其原因是域控制器没有处于处理智能卡登录请求的状态。这个问题发生的几率很小，但此处还是介绍它的解决方案，以防的确发生此问题。
解决方案：
重新启动处理智能卡登录请求的域控制器。通过用用户名和密码登录到工作站，然后在命令行提示符下运行 Set 命令，来确定哪个域控制器不能处理请求。重新启动 LogonServer 项确定的域控制器。
C:\ set
LOGONSERVER=\\NTDSDC2
Error: The network request is not supported
原因：
这个错误表明域控制器没有域控制器证书。
解决方案：
如果企业中存在企业 CA，域控制器应该“自动注册”证书。安装 CA 后可能会产生时间延迟，期间域控制器不会得到 KDC 证书。通过在域控制器上运行 dsstore -pulse 在 KDC 上产生自动注册，以消除这个时间延迟。
如果激发这个事件后（运行 dsstore -dcmon，选项 1 display 来验证域上的所有域控制器都有 KDC 证书），域控制器仍然没有证书，请分析域控制器的事件日志（应用程序日志、winlogon 事件）和 CA 的事件日志来确定注册失败的原因。
如果有问题的域控制器是刚刚加入该域，应确保已经复制对象（域控制器的计算机对象）及其属性。如果复制没有发生，会造成错误 0x547（“Configuration information could not be read from the domain controller, either because the machine is unavailable, or access has been denied”），因为 CA 验证请求所对照的域控制器还没有新添加的域控制器的帐户数据。
Error: A certificate chain processed correctly, but terminated in a root certificate which is not trusted by the trust provider
原因：
这一消息表明客户机缺少颁发了 KDC 证书证书链的根证书。以下问题可能会导致这个错误：
- 成员服务器没有收到策略 - 在应用程序日志中检查 userenv 错误。
- 成员服务器不能向 Active Directory 进行身份验证，并且没有收到根证书。
解决方案：
激发自动注册事件 (dsstore -pulse)，它从 Active Directory 中的企业根证书存储区中下载所有的根。
注册的错误和修正
这一节描述注册错误，并介绍怎样改正它们。
Error: Windows could not find a certification authority to process the request
原因：
这个错误表明四种可能的情况之一；只有使用证书管理单元的“证书管理器注册”向导时才会发生。下面任何一种情况都可以产生这个错误：
- 域中不存在企业 CA。
- 允许注册人对照它进行注册的 CA 不存在。
- 企业中任何 CA 均未颁发注册人有权限注册的证书模板。
- 注册人的计算机缺少特定 CA 层次结构的根证书。
前三种情况是配置问题。最后一种情况，通常意味着成员服务器或工作站还没有收到企业根证书的复本（因为复制还没有发生）。
解决方案：
对所有的四种情况，（对基于 Active Directory 的企业根证书存储区）运行 dsstore -pulse 或（对基于 GPO 的根证书）运行 secedit /refreshpolicy machine_policy 来解决这个问题。
如果运行这些命令之一不能解决这个问题，请在事件日志中查找关于计算机的安全通道的 netlogon 错误。
Error: Certsrv web pages inaccessible, and Virtual Roots do not show up in Internet Services Manager
原因：
这通常是未安装 Internet 信息服务 (IIS) 就安装证书服务而造成的结果。
解决方案：
在 CA 上，运行 certutil -vroot。这会用适当的权限重新安装虚拟根。（虚拟根是当用户连接到诸如 HTTP 或 FTP 服务器的 Internet 服务器时看到的根目录。虚拟根实际上是指向物理根目录的一个指针，物理根目录可能在一个不同位置，比如在另一个服务器上。可以使用虚拟根为 Internet 站点创建简单的 URL，并且移动根目录而不影响 URL。）
Error: Enrolling for smart card through enrollment station web pages fails with "A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider"
原因：
注册代理证书是由非企业 CA 或不受信任的 CA 颁发的。造成这种错误可能是以下两个原因之一：
- 颁发的 CA 不是企业 CA。
- 处理请求的 CA 还没有将颁发 CA 的证书下载到本地证书存储区。
第一个是预期的（正确的）行为。企业 CA 通过 DCOM 模拟进行身份检查，因此客户机的身份可以得到验证。独立的 CA 不通过 DCOM 模拟进行身份检查；因此，在企业环境中独立 CA 授予的证书是可疑的，并且不能在注册站点中使用。
关于该错误第二个原因的详细信息，请参见前面“自动注册和组策略造成的滞后时间”部分的内容。
解决方案：
要补救这一点，请在对照它执行操作的 CA 上激发自动注册事件 (dsstore -pulse)。
Error: Configuration information could not be read from the domain controller, either because the machine is unavailable, or access has been denied
原因：
通常情况下，如果在 CA 向其发送信息的全局编录服务器中，没有请求者（一个用户或计算机）的信息，就会发生这个错误。如果用户或计算机刚刚移到域中，但信息还没有复制到全局编录，就有可能发生这种情况。从受信任的目录林中尝试跨目录林注册时（Windows 2000 中不支持这种做法），也可能发生这种错误。最后，可能存在与复制或全局编录有关的问题。
解决方案：
像对待所有滞后时间问题那样，放宽网络时间。Windows 2000 不支持跨目录林注册。
如果用户已经在域中很长时间，请使用 Windows 2000 资源工具包 DCDiag 工具检查全局编录的状态，或使用类似的工具。分析全局编录上的事件日志查找错误消息。
Error: This operation returned because the timeout period expired
原因：
CA 没有在 60 秒内响应证书请求。
解决方案：
确保 CA 在正确运行，并且没有使用最大限度的 CPU 或内存。并且确保不存在会防止及时注册的网络问题。
Error: The RPC server is unavailable
原因：
CA 脱机，或者 DNS 名称解析存在问题。（请注意，DCOM 使用 RPC，这就是错误消息提到 RPC 的原因。）
解决方案：
如果 CA 脱机，则重新启动它。对 DNS，运行 dsstore -tcainfo，检查对照它执行注册的 CA 的 Machine Name 结果。如果不能按照这个名称 ping 到它，那么请检查 CA 的 DNS 记录。
Error: Invalid Parameter
原因：
以前，只有在计算机注册过程中请求计算机的 DNSHostName 属性有问题时，才发生这种错误。检查对照它进行请求的 CA 的事件日志。
解决方案：
这个错误发生的几率很小，但是如果它的确发生，请断开域的连接并重新连接，这应该能够解决此问题。
小结
Windows 2000 证书服务实施的 PKI 技术，使得通过 Internet、Extranet 和 Intranet 进行安全的信息交换成为现实。本文提供了在 Windows 2000 目录林中诊断和解答 PKI 部署疑难问题的指导方针。它还详细描述了怎样使用 DSStore 实用工具，并说明了智能卡登录错误和证书注册错误的原因和解决方案。
其它信息
关于 Windows 2000 Server 的最新信息，请查看我们的 Web 站点，网址是： http://www.microsoft.com/windows/server 及 MSN™ 上的 Windows NT Server Forum，地址是： http://computingcentral.msn.com/topics/windowsnt。
5 环境指您是在用户环境中（例如，作为登录的用户）还是在计算机环境中运行。
Windows 2000 PKI 部署和智能卡登录的疑难解答 [ yinjie 发表于 2004-10-29 2:30:00]