Troubleshooting Windows 2000 PKI Deployment and Smart Card Logon
Microsoft Windows 2000 Certificate Services provides an integrated public key infrastructure (PKI) that lets customers securely exchange information across the Internet, extranets, and intranets. This paper describes optimizing PKI deployment and PKI problem diagnosis and troubleshooting for Windows 2000 Certificate Services.
On This Page
Introduction Optimizing PKI Deployment DSStore-New Tool for Windows 2000 PKI Smart Card Logon Errors and Fixes Enrollment Errors and Fixes Summary
Introduction
Microsoft Windows 2000 Certificate Services, used to create a certification authority (CA) for managing the Windows 2000 public key infrastructure (PKI), verifies and authenticates the validity of each party involved in an electronic transaction. This technology allows the secure exchange of information on open networks, such as the Internet, extranets, and intranets. The focus of this paper is to provide information for administrators who implement and support Windows 2000 PKI.
This paper provides a Microsoft Consulting Services (MCS) and Microsoft Product Support Services (PSS) guide for diagnosing problems and troubleshooting PKI deployment in a Windows 2000 forest. Included are detailed information about DSStore (a Windows 2000 Resource Kit tool helpful in identifying and solving smart card logon and PKI problems), and strategies for responding to and resolving smart card logon and certificate enrollment error messages. These topics are covered in the following sections:
Optimizing PKI deployment
DSStore?new tool for Windows 2000 PKI
Smartcard logon errors and fixes
Enrollment errors and fixes
This paper assumes you are already familiar with the white paper "Windows 2000 Certificate Services," which explains how to design and deploy the PKI for Windows 2000 Certificate Services. You can find the link to the paper in the section "For More Information" at the end of this document.
Optimizing PKI Deployment
Several considerations can affect the successful performance of your PKI implementation. Understanding the following topics will help you optimize your PKI deployment:
Latency caused by Active Directory replication
Latency caused by auto-enrollment and group policy
Latency caused by certificate templates
Effect on certificate revocation of CRL lifetimes
Preserving good auto-enrollment behavior when uninstalling CAs
The certificate publisher's group
For additional information about designing the CA hierarchy and deploying Certificate Services, see the section "PKI Design and Deployment in Windows 2000" in the white paper "Windows 2000 Certificate Services" (link can be found in "For More Information").
Latency Caused by Active Directory Replication
Windows 2000 enterprise CAs (described, as are stand-alone CAs, in the white paper "Windows 2000 Certificate Services") rely on containers and objects in Active Directory and are therefore subject to the rules of Active Directory replication. For example, if you make a change to the discretionary access control list (DACL)1 of a certificate template, you are in effect making a change to a security descriptor2 on an object on an individual domain controller. The object on which you are making the DACL change is in the container identified by the following distinguished name:
CN=Certificate Templates,CN=Public Key Services,CN=Services, CN=Configuration,DC=mydomain, DC=com
Before this change takes effect on a given CA (or a given client), the change must replicate across the enterprise to the domain controller from which the CA (or client) is receiving information. Typically, this takes place relatively quickly, but with some replication topologies (such as between two sites separated by an intermittent WAN connection-see below for an example) it can take longer. Any administrative actions must take this latency into account.
In addition, in some replication topologies, it is possible to end up with container or object conflicts, which results in the creation of new containers or objects prefixed by CNF <some #><conflicting common name> (CNF stands for conflict). The most common problems caused by this collision show up as errors on the certificate template objects when the first CAs are installed on a domain, especially in multi-site enterprises.
In the case of conflicting certificate templates, simply delete the certificate template objects containing the CNF notation using the Active Directory Sites and Services snap-in.
For a general discussion of Active Directory replication in a Windows 2000 network, see the link to the "Active Directory Architecture" white paper in "For More Information." For specific information about how Active Directory replication interacts with Windows 2000 Certificate Services certificate revocation lists (CRLs), see the subsection "Certificate Revocation Lists" in the white paper "Windows 2000 Certificate Services."
Example Scenario: Deploying PKI across Multiple Sites Separated by Slow WAN Links
Deploying PKI across multiple sites connected with slow WAN links presents an interesting administrative problem. This deployment scheme is one possible way to handle layouts in which low or intermittent inter-site bandwidth prevents DCOM or HTTP connections between users in Site 1 and CAs in Site 2.
The theoretical deployment discussed in this subsection assumes an enterprise comprised of two sites, separated by an intermittent 56K WAN link. It also assumes that an enterprise CA exists in each site. For this strategy to work, the following five conditions must be true:
All users and computers in Site 1 are members of a group called Site 1 Requestors.
All users and computers in Site 2 are members of a group called Site 2 Requestors.
All machines in Site 1 are members of an organizational unit (OU) called Site 1 Computers.
All machines in Site 2 are members of an OU called Site 2 Computers.
Both Site 1 and Site 2 contain a global catalog server. Note that Windows 2000 enterprise CAs require a global catalog server in each site, if DCOM connectivity between sites is not available. (The Windows 2000 operating system's global catalog, which plays major roles in logging on users, in querying, and in replication, is a database kept on one or more domain controllers.)
To restrict users and machines in Site 1 so that they can enroll only against Site 1 Enterprise CAs, perform the following steps:
Launch the CA snap-in for the Site 1 Enterprise CA.
Right-click on the CA, and then select Properties.
Select the Security Tab.
For Authenticated Users, clear the Enroll check box.
Click the Add... button.
Add users or computers who will request a certificate from Site 1 to the DACL list of each enterprise CA, and check the Enroll check box.
Wait until inter-site replication has had a chance to take effect.
Repeat steps 1-7 for Site 2 Requestors.
If you also wish to force auto-enrollment to occur only within site boundaries3, perform the following steps:
Create a new Group Policy object (GPO) for the Site 1 Computers OU.
Right-click on the CA, and then select Properties.
Run the Automatic Certificate Request Settings wizard to create the auto-enrollment object for the Site 1 Enterprise CA..
Repeat steps 1-2 for the Site 2 Computers OU.
Latency Caused by Auto-Enrollment and Group Policy
Perhaps the most important type of latency, in the context of Certificate Services, is that associated with the auto-enrollment event. When the auto-enrollment event occurs, several operations are triggered:
This adapter's IP address resolves to the adapter's built-in MAC address.
Verification and re-enrollment. Verification of the current certificate against the auto-enrollment object, and re-enrollment, if necessary. Re-enrollment can be required because of certificate revocation, expired certificates, changes in certificate template usages, or a change in the issuer in the auto-enrollment object.
Downloading root certificates. Downloading of root certificates from the Active Directory-based enterprise root certificate store to the local enterprise root certificate store. (See the section "Active Directory-Based Enterprise Root Certificate Store" in Appendix A of the white paper "Windows 2000 Certificate Services" for a description of that store).
Downloading enterprise CA certificates. Downloading of root certificates from the Active Directory-based enterprise root certificate store to the local enterprise root certificate store. (See the section "Active Directory-Based Enterprise Root Certificate Store" in Appendix A of the white paper "Windows 2000 Certificate Services" for a description of that store).
The following occurrences trigger auto-enrollment for machines:
Pulsing of Group Policy Event. Pulsing of the Group Policy event triggers auto-enrollment only after the successful application of policy. Policy is applied only when there has been a change in any of the group policies that apply to the machine in question.
DSStore-pulse. You can use the DSStore utility to pulse the event manually (see the section "DSStore—New Tool for Windows 2000 PKI").
After reboot. Auto-enrollment is triggered automatically any time the machine is rebooted.
Every eight hours. Auto-enrollment is triggered automatically every eight hours.
Examples of how auto-enrollment latency can affect a server or workstation on a domain follow:
Smart Card Enrollment Station. . If an enterprise CA has been recently added to an enterprise's PKI, and it issued an Enrollment Agent certificate to a user shortly thereafter, a time lag can occur between the issuing of the Enrollment Agent certificate and when it becomes valid for use at the smart card enrollment station. (Search Windows 2000 online Help for "enrolling for a smart card certificate" for information about the smart card enrollment station.) This delay occurs because the CA against which the Enroll on Behalf of operation is taking place may not have a copy of the new enterprise CA certificate in its local certificate store. This situation is identifiable by the error 0x800b0112 ("A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider"). To remedy this, pulse the auto-enrollment event (dsstore -pulse) on the CA against which the operation is performed.
Smart Card Logon. If a newly installed enterprise CA has issued a smart card logon certificate, then domain controllers processing the logon request may not be aware of the new CA. To remedy this, pulse the auto-enrollment event on the domain controller.
Certificate Enrollment using the Certificates snap-in's Certificate Manager Enrollment Wizard. In order for an entity to enroll against an enterprise CA through the Certificate Manager's Enrollment wizard, the root certificate in the chain must be present on the server or workstation (Web enrollment is not constrained by this requirement). Without the root certificate from a certificate hierarchy, it may not be possible to enroll against a given CA. To remedy this, wait for replication and auto-enrollment to take place, which can take up to eight hours.
In addition, the wizard requires that the enrollee has Enroll access to the CA and to at least one certificate template which that CA issues.
Latency Caused by Certificate Templates
An organization's servers and workstations can also experience a latency associated with certificate templates. Certificate template information is maintained in a cache with a 10-minute lifetime. Examples of such cached information are DACLs and key usages (key usages specify what a certificate is used for). If this cache has timed out, it is updated from Active Directory (which, as described above, has its own latency caused by replication) during the enrollment process.
In addition, CAs also cache certificate template information, which, in the short-term, may not be entirely synchronized with the DACLs in the enrollee's certificate template cache. Therefore, DACL changes on certificate templates do not always take place immediately after application, even if the enrollee has appropriate permissions to enroll for a given certificate.
Effect on Certificate Revocation of CRL Lifetimes
If the private keys associated with a certificate are compromised, it is standard practice to revoke that certificate. When a certificate is revoked, it appears in that certificate issuer's CRL. CRLs are periodically published to several locations (such as Active Directory, a Web site, or a file share). Each CRL has a validity lifetime approximately corresponding to its publication period. The default publication period for Windows 2000 CAs is one week. Windows 2000 CAs also let the administrator configure how often CRLs are published (resulting in customizable CRL lifetimes).
When an application validates a certificate, it may choose to use the information in a CRL to determine whether or not to accept a given certificate for a given purpose. For example, if a Web server requests Secure Sockets Layer (SSL)4 client authentication, it can check to make sure that the client certificate does not appear in its issuer's CRL.
CRL checking for most Windows 2000 features (including smart card logon) uses the Microsoft Cryptographic Application Program Interface (CryptoAPI) 2.0 Certificate Chaining Engine APIs. A potential side effect to this is that CRLs retrieved during the chain-building process are cached in the context5 of the user or computer for the lifetime of the CRL. Therefore, if additions or changes to a CRL have been made, these changes are not reflected in the chain-building process on other machines until the locally cached copy of the CRL has expired. For this reason, Microsoft recommends that the CRL lifetimes of CAs responsible for issuing Smart Card Logon and Smart Card User certificate templates are short (for example, 24 hours). Using short CRL lifetimes significantly speeds the effects of revoking a smart card logon certificate.
In addition, if network traffic is a concern, you can restrict the certificate templates issued by this short CRL lifetime CA to Smart Card Logon certificate types. Doing so ensures that the repeated retrieval and validation of CRLs associated with this CA take place only during logon operations.
Preserving Good Auto-Enrollment Behavior When Uninstalling a CA
Several rules of thumb can help keep PKI operating trouble-free when removing either an enterprise or a stand-alone CA from the domain. The best practice is determined by which type of CA you are uninstalling.
Important. When a CA is uninstalled, it no longer publishes CRLs, and certificate chain checking typically returns an error stating that the revocation server is offline. This error is valid in some cases (for example, in the case of a laptop unattached to the network) and does not trigger auto-enrollment for a fresh certificate. This situation can be a problem on domain controllers, whose certificates may no longer be verifiable on a workstation doing smart card logon due to the expired CRL. |
If you do not use the procedures described in the following two subsections, you may have to delete auto-enrolled certificates from domain controllers to make smart card logon work correctly on a domain. See "Error: Revocation server offline" in the "Smart Card Logon Errors and Fixes" section, as well as the section "Verifying Domain Controller Certificate."
Uninstalling Root CAs To uninstall a root CA, you must remove the root certificate from the Windows 2000 trust constructs. To do this, perform these steps:
Remove the root CA certificate from any Group Policy objects that you have created manually. For specific instructions, search Windows 2000 online Help for "Public Key Policies."
Remove the root CA certificate from the Active Directory-based enterprise root certificate store by executing the following command from a command prompt:
dsstore <DN of your root domain> -del
Finally, walk through the console menus and delete the certificate(s) corresponding to your root CA. All machines on the domain will be informed of the change during the next pulsing of the auto-enrollment event. You can speed the process by running dsstore -pulse from a command prompt.
Uninstalling Subordinate CAs When the subordinate CA is uninstalled, the certificate should be revoked by its issuer. You perform this manual revocation through the issuing CA's Certificate Authority snap-in.
Applying a two- or three-tier CA hierarchy in an enterprise simplifies administration, because using this configuration means that you have a secure offline root CA that cannot be compromised, and you can easily revoke subordinate CAs before uninstalling them.
The Certificate Publishers' Group
All enterprise CAs are added to the Certificate Publishers' group (a group provided by Windows 2000) during installation. Default user-object DACLs allow the Certificate Publishers' group Write access to the userCertificate and userCert attributes on most user objects (see the bullets below for exceptions). This lets you publish some certificate types to user objects. Keep the following considerations in mind when using this functionality:
Certificate Publishers' group membership is domain local. Default DACLs on user objects allow Write access for Certificate Publishers from only the user's domain. If it is desirable to have Certificate Publishers from another domain publish to user objects in a given domain, you must run the Delegation wizard on the user objects to allow Write access to the userCert and userCertificate attributes.
Not all certificate types are published to user objects. The following certificate types are published to Active Directory user or machine objects as part of the enrollment process:
User
User Signature Only
Smartcard User
EFS
Administrator
EFS Recovery
Computer
Domain Controller
Group membership requires a reboot after setup. As with all group memberships, the inclusion of the Certificate Publishers group in the authentication token requires a log off/log on. In the case of machines, log off/log on equates to a reboot. Until this reboot is performed, certificates issued are not published to the user object in Active Directory.
DSStore-New Tool for Windows 2000 PKI
DSStore is a new tool provided with the Windows 2000 Resource Kit to help manage Active Directory-based public key constructs. Specifically, it is used to diagnose PKI and smart card logon problems. This section, which is divided into the following subsections, describes the functionality of DSStore:
Pulse auto-enrollment events to speed PKI processes
Manage enterprise roots in Active Directory
Check status and validity of domain controller certificates
Check validity of smart card certificate
List information about CAs on an enterprise
List information about a machine's certificates
List information about machine objects on a domain
Add non-Windows 2000 CAs or offline CAs to Windows 2000 PKI
Troubleshooting certificate chains with DSStore
Pulse Auto-Enrollment Events to Speed PKI Processes
Usage: dsstore -pulse
You can initiate three processes by pulsing the auto-enrollment event:
Download enterprise roots from Active Directory.
Download enterprise CA certificates from Active Directory.
Trigger auto-enrollment for certificates.
See the earlier section called "Latency Caused by Auto-Enrollment and Group Policy" for more information about these events.
Manage Enterprise Roots in Active Directory
Usage: dsstore <DN of root domain (required)> [-display | -del | -addroot]
When an enterprise administrator (or a domain administrator of the root domain) installs a root CA in a network, its certificate is automatically stored in the enterprise root certificate store in Active Directory. (For the location of the root certificate, see the section "Active Directory-Based Enterprise Root Certificate Store" in Appendix A of the white paper "Windows 2000 Certificate Services.")
This option lets administrators display, delete, or add those certificates in the enterprise root certificate store in Active Directory. Adding roots is covered in more detail in the later section "Add Non-Windows 2000 CAs or Offline CAs to Windows 2000 PKI."
Check Status and Validity of Domain Controller Certificates
Usage: dsstore [-domain <target domain>] -dcmon
This command lets administrators check for the presence and validity of domain controller certificates. When run, this command provides the following four options:
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
The display option shows only the domain controller certificates that each domain controller in a given domain has.
The chain option shows the status of the certificate chain for each domain controller in a given domain.
The delete all option deletes all domain controller certificates from all domain controllers in a given domain.
The delete bad option deletes only those domain controller certificates that do not chain correctly.
Caution: It is best to run this command on a member server or workstation, because chaining failures can be masked if you run this command from the domain controller (especially if a CA is installed on the domain controller). |
Check Validity of Smart Card Certificate
Usage: dsstore -checksc
You must run this command on a machine equipped with a functioning smart card reader, with the card inserted. It verifies that the smart card subsystem is functioning and that the certificate chain associated with the smart card certificate is correct.
See the later section called "Troubleshooting Certificate Chains with DSStore" for more information.
List Information about CAs on an Enterprise
Usage: dsstore -tcainfo
You use this command to display the CA name, the DNS name, and the certificate types. Here is an example of the command's output:
This entry shows the name of the CA on the domain:
CA Name: W2K NTDEV Ent User CA =============================
This entry shows the DNS machine name (if you cannot use this name to successfully ping the CA, enrollment will fail, probably with the error message "The certificate authority cannot be reached"):
Machine Name: w2kuserca.ntdev.microsoft.com
This section shows what certificate types can be issued by a given CA and whether or not an individual has access to that CA. For example, the user shown below has no access to the Administrator certificate type:
:: 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
Note: You can change DACLs on certificate types by using the Active Directory Sites and Services snap-in. |
List Information about a Machine's Certificates
Usage: dsstore -entmon <machine name>
Important: Make sure you use the SAM-style machine name for this option, that is, MyDomain\MyMachine$. |
This command, which must be run by an administrator on the target machine, displays the following information about the target machine:
Enterprise root certificates on that machine.
Auto-enrollment objects on that machine.
Certificates that are auto-enrolled on that machine.
Group membership of that machine.
Sample output:
++++++++ 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
List Information about Machine Objects on a Domain
Usage: dsstore -macobj <machine name>
Important: Make sure you use the SAM-style machine name for this option, that is, MyDomain\MyMachine$. |
Although highly unlikely, it is possible that using Active Directory attributes ServicePrincipalName (SPN), DNSHostName, and group membership attributes of machine objects could occasionally produce errors.
This command is primarily a diagnostic tool to determine if a problematic smart card logon (or machine enrollment) is related to the use of these attributes.
Add Non-Windows 2000 CAs or Offline CAs to Windows 2000 PKI
Usage: dsstore <DN of root domain (required)> -addroot <.crt file> <ca name> dsstore <DN of root domain (required)> -addcrl <.crt file> <ca name> <machine name> dsstore <DN of root domain (required)> -addaia <.crt file> <ca name>
You can use all these options for either an offline CA or for a third-party CA (neither of which publishes to Active Directory). These switches let you have these non-Active Directory-aware CAs publish to Active Directory, just as an online enterprise CA does.
Here is what each of these options does:
-addroot adds a root CA certificate to the enterprise root certificate store and adds the certificate to the customary Authority Information Access (AIA) location in Active Directory.
-addaia adds an intermediate CA certificate to the customary AIA location in Active Directory.
-addcrl publishes a CRL to the customary location in Active Directory.
When used with these options, DSStore's primary purpose is to add offline CAs to an enterprise PKI or to add a third-party CA to an enterprise PKI list of trusted roots?without having to rely on the group policy mechanism. The DSStore tool also lets you add CRLs to the customary CRL distribution point (CDP) locations.
DSStore allows the chaining engine to verify certificate chains built from an offline root or from a non-Windows CA.
New root certificates are added to Active Directory at the following two URLs, one for the Active Directory-based enterprise root certificate store, and another at the common location used in AIA extensions (and which will be downloaded as part of the auto-enrollment mechanism):
Active Directory-based enterprise root certificate store: CN=<CA Name>,CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=<root domain in enterprise>,DC=com
AIA location: ldap:///CN<CA Name>,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=<root domain in enterprise>
New CRLs will be added to Active Directory at the CDP location:
- CDP location: ldap:///CN=<CA Name>,CN=<Machine Name>, CN=CDP,CN=Public Key Services, CN=Services,CN=Configuration,DC =<root domain in enterprise>
Important: Be sure to alter the AIAs and CDPs of issued certificates to point to these locations (using the CA MMC snap-in) before issuing certificates to subordinate CAs. If you do not, your resultant certificate chain cannot be built. See Windows 2000 online Help for additional details. |
Troubleshooting Certificate Chains with DSStore
The following subsections describe how to use DSStore to troubleshoot certificate chains.
Common Chaining Errors Reported by DSStore
CERT_TRUST_REVOCATION_STATUS_UNKNOWN. Typically, this error occurs for one of two reasons: Either the CRL is no longer time valid, or the CRL is not reachable using the CDP extensions in the certificates in the chain. Verify that all CAs are online, that their CRLs are reachable, and that their CRLs are time valid.
CERT_TRUST_IS_PARTIAL_CHAIN This error indicates that it is not possible to build the chain, either because certificates are not present on the machine doing the chain validation, or because certificates in the chain are not reachable through their AIA extensions.
CERT_TRUST_IS_NOT_TIME_VALID This error indicates that one (or more) of the certificates in the chain has expired.
CERT_TRUST_IS_REVOKED This error indicates that one (or more) of the certificates in the chain is revoked.
CERT_TRUST_IS_NOT_VALID_FOR_USAGE This error indicates that an attempt is being made to use a certificate for a purpose that is not supported by the certificate.
CERT_TRUST_IS_UNTRUSTED_ROOT This error indicates that the certificate chain terminates in an untrusted root certificate. Either manually establish the trust by importing the root certificate through the Certificates snap-in, or, for enterprise-wide distribution of the root, utilize the Public Key Policies group policy or the Active Directory-based enterprise root certificate store.
Verifying Domain Controller Certificate
You must be a domain administrator to perform the following steps. These steps verify that the domain controller certificates on all domain controllers chain correctly. It is best to run this option on a member workstation or server, because this emulates the chain validation process that takes place on a smart card logon client.
From a command prompt, run dsstore -dcmon.
Select Option 2:
2. Chain Check chaining on DC certificates
Verify that no chaining errors exist.
If chaining errors do exist, run dsstore -dcmon again.
Select Option 4:
4. Delete bad Deletes *all* KDC certificates which do not chain
Verifying Smart Card Certificate
To verify smart card certificates on the workstation, run:
dsstore -checksc
This dumps the error status of each element in the chain and displays the certificate on the card. This helps pin down the missing CRL or revoked certificate. Two example outputs follow (Case 1 and Case 2):
Case 1: Missing intermediate and root certificates
The following debug information indicates that the entire chain cannot be built, because the machine on which the test is being run is missing intermediate certificates, as well as the root certificate.
This indicates that the smart card is working correctly:
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
This indicates that the keys have integrity on this card:
Performing public key matching test... Public key matching test succeeded.
This portion of the output displays the certificate chain status:
Performing cert chain verification... Chain Context Trust Status (E=0x10040,I=0x0)
This is the overall status of the entire chain. Note that we are missing revocation information, and we are missing elements in the chain. In fact, all we have is a leaf certificate:
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
This displays all of the elements in the chain. We have only the leaf certificate:
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
This indicates the trust status of this individual certificate:
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 ::
Case 2: Root certificate is not trusted
The output below displays results that occur if the root certificate in a chain is untrusted. Only the chain information is shown for this case.
Performing cert chain verification... Chain Context Trust Status (E=0x20,I=0x0)
This shows that the chain is okay, other than missing the root certificate:
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
This leaf certificate is okay:
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
This intermediate CA certificate is okay:
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
This intermediate CA certificate is okay:
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
This shows that the certificate was retrievable (through its AIA extension), but that it is a root certificate, and it is not trusted on this machine. Root certificates must be in the Active Directory-based enterprise root-certificate store in order to be trusted for public key operations:
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 ::
Smart Card Logon Errors and Fixes
This section describes smart card logon errors and how to correct them.
Error: Status insufficient resources
Cause:
The only known reason for this error is having a mix of clients and domain controllers from different builds of Windows 2000. Many of the protocols are based on a moving specification that has evolved with the product, so some interoperability problems have arisen.
This is also the mapping for generic Kerberos failures, so it is possible that other (unknown) error conditions could produce this error, but, to date, none are known.
Solution:
Upgrade all of your domain controllers, member servers, and workstations.
Error: Revocation server offline
Cause:
This error indicates that the domain controller certificate is not verifiable by the client. See the section "Troubleshooting Certificate Chains with DSStore" for more information on certificate chain checking.
This error is caused by either of two events:
The CRL has expired.
The CRL is not reachable from the member server or from the domain controller.
Solution:
Ensure that all CAs in the certificate hierarchy are running and are publishing time-valid CRLs correctly. Certutil.exe is installed on each CA created in a domain. Running this command as follows will dump the CRLs for each CA in the enterprise:
Certutil -dsCRL
This error message was probably triggered either by someone removing a CA from the domain without following the steps detailed in the earlier section titled "Preserving Good Auto-Enrollment Behavior When Uninstalling a CA," or by a CA going down before it could publish a new CRL.
To correct this problem, see the earlier section "Troubleshooting Certificate Chains with DSStore." The solution is to run dsstore -dcmon to remove the offending KDC certificate, and then run dsstore -pulse to trigger an auto-enrollment event on the domain controller.
Error: Certificate has been revoked, but still can be used for smart card logon
Cause:
CRLs are cached on a machine to prevent unnecessary network traffic until they are no longer time valid. Revoking a certificate (and publishing the CRL) does not always mean that the revocation takes place immediately, because any machine that has a cached version of the CRL does not attempt to retrieve a new one until that locally cached copy is no longer time valid.
Solution:
Two possible solutions to this problem exist. To revoke smart card logon certificates, you can disable the user account. Alternatively, if you assign the issuing CAs shorter CRL periods than the default of one week, the revocation will be detected much more quickly. The tradeoff, however, is increased network traffic, so it is best to alter CRL publishing periods only on CAs that are directly responsible for issuing certificates to users.
See the earlier section "Optimizing PKI Deployment" for more information about this issue.
Error: Client credentials could not be verified
Cause:
The client certificate is not a smart card logon certificate type; it is revoked, not trusted, or revocation information was not available to the domain controller processing the logon request.
Solution:
Run dsstore -checksc to check the client certificate (see the earlier section "Troubleshooting Certificate Chains with DSStore"). Verify that the certificate is of certificate type smartcard logon or smartcard user by looking at the Details tab of the certificate user interface.
Next, run dsstore -dcmon (select the display option) to verify that all domain controllers have a copy of the root certificate in the smart card certificate hierarchy. Verify that the root listed by the checksc option is present on each domain controller.
Error: The security database on the server does not have a computer account for this workstation trust relationship
Cause:
The ServicePrincipalName (SPN) attribute for the computer on which smart card logon is taking place is not correct in Active Directory.
Solution:
Use DSStore as follows:
dsstore -macobj <machine name>
This command dumps the SPN, DNSHostName, and group memberships for a given machine. You should see an SPN of the form host/DNSHostName. If this SPN is not set correctly, use the Windows 2000 Resource Kit tool Setspn.exe as follows:
setspn -R <computer name>
Error: Invalid Handle
Cause:
This is a server-side (domain controller) error that arises because the domain controller is not in a state to service smart card logon requests. It is highly unlikely that this problem will occur, but its solution is included here just in case it does.
Solution:
Reboot the domain controller servicing the smart card logon request. Determine which domain controller has failed to process the request by logging on to the workstation with a user name and password, and then running the Set command at the command prompt. Reboot the domain controller identified by the LogonServer entry.
C:\ set LOGONSERVER=\\NTDSDC2
Error: The network request is not supported
Cause:
This error indicates that the domain controller does not have a domain controller certificate.
Solution:
If an enterprise CA exists in the enterprise, domain controllers should "auto-enroll" for a certificate. A potential time lag occurs after the installation of a CA, during which a domain controller does not get a KDC certificate. Running dsstore -pulse on the domain controller eliminates this time lag by causing auto-enrollment to occur on the KDC.
If after pulsing this event (run dsstore -dcmon, option 1 (display) to verify that all domain controllers on the domain have KDC certificates), your domain controller still does not have a certificate, analyze the event logs of the domain controller (application log, winlogon event) and the event logs of the CA to determine why the enrollment is failing.
If the problematic domain controller has just been joined to the domain, ensure that replication of that object (the domain controller's machine object) and its attributes have taken place. If replication has not occurred, this causes error 0x547 ("Configuration information could not be read from the domain controller, either because the machine is unavailable, or access has been denied"), because the domain controller against which the CA is validating the request does not yet have the account data for the newly added domain controller.
Error: A certificate chain processed correctly, but terminated in a root certificate which is not trusted by the trust provider
Cause:
This message indicates that the client is missing the root certificate that issued the certificate chain of the KDC certificate. The following problems can produce this error:
Member server is not receiving policy—check application log for userenv errors.
Member server cannot authenticate to Active Directory and is not receiving a root certificate.
Solution:
Pulse the auto-enrollment event (dsstore -pulse), which downloads all roots from the enterprise root certificate stores in Active Directory.
Enrollment Errors and Fixes
This section describes enrollment errors and how to correct them.
Error: Windows could not find a certification authority to process the request
Cause:
This error indicates one of four possible conditions; it occurs only when you attempt to use the Certificates snap-in's Certificate Manager Enrollment wizard. Any of the following conditions can produce this error:
No enterprise CAs exist on the domain.
No CAs exist against which the enrollee is permitted to enroll.
None of the CAs in the enterprise issue a certificate template for which the enrollee has permission to enroll.
The enrollee's machine is missing the root certificate for a given CA hierarchy.
The first three conditions are configuration issues. The last one, typically, means the member server or workstation has yet to receive a copy of the root certificate for an enterprise (because replication has not yet taken place).
Solution:
For all four conditions, run dsstore -pulse (for Active Directory-based enterprise root certificate stores) or run secedit /refreshpolicy machine_policy (for GPO-based root certificates) to remedy the problem.
If running one of those commands does not correct the problem, check the eventlog for netlogon errors regarding the machine's secure channel.
Error: Certsrv web pages inaccessible, and Virtual Roots do not show up in Internet Services Manager
Cause:
This is, typically, a result of installing Certificate Services before installing Internet Information Services (IIS).
Solution:
On the CA, run certutil -vroot. This reinstalls the virtual roots with proper permissions. (A virtual root is the root directory that a user sees when connected to an Internet server, such as an HTTP or FTP server. The virtual root is actually a pointer to the physical root directory, which may be in a different location, such as on another server. You use a virtual root to create a simple URL for the Internet site and to move the root directory without affecting the 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"
Cause:
The Enrollment Agent certificate was issued from a non-enterprise CA or from an untrusted CA. This can happen for one of two reasons:
The issuing CA is not an enterprise CA.
The CA processing the request has not yet downloaded the issuing CA's certificate into the local certificate store.
The first is expected (correct) behavior. Enterprise CAs do authentication checking through DCOM impersonation, so the identity of the client can be verified. Stand-alone CAs do not do authentication checking through DCOM impersonation; therefore, certificates granted by a stand-alone CA are suspect in an enterprise environment and cannot be used in the enrollment station.
See the earlier section "Latency Caused by Auto-Enrollment and Group Policy" for more information on the second cause of this error.
Solution:
To remedy this problem, pulse the auto-enrollment event (dsstore -pulse) on the CA against which the operation is performed.
Error: Configuration information could not be read from the domain controller, either because the machine is unavailable, or access has been denied
Cause:
Typically, this error occurs if information about a requestor (either a user or computer) is not available in the global catalog server to which the CA is sending information. This can happen if the user or computer has just been moved into the domain and the information has not yet replicated to the global catalog. It can also occur if you attempt cross-forest Web enrollment from a trusted forest, which is not supported in Windows 2000. Finally, problems with replication or your global catalog may exist.
Solution:
As with all latency issues, give the network time. Windows 2000 does not support cross-forest enrollment.
If the user has been on the domain for a long time, use the Windows 2000 Resource Kit DCDiag tool to investigate the condition of your global catalogs, or use a similar tool. Analyze your event log on the global catalog for error messages.
Error: This operation returned because the timeout period expired
Cause:
The CA did not respond to the certificate request within 60 seconds.
Solution:
Ensure that the CA is running correctly and is not running at maximum CPU or memory. Also, ensure that no network issues are preventing timely enrollment.
Error: The RPC server is unavailable
Cause:
The CA is offline, or a problem exists with DNS name resolution. (Note that DCOM uses RPC, which is why the error message refers to RPC.)
Solution:
If the CA is offline, restart it. For DNS, run dsstore -tcainfo, look at the Machine Name results for the CA against which the enrollment was performed. If you cannot ping it by this name, then verify the DNS records for the CA.
Error: Invalid Parameter
Cause:
Historically, this error occurs only during machine enrollment and when there is a problem with the DNSHostName attribute of the requesting machine. Verify this in the eventlog of the CA against which the request is being made.
Solution:
This error is highly unlikely, but if it does occur, disjoining from the domain and rejoining should fix the problem.
Summary
The Windows 2000 Certificate Services implementation of PKI technology enables the secure exchange of information across the Internet, extranets, and intranets. This paper provides guidelines for diagnosing and troubleshooting PKI deployment in a Windows 2000 forest. It also describes in detail how to use the DSStore utility and explains the causes and solutions for smart card logon errors and certificate enrollment errors.
For More Information
For the latest information on Windows 2000 Server, see https://www.microsoft.com/technet/prodtechnol/windows2000serv/default.mspx.
For additional information, see these sources:
"Windows 2000 Certificate Services" white paper
"An Introduction to the Windows 2000 Public Key Infrastructure" white paper
"Microsoft Windows 2000 Public Key Infrastructure" white paper
"Public Key Interoperability" white paper
"Active Directory Architecture" white paper
International Telecommunications Union (ITU) Web site.
PKIX Web site (the IETF working group charged with defining the basis for an interoperable PKI).
Windows 2000 Server Resource Kit. Located on the Windows 2000 Server and Advanced Server CDs as part of Support Tools.
Schneier, Bruce. Applied Cryptography: Protocols, Algorithms, and Source Code in C. 2nd Ed. John Wiley & Sons, 1995. This is a common cryptography primer.
| 1 | In Windows 2000, an access control list (ACL) is a list of security protections that apply to an entire object, a set of the object's properties, or an individual property of an object. Each Active Directory object has two associated ACLs: The discretionary access control list (DACL) is a list of user accounts, groups, and computers that are allowed (or denied) access to the object. The system access control list (SACL) defines which events (such as file access) are audited for a user or group. |
| 2 | Windows 2000 implements access control by allowing administrators to assign security descriptors to objects stored in Active Directory. A security descriptor is a set of information attached to an object (such as a file, printer, or service) that specifies the permissions granted to different groups (or users), as well as the security events to be audited. In addition to controlling access to a specific object, you can also control access to a specific attribute of that object. |
| 3 | You can also restrict the application of group policy by using "Apply Group Policy" DACLs on the GPO. This would eliminate the need to create separate OUs. |
| 4 | Secure Sockets Layer (SSL) is a proposed open standard developed by Netscape Communications for establishing a secure communications channel to prevent the interception of critical information, such as credit card numbers. Primarily, it enables secure electronic financial transactions on the World Wide Web, although it is designed to work on other Internet services as well. |
| 5 | Context refers to whether you are running in the user context (for example, as a logged-on user) or in the machine context. |