Configuring and Troubleshooting Windows 2000 and Windows Server 2003 Certificate Services Web Enrollment

On This Page

	Introduction
	Setting Up the Server Environment
	Configuring the Web Enrollment Proxy for Delegation
	Altering the Proxy Configuration
	Web Enrollment Client Prerequisites
	Certificate Enrollment Scenarios
	Troubleshooting
	Frequently Asked Questions
	Appendix
	Summary
	Related Links

Introduction

In Active Directory^® environments, certificates can be enrolled with the MMC Snap-In or with auto-enrollment from a Windows^® 2000 or Windows Server 2003 CA. A third certificate distribution method is Web enrollment that works especially well in environments where Active Directory is not widely available or accessible.

For an introduction to Microsoft Public Key Infrastructure (PKI) and Certificate Services, see
http://www.microsoft.com/pki

Enrolling certificates using Web enrollment is always a manual process that gives the certificate enrollment planner flexibility regarding the enrollment workflow.

If PKI architects or planners decide to implement Web enrollment support, they will primarily satisfy one or several of the following requirements.

For information on how to extend Web  enrollment support on Windows Server 2003, see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/customizing_the_certificate_services_web_enrollment_pages.asp

Scope

This white paper covers the implementation of Web enrollment support in Windows Server environments, including environments that have heterogonous deployments of both Windows 2000 Server and Windows Server 2003.

Note:  Neither Certificate Services nor Web enrollment support is enabled on Windows Server 2003 Web Edition.

This white paper helps system architects and administrators understand how to implement Web enrollment support in complex scenarios. It includes detailed information about the required network protocols between certificate requester, Web enrollment computer, and which CA is available. It also provides step-by-step guidance on how to constrain the delegation at the Web enrollment server. The troubleshooting section explains how to interpret error messages and how to resolve configuration errors.

Terms

In this white paper, technical terms are used for components that are part of the PKI and Certificate Services infrastructure. To clarify, the following rules apply.

Top of page

Setting Up the Server Environment

This section focuses on the installation and configuration of a certificate Web enrollment scenario. It provides step-by-step guidance on how to configure the components. You may configure Web enrollment support for a homogenous Windows 2000 environment or, alternatively, deploy a mixed configuration. However, the guidance provided applies primarily to homogenous Windows Server 2003 deployment environments.

Supported Scenarios

The computer that hosts Certificate Services and the computer that hosts Web enrollment support must be members of the same Active Directory forest but can be members of different domains.

You can enroll certificates from a Windows Server 2003 CA through a Windows Server 2003 or Windows 2000 Web enrollment proxy. Alternatively, you can enroll certificates from a Windows 2000 CA through a Windows 2000 Web enrollment proxy. There is no support, however, to enroll certificates from a Windows 2000 CA through a Windows Server 2003 Web enrollment proxy. If multiple Web enrollment proxies are required, multiple combinations can be implemented.

Table 1:  Supported operating system (OS) combinations for Web enrollment support

The CA running Certificate Services can be configured as an enterprise or stand-alone CA. However, you cannot install certificate Web enrollment support on a computer that has Windows SharePoint Services installed. This limitation is based on the fact that the Web enrollment support uses the “Default Web Site” as the Web environment. You cannot change the Web site that is used because it is hard-coded.

If you are using a Windows 2000 Web enrollment proxy, the Web enrollment capabilities are always limited to V1 templates even if you have V2 templates available at your Windows Server 2003 enterprise CA. V2 templates are ignored and not displayed in the Windows 2000 advanced Web enrollment pages.

Since a Web enrollment proxy acts like a normal Distributed Component Object Model (DCOM) client when it connects to the CA, you can configure as many Web enrollment proxies as you want. By default, the current implementation of the Web enrollment pages supports an n-to-1 relationship between Web enrollment proxy and CA. However, you cannot configure the Web enrollment pages in a way that multiple CAs are accessible at the same time. However, customization of the Web enrollment pages could satisfy such a specific requirement. Only one instance of the Web enrollment pages can be installed on a computer. You cannot set up multiple Web sites in IIS and run multiple Web enrollment pages with that configuration.

If you have high-availability requirements, you can install the Web enrollment pages on a network load-balanced Web cluster that runs IIS. Since this kind of configuration is more IIS-specific, this white paper does not provide any specific information on this topic.

Figure 1 illustrates a supported sample scenario where two CAs are available in the Active Directory forest. Each CA has multiple Web enrollment proxies connected to it. It is assumed that all computers belong to the same Active Directory forest.

Figure 1:  Sample configuration in a complex network with Web enrollment support
See full-sized image

A Web enrollment proxy configuration can be installed in a Windows 2000 or Windows Server 2003 Active Directory environment. In addition, mixed-mode configurations are supported as described previously.

Prerequisites

In the default configuration, the Windows Server 2003 Web enrollment proxy communicates with the CA via DCOM and establishes communication with a domain controller via Lightweight Directory Access Protocol (LDAP) and Kerberos. However, with additional configuration steps, the Transmission Control Protocol (TCP) communication can be constrained in a way that all traffic between the Web enrollment proxy and the CA can pass a firewall. Communication between the client and the Web enrollment proxy is purely HTTP so that you may constrain network traffic to the port that is used by the Web site that runs the Web enrollment pages. However, if the smart card enrollment station is used with the Web enrollment pages, the client does require direct DCOM connection to the CA as well.

Installing the CA

To set up the CA configuration, you should follow the best practice recommendations that are already provided by Microsoft. For information and recommended configurations, see Related Links.

To implement certificate enrollment through Web enrollment pages, it is not necessary and also not recommended to install or host IIS on the computer where the CA is installed. The CA setup will install Web enrollment support on a CA in any case because Certificate Services depend on some components of the Web enrollment support. But if IIS is not installed, the capability to enroll certificates via the Web is disabled.

Additional CA Configuration for Firewall Environments

In a scenario where a firewall is placed between the Web enrollment proxy and the issuing CA, you must change the CA and operating system configuration to reduce the number of ports that are used for communication between both systems. The configuration of the Web enrollment proxy remains unchanged.

Figure 2 illustrates the Web enrollment configuration for the firewall environment used in this white paper. Continuous lines show network traffic that flows when Web enrollment is performed. The dotted lines show additional network traffic that occurs if enrollment agents deploy smart card certificates.

Figure 2:  Sample Web enrollment scenario for an environment with a firewall

Figure 3 illustrates the certificate auto-enrollment configuration for the firewall environment used in this white paper.

Figure 3:  Sample certificate auto-enrollment scenario for an environment with a firewall

All computers are joined to the same Active Directory forest. The forest has two domains called child.contoso.com and contoso.com. The CA computer is a member of the contoso.com domain and can communicate properly with the domain controller called dc.contoso.com. The client (client.child.contoso.com) and Web enrollment proxy computer (caproxy.child.contoso.com) are members of the child domain and can communicate properly with the domain controller (dc.child.contoso.com) that maintains the domain. Domain controller to domain controller communication is assumed to be reliable and functional. For more information on Active Directory Replication over Firewalls, see
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/deploy/confeat/adrepfir.mspx

Note:  ISA Server 2004 is filtering Remote Procedure Call (RPC) traffic. You should enforce strict RPC compliance for the firewall rule between your domain controllers.

With these configuration steps, clients in the child domain are able to request certificates manually through the MMC Snap-In or Web enrollment interface, or enroll certificates automatically.

The configuration also applies to an environment where the CA computer, the Web enrollment proxy, and the client are joined to the same domain. With a single domain, the configuration steps are the same but the firewall configuration becomes simpler. See Configuring the Firewall for a Web Enrollment Scenario.

Note:  If the firewall is in place before you set up and configure the Web enrollment components, you must perform the following configuration steps at the CA before you install the Web enrollment support components. You must do this because during setup, the Web enrollment component already communicates with the issuing CA.

Disabling the RPC Interface at the Issuing CA

In the default configuration, a Windows Server 2003 CA communicates with its clients via RPC and DCOM. RPC is used to support Windows 2000 clients and servers and DCOM is used to support Windows XP and Windows Server 2003 clients. Since firewalls typically do not work well with RPC traffic, the CA RPC interface needs to be disabled. Note that this configuration step does not disable all RPC capabilities for the computer hosting the CA. Disabling RPC at the CA has no impact on the certificate enrollment capabilities with the Certificates MMC Snap-In or auto-enrollment in an environment where all computers run Windows XP or a later version of the Windows operating system family. With a disabled RPC interface at the CA, Windows 2000 computers cannot enroll certificates with the Certificates MMC Snap-In; however, they can enroll certificates through Web enrollment support.

To disable the RPC interface, perform the following steps.

certutil -setreg ca\interfaceflags +0x8

net stop certsvc & net start certsvc

To reset the RPC interface to the default settings, replace the plus sign in the previous command with a minus sign.

certutil -setreg ca\interfaceflags -0x8

Configuring the DCOM Settings

The CA is primarily implemented as a DCOM application. By default, DCOM uses high-numbered TCP ports to respond to client requests. With the DCOM Configuration MMC Snap-In, Certificate Services can be enforced to use a custom TCP port.

dcomcnfg.exe

net stop certsvc & net start certsvc

To undo this change at a later stage, remove the added entry from the list of endpoints.

Configuring the Firewall for a Web Enrollment Scenario

The firewall configuration for certificate enrollment through Web enrollment support corresponds to the previous sample scenario. To allow communication between the computers that are involved during certificate enrollment, the firewall must be configured to permit the network protocols as documented in Table 3.

Table 2 shows the network protocols that are generally required for communication between client, Web enrollment proxy, and Certificate Services during certificate enrollment. Other protocols like Domain Name System (DNS) might be required but this depends on whether these resources are only accessible through the firewall or can be reached directly. The protocol labels are taken from the ISA 2004 configuration and may not match the protocol description used in different firewall products.

Table 2:  Network protocols used for certificate enrollment

To configure the firewall, define rules that mirror the following rules. Apply the protocol definitions as described in Table 2 and pay special attention to the RPC filter. You must enable or disable strict RPC filtering according to Table 3.

Table 3:  Firewall configuration for certificate enrollment using Web enrollment

If, in your configuration, all computers share the same domain, you must implement rules 1, 2, 3, and 6 only.

If you enroll certificates with a smart card enrollment station, you must configure the firewall rules in Table 3 in addition to the rules in Table 4.

Table 4:  Additional firewall rules

Note:  Depending on your firewall software, it may take a few minutes after you have applied the firewall rules until the rules are actually enabled. It is also highly recommended that you reboot the CA and Web enrollment proxy computer to ensure that they communicate through the firewall properly from their initial state. In certain cases, clients on both sided of the firewall failed to establish a secure channel at the time when the firewall has been in place but permit rules have not been enabled. To force proper handshakes between the Web enrollment proxy and the CA, you should reboot.

Configuring the Firewall for a Certificate (Auto) Enrollment Scenario

Users and computers are able to enroll certificates if a firewall is between the requesting computer and the CA. The following firewall rules require that the RPC interface at the CA has been disabled and that a fixed port was set for the CA’s DCOM interfaces.

For more information about the protocol definitions, see Table 2. Make sure that you disable strict RPC filtering for rule 2.

Table 5:  Firewall configuration for manual certificate enrollment and auto-enrollment

Installing IIS on the Web Enrollment Proxy Computer

It is recommended that you install the IIS components independently before the Certificate Services Web Enrollment Support is installed. This is to ensure the appropriate installation and configuration order of both components. If you have installed IIS previously, continue with Installing IIS on the Web Enrollment Proxy Computer.

Note:  You may need the Windows Server 2003 installation media to complete this task.

Installing Web Enrollment on a Computer

Certificate Services Web enrollment pages can be installed independently from a CA. You can install Web enrollment support for Windows 2000 only on a Windows 2000 computer that runs IIS 5.0. To install Web enrollment support for Windows Server 2003, you must have a computer running Windows Server 2003 Standard or Enterprise Edition with IIS 6.0 installed. Microsoft does not support Web enrollment on Windows Server 2003 Web Edition, as documented at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/serverhelp/7A9252F4-D68D-46CE-BAF9-5C26C4807C45.mspx

Generally, the computer that hosts the Web enrollment pages and the CA must share the same Active Directory realm. This is because of two requirements. First, the CA and Web enrollment proxy rely on Kerberos tickets that have to be issued from a key distribution center in the realm. Second, the CA maintains enrollment permissions based on Active Directory accounts on the CA object. To configure the access control list for the CA in a reasonable way, you need to add security credentials that are known as such in your realm. Other considerations include the following:

Note:  You may need the Windows Server 2003 installation media to complete this task.

If you specify or type the wrong computer name for the CA, or you choose the wrong certificate service, you do not have to reinstall the Certificate Services Web enrollment pages. See Altering the Proxy Configuration.

If you click No by mistake when the wizard asks to enable the Active Server Pages (ASP) support for IIS, you can enable Active Server Pages manually. This explicit activation is also required if you have installed IIS after the Web enrollment pages are installed. At the command-line prompt, type

certutil -vroot

Press ENTER or open the Internet Information Services (IIS) Manager and enable ASP in the Web Service Extensions container.

Web Enrollment Permissions

Access permissions for the Web enrollment pages are controlled through the directory security settings of the Web application in IIS.

The default configuration for Windows 2000 and IIS 5.0 is set to the following authentication methods.

The default configuration for Windows Server 2003 and IIS 6.0 is set to the following authentication methods.

Changing any of these settings is recognized by clients immediately. Neither IIS nor the Web site requires a restart to put a new configuration into action. Since only Integrated Windows Authentication allows certificate enrollment from domain-joined and non-domain-joined computers, it is highly recommended that you configure Integrated Windows Authentication for any Web enrollment proxy. This applies to the following configurations.

Securing the Web Enrollment Pages with SSL

In any case, if you change the authentication method to Basic Text Authentication, it is highly recommended that you secure the HTTP channel between the client and the Web enrollment proxy with Secure Sockets Layer (SSL). Without an SSL server certificate, all HTTP traffic between the client and the server (including the user credentials) is sent in clear text via the network. In general, it is strongly recommended that the certificate server Web enrollment pages use SSL even with Integrated Windows Authentication for maximum security and privacy.

Top of page

Configuring the Web Enrollment Proxy for Delegation

In a configuration where the functionality for Certificate Services and the Web enrollment is separated between two physical computers, you are required to manage an identity and impersonation issue. The Web enrollment computer is a proxy that acts between the Certificate Services in the backend and the Web enrollment client. To enable the proxy functionality, the Web enrollment computer must be trusted for delegation in Active Directory; otherwise, it is not able to impersonate and request certificates on behalf of the user.

Generally, you can follow one of two approaches to configure delegation.

A domain controller is always trusted for delegation by default, thus, it is not required to be configured explicitly to be trusted for delegation. For general information about delegating authentication, see
http://www.microsoft.com/resources/documentation/WindowsServ/2003/enterprise/proddocs/en-us/se_constrained_delegation.asp

Kerberos Tickets

Enrolling certificates through Web enrollment relies on the Kerberos authentication and authorization protocol. Kerberos is implemented as a core technology in Windows 2000 and later systems. Generally, the handling of Kerberos tickets happens automatically, so that you do not have to configure its behavior explicitly. The following documents describe how Kerberos works in distributed environments like certificate Web enrollment.

Generally, domain-joined clients automatically request and use their own Kerberos tickets to authenticate at the Web enrollment proxy and to enroll for a certificate at the CA. However, non-domain-joined clients are not able to receive Kerberos tickets at all. Thus, the Web enrollment proxy is required to impersonate users and request Kerberos tickets on behalf of non-domain-joined clients.

Enabling Trust for Delegation at the Computer Level

The following steps show how to enable trust for delegation on a domain-joined computer so that any service hosted on that computer inherits the trust from the computer. For more information, see Windows Server 2003 online help at
http://www.microsoft.com/resources/documentation/WindowsServ/2003/enterprise/proddocs/en-us/se_del_computer.asp

See also the Microsoft Knowledge Base article at http://support.microsoft.com/?id=325894

Enabling Constrained Delegation

Compared to full computer trust for delegation, constrained delegation permits only a specific service account on a specific computer to impersonate a subject.

Figure 4 illustrates how name matching between the URL of the proxy, the service principal name (SPN), and the fully qualified domain name (FQDN) are implemented with constrained delegation.

1.	The client enters the http://caproxy.child.contoso.com URL to access the Web enrollment pages.
2.	The SPN that matches the URL is looked up in Active Directory and identifies the correct application pool. This is required because different application pools can share the same identity. To allow the client to select the right application pool, the HTTP SPN is required.
3.	Using delegation, the CA determines if the Remote Procedure Call service protocol is permitted for caproxy.contoso.com.
4.	If the protocol is permitted, the CA determines if the service account is trusted for delegation.
5.	If all delegation requirements are satisfied, the CA proxy is allowed to impersonate the certificate requester’s subject. Figure 4:  Name matching implementation with constrained delegation See full-sized image

As mentioned previously, constrained delegation works only if the domain functional level has been set to Windows Server 2003. Raising the domain level has no dependency on the forest level. You can elevate the domain level without raising the forest level. The Windows Server 2003 domain level is only required for the computers that host a Web enrollment proxy. This means that if you cannot raise the domain level of any of your production domains, you should think about a temporary separate domain where you host Web enrollment proxy computers.

Constrained delegation can be implemented easily with IIS 6.0 because it supports application pools which allow IIS to run Web applications in different security contexts.

To enable constrained delegation on a production system, several steps need to be performed.

If you plan to run multiple independent Web proxy servers in your environment, you must repeat all six steps for every Web enrollment proxy server. However, if you have an IIS cluster in place where multiple nodes have the Web enrollment pages installed, you only have to repeat steps 3 through 6 for every node in the cluster.

Setting Up an Individual IIS Service Account

By default, Certificate Services Web enrollment support is registered in the default application pool and thus, uses the identity of the Network Service. To prepare the change of identity for the Web enrollment support, you must provide a distinct service account that will be trusted for delegation. See Configuring Trust for Delegation for the Service Account.

Configuring the Service Principal Name

To make the newly created service account available for the next configuration steps, you must register an SPN for the service account. An SPN is like an alias for an Active Directory account. To register the SPN, you must have the setspn.exe tool installed on your computer. The tool is available with Windows Server 2003 support tools.

Changing the SPN becomes effective immediately. As soon as the client recognizes the SPN for the account, it will use the SPN that is found in the service account’s Active Directory object.

To set the SPN, perform the following steps.

setspn –A http/<Servername> <ServiceAccount>

setspn –A http/caProxy SPNcaProxy

setspn –A http/<FQDN-Servername> <ServiceAccount>

setspn –A http/caProxy.child.contoso.com SPNcaProxy

setspn –L SPNcaProxy

Registered ServicePrincipalNames for CN=SPNcaProxy,OU=Users,DC=child,DC= 
contoso,DC=com: 
    http/caProxy 
    http/caProxy.contoso.com

Configuring Trust for Delegation for the Service Account

Once the service account has been created, you must configure its delegation capabilities. This step enables the service account to impersonate a user and request a certificate on their behalf.

Configuring Trust for Delegation for the Computer Account

In this step, you are going to further restrict the impersonation capabilities. You will define what protocols can be initiated from this computer by a subject that is allowed to delegate.

Adding the Service Account to the IIS_WPG Group

To permit an account to take the identity of a Web application pool, the account must have certain permissions on the local system. The correct set of permissions is held by the IIS_WPG group (worker process group) by default. When IIS is installed, the IIS_WPG group is created with the members: Local Service, Network Service, and System.

You have to add the service account manually to allow it to be an identity of an application pool. To make the change, perform the following steps.

Configuring a New IIS Application Pool

This feature of IIS 6.0 is available only if IIS is running in worker process isolation mode. For more information on application pool identity, see “Configuring Application Pool Identity” at the Microsoft Web site
http://www.microsoft.com/resources/documentation/WindowsServ/2000/standard/proddocs/en-us/ca_cfgwrkridentity.asp

As mentioned previously, the CertSrv application requires the identity of the service account to enable constrained delegation. Instead of changing the identity of the default Web site, it is recommended that you create a new application pool that runs in the service account’s security context. To create and configure the new application pool, perform the following steps.

Configuration of constrained delegation is now complete. You can now start enrolling certificates from your Web enrollment proxy computer.

Note:  If you plan to uninstall the Web enrollment functionality again, you must also remove the manually created application pool from your IIS configuration manually.

Top of page

Altering the Proxy Configuration

At some point in the future, it might be required to change the configuration of the Web enrollment proxy so that it targets a Certification Authority on a different server. Fortunately, the name of the certificate server is maintained in an ASCII text file on the Web enrollment proxy and, therefore, is easy to update. To change the targeted certificate server, perform the following steps.

certutil -dump

Top of page

Web Enrollment Client Prerequisites

The client computer may require some configuration preparation to become a functional Web enrollment client.

Any computer that runs an earlier OS release than Windows 2000 SP4 or Windows XP SP1 and does not have Windows hotfix 323172 installed (http://support.microsoft.com/?id=323172) will be prompted to install the certificate enrollment control when visiting the Web enrollment pages for the first time. Administrator or Power User permissions are required to install the certificate enrollment ActiveX component on a computer for the first time.

Configuring Internet Explorer

To use certificate Web enrollment in scenarios where the CA and Web enrollment support are installed on different computers, you must at least have Internet Explorer version 6.0.2600.0000 installed on all clients that are part of your configuration. With earlier versions, you will recognize authentication errors that result in failed certificate enrollments because these versions do not support Integrated Windows Authentication.

In any case, you must ensure that the Internet Explorer version that is installed on the client computers is still a supported version according to the lifecycle information that is provided at http://support.microsoft.com/default.aspx?id=fh;[ln];lifeprodi

Enabling Integrated Windows Authentication

The default Internet Option settings for Internet Explorer 6.0 are different in Windows 2000 than in Windows XP even if the same Internet Explorer version is installed on both operating systems. In Windows 2000, you must enable Integrated Windows Authentication manually. In Windows XP, Internet Explorer is configured for Integrated Windows Authentication by default. To enable this user-specific setting, perform the following steps.

Adding the Web Enrollment URL to the Local Intranet Site

URLs that represent an FQDN are automatically put into Internet Explorer’s Internet Security zone.

If a Web enrollment proxy is referenced with a URL that belongs to the Internet Security zone, delegation is not going to work if Integrated Windows Authentication is required. However, delegation would work with Basic Text Authentication in this scenario.

To enable delegation with Integrated Windows Authentication where an FQDN is used to refer the Web enrollment proxy, you must add the URL to the local intranet site in Internet Explorer.

Web Enrollment Component

To enable a computer that acts as a Web enrollment client, an ActiveX component (Xenroll.dll) has to be installed and available on the computer. Windows 2000 prior to SP4 with hotfix 323172, Windows 2000 SP4, Windows XP with hotfix 323172, and Windows XP SP1 share the same version 5.131.3659 of the component. Windows Server 2003 and Windows XP SP2 also share the same version 5.131.3686.

Depending on the version that is installed on the Web enrollment client computer, you must install or upgrade the enrollment control. To update the control, you can use one of two different approaches.

The ActiveX component consists of two Dynamically Linked Library (DLL) files so that you have to permit two DLLs for installation when the component is installed interactively. On the computer where the Web enrollment pages are installed, the ActiveX DLLs can be found at %systemroot%\system32\certsrv\certcontrol.

In the case where you have installed the ActiveX version 5.131.3659 but attempt to request a certificate from a Windows Server 2003 Web enrollment proxy, the client may receive an offer to download a newer version of the control. To work around this issue, see the following Microsoft Knowledge Base article at http://support.microsoft.com/?id=818026

Top of page

Certificate Enrollment Scenarios

Table 6 shows all scenarios where certificate enrollment is supported and will be successful with the identified configuration. The following terminology is used to describe the components.

An “x” means that this column applies. An empty field means that a different column in the same group applies. “n/a” means that there is no authentication window to enter credentials.

Table 6:  Scenarios where certificate enrollment is supported

Note:  If trust for delegation has not been enabled for the computer, the error-message “The specified component could not be found in the configuration information. 0x80070862 (WIN32: 2146)" is shown for scenario ID 5, 6, 21, and 22.

Top of page

Troubleshooting

This section provides guidance on how to resolve issues that arise with incomplete or improperly configured client or server systems. The heading for each scenario is meant to represent the error message that is displayed to the user or administrator attempting enrollment. For each scenario, a short description of the problem is provided as well as suggested solutions.

Web Enrollment

The following section covers issues that are primarily seen in Web enrollment configurations.

Downloading ActiveX Control message appears and then does not disappear.

If you connect to the Web enrollment pages of a Windows CA with a client computer that has version 5.131.3659.0 or a later version installed, the Downloading ActiveX control message appears and does not disappear.

This behavior may occur if the version of the Xenroll.dll on the client is greater than the Xenroll.dll version on the CA. To resolve this problem, see the Microsoft Knowledge Base article at http://support.microsoft.com/?id=330389

The proper version of the ActiveX Control failed to download and install.

This error message may be displayed after the Downloading ActiveX Control message appears in the progress bar when you try to use a Microsoft Windows Certificate Server to enroll a smart card. It may also be displayed when you try to enroll a certificate from a client computer where the latest version of Xenroll.dll has not yet been installed. Even if you are logged on with local administrator permissions to download ActiveX controls, this behavior most often occurs if the Web site hosting the Web enrollment proxy is not in the Trusted Sites zone in Internet Explorer. To resolve this problem, see the Microsoft Knowledge Base article at http://support.microsoft.com/?id=330211

This error may also occur with Windows XP SP2 since installation of ActiveX controls is forbidden by default. To work around this issue, click OK to accept the error message and right-click the warning below the address bar. On the Context menu, click Allow this page to install ActiveX controls. Refresh the page and continue to install the control.

You are prompted for credentials while you are already logged on to the domain.

If you attempt to access the Web enrollment pages from a computer that is a domain member and you are logged on with valid domain credentials, you may receive a log on window. This behavior occurs if Web enrollment support and the CA are installed on different computers and Integrated Windows Authentication is enabled.

To perform Integrated Windows Authentication properly with Web enrollment support, you must add the URL which refers to the Web enrollment proxy to the Local Intranet zone in Internet Explorer. Additionally, the default user authentication setting in the security settings of the Local Intranet zone must be unchanged.

No certificate templates could be found. You do not have permissions to request ...

If you are experiencing this error message as smart card enrollment agent, see the same error message in Smart Card Enrollment Agent.

When a client attempts to request a certificate from the Advanced Certificate Request pages, it may receive the informational message “No certificate templates could be found. You do not have permissions to request a certificate from this CA, or an error occurred while accessing the Active Directory.” To resolve this problem, you will have to examine several configuration settings.

First, verify the configuration string of your CA as described in the Microsoft Knowledge Base article at http://support.microsoft.com/?id=811418

Next, if you cannot resolve the problem from the article, verify if user certificate enrollment works properly from the Certificates MMC Snap-In. If it works, verify the permissions that the certificate requestor has on the CA and the certificate templates. To verify a user’s permissions on the available templates, you can run the Windows Server 2003 version of certutil in the requestor’s security context. For information on how to get the latest version of certutil on your system, see How to Use the Latest Version of certutil on Non-Windows Server 2003 Computers in the Appendix. Then, run the following command at the command-line prompt.

certutil -template

For each certificate template that cannot be used by the user that is currently logged on, you will see an “Access denied” status. For example:

Administrator: Administrator -- Access is denied. 
CA: Root Certification Authority -- Access is denied. 
CAExchange: CA Exchange -- Access is denied. 
CEPEncryption: CEP Encryption -- Access is denied. 
ClientAuth: Authenticated Session 
CodeSigning: Code Signing -- Access is denied.

In the previous scenario, the user can enroll certificates only with the ClientAuth certificate template.

If the user’s permissions are set correctly, it could be that the configuration string that is defined in the certdat.inc file is not the same case as the CA’s configuration string. Note that the configuration string is case-sensitive To find out the correct configuration string, run the certutil.exe command without any command options at the Web enrollment proxy computer. The command will show a list of all CAs that are available in this forest. Copy the corresponding CA configuration string from the command’s output and paste it into the certdat.inc file. For more information on this procedure, see Altering the Proxy Configuration.

Another possible reason, though rare, that you are experiencing this problem could be that the Web enrollment proxy’s certificate template cache has not yet been refreshed so that newly permitted certificate templates do not appear. To refresh the certificate template cache manually, log on as administrator to the CAproxy computer.

Run the following command on a Windows 2000 Web enrollment proxy.

Secedit /refreshpolicy machine_policy /enforce

Run the following command on a Windows Server 2003 Web enrollment proxy.

gpupdate /force

Note:  If this does not refresh the certificate template cache, see the Microsoft Knowledge Base article “A Certificate Request That Uses a New Template Is Unsuccessful” to force a refresh of the cache at http://support.microsoft.com/default.aspx?id=281260

Internet Explorer refreshes logon window and Event ID 100 is logged in Web enrollment proxy application log from source. W3SVC

Clients who have not logged on to their computers with domain credentials will notice that Internet Explorer refreshes the logon window after the correct credentials have been provided. The Web enrollment proxy logs event ID 100 from source W3SVC for every logon attempt.

This problem occurs if the Web enrollment proxy runs on Windows 2000 and the authentication method for CertSrv is set to Basic Text Authentication. A Group Policy may have been applied from the domain that does not allow the user to log on locally.

To resolve this problem, change the authentication method to Integrated Windows Authentication since this is the recommended authentication method. Otherwise, you have to allow the user account, or a group the user account belongs to, to log on locally.

Specified component could not be found in the configuration information. 0x80070862

The client may receive this error message. No messages are found in the Event Viewer—neither on the Web enrollment proxy nor on the CA computer corresponding to this transaction.

This error occurs most often with Windows 2000 workgroup or domain-joined computers where Integrated Windows Authentication was not explicitly enabled in Internet Explorer. A Windows 2000 Web enrollment proxy is used with a Windows Server 2003 CA that is installed on a different computer in this case. The authentication method on the Web enrollment proxy is set to Integrated Windows Authentication.

Or, alternatively, if a Windows XP client is used where Integrated Windows Authentication is enabled by default in Internet Explorer, the error occurs when the user logs on from a non-domain-joined computer with the user principal name (UPN) to a Windows 2000 enrollment proxy where the CA is installed on Windows Server 2003.

To resolve this problem, enable Integrated Windows Authentication in Internet Explorer on a Windows 2000 computer. On a Windows XP computer, use the “domainname\username” instead of the UPN during authentication to the Web enrollment site.

Your certificate request was denied with Event ID 53.

The client receives the error message “Certificate request was denied”. The CA computer logs event ID 53 in its application log as follows:

Event Type:    Warning 
Event Source:    CertSvc 
Event Category:    None 
Event ID:    53 
Date:        3/23/2004 
Time:        3:20:08 PM 
User:        N/A 
Computer:    W2K-E-CA 
Description: 
Certificate Services denied request 14 because Access is denied.  0x80070005 (WIN32: 5). 
The request was for (Unknown Subject).  Additional information: Denied by Policy Module

This problem occurs only in configurations where the Web enrollment proxy and the CA are installed on two different Windows 2000 computers.

This error may occur with Windows 2000 workgroup or domain-joined client computers where Integrated Windows Authentication was not explicitly enabled in Internet Explorer. A Windows 2000 Web enrollment proxy is used with a Windows 2000 CA in this case. The authentication method on the Web enrollment proxy is set to Integrated Windows Authentication.

Or, alternatively, if a Windows XP client is used where Integrated Windows Authentication is enabled by default, the error occurs when the user logs on from a non-domain-joined computer with the UPN.

To resolve this problem, enable Integrated Windows Authentication in Internet Explorer on a Windows 2000 computer. On a Windows XP computer, use the “domainname\username” instead of the UPN during authentication to the Web enrollment site.

COM Error Info: CCertRequest::Submit Access is denied. 0x80070005 (WIN32: 5)

If the client receives this error message, the suggested cause is “The Certification Authority Service has not been started.". This is a generic DCOM error where the suggested cause is not accurate.

Given that the Web enrollment proxy has valid delegation permissions, this problem occurs in configurations where the Web enrollment proxy and the CA are installed on different Windows Server 2003 computers. To resolve this problem, one or many of the following issues should be considered.

Event ID 10006 from Source DCOM

The error message in the system log of the Web enrollment proxy may contain an entry similar to the following:

Event Type:    Error 
Event Source:    DCOM 
Event Category:    None 
Event ID:    10006 
Date:        3/17/2004 
Time:        6:18:39 PM 
User:        CAPROXY\Administrator 
Computer:    CAPROXY 
Description: 
DCOM got error "General access denied error" from the computer W2K3-E-CA.contoso.com when attempting to activate the server: 
{D99E6E74-FC88-11D0-B498-00A0C90312F3}

The most common reason for this error is improper or absent delegation permissions. To resolve this problem, make sure that trust for delegation has been configured properly. For more information on proper configuration, see Enabling Trust for Delegation at the Computer Level or Enabling Constrained Delegation.

Cannot find object or property. 0x80092004 (-2146885628)

The error message in the Windows 2000 CA application log may contain an entry similar to the following:

Event Type:    Error 
Event Source:    CertSvc 
Event Category:    None 
Event ID:    21 
Date:        3/18/2004 
Time:        12:33:52 PM 
User:        N/A 
Computer:    W2K-E-CA 
Description: 
Certificate Services could not process request 4 due to an error: Cannot find object or property.  0x80092004 (-2146885628).  
The request was for (Unknown Subject).

This error message is displayed if you attempt to access a Windows 2000 CA from a Windows Server 2003 Web enrollment proxy. This configuration is not supported. To resolve the problem, upgrade the operating system of the CA to Windows Server 2003 or use a Windows 2000 Web enrollment proxy with a Windows 2000 CA.

The disposition message is "Denied by Policy Module".

If a client receives this error message, the certificate request has reached the certificate service. The CA policy module has verified that all mandatory certificate attributes are available in the certificate request or the requesters Active Directory object. The failure occurred because not all attributes have been provided properly. The CA computer logs more details about the issue with Event ID 53 in the application log. For example:

Event Type:    Warning 
Event Source:    CertSvc 
Event Category:    None 
Event ID:    53 
Date:        3/22/2004 
Time:        8:01:30 PM 
User:        N/A 
Computer:    W2K3-E-CA 
Description: 
Certificate Services denied request 10 because The EMail name is unavailable and cannot be added to the Subject or Subject Alternate name. 
0x80094812 (-2146875374).  The request was for CONTOSO2\JimKim.  Additional information: Denied by Policy Module

To resolve this problem, use the Active Directory Users and Computers MMC Snap-In to add the missing attributes to the user account.

Certificate enrollment from Intel IA64 clients to a Windows 2000 CA fails.

If you attempt to enroll certificates using the Web enrollment pages hosted on a Windows 2000 CA, Intel (IA64)-based clients fail. To resolve the problem, see the Microsoft Knowledge Base article at http://support.microsoft.com/?id=283237

Constrained Delegation

This section describes error messages that can occur when constrained delegation has been configured. Unfortunately, some error messages occur for multiple reasons; therefore, you must ensure that multiple settings have been set correctly.

You are not authorized to view this page.

When a domain-joined client connects to the Web enrollment pages, an unexpected window may appear, asking for user credentials. After entering the appropriate credentials, the window refreshes. After entering the credentials three times without success, the error message “You are not authorized to view this page” is displayed.

To resolve this problem, one or both of the following issues should be considered.

The page cannot be displayed (Cannot find server or DNS Error).

This error message is displayed when a non-domain-joined client has entered user credentials and connects to the Web enrollment pages, but the SPN was not registered appropriately or the CertSrv application is running in the wrong application pool.

To resolve this problem, see the suggested solution for the problem in You are not authorized to view this page.

The error may also be caused by an unusually large client public key as described in the Microsoft Knowledge Base article at http://support.microsoft.com/?id=278475

Result: Access is denied. 0x80070005 (WIN32: 5)

Because DCOM is a standard protocol, it does not provide any specific error messages for Certificate Services. If a client receives the Access is denied error message, events are logged neither in the Event Viewer on the computer where the CA is installed nor on the Web enrollment proxy. However, the following are some of the more common issues that generate this error.

SPN was set incorrectly.

An “Access denied” error might occur if the SPN for the service account was set but is incorrect. Make sure that the SPN was set to service type ”http” only. If the service account has other service types registered, like “host”, remove them. The correct