Return to top
In Windows Server operating system releases prior to Windows Server 2008 R2, AD CS is a forest level resource. Organizations with multiple Active Directory Domain Services (AD DS) forests had to deploy one or more certification authorities (CA) into each forest in which there were users or computers that required automatic enrollment of certificates. Prior to Certificate Enrollment Web Services, even if
Certificate Enrollment Web Services enables organizations with multiple forests to consolidate their PKI by eliminating the requirement for per-forest CA deployments. This enables organizations to consolidate PKI services by deploying fewer CAs.
Cross forest certificate issuance requires forest trust to be enabled between all forests, and clients from all forests must be running at least Windows 7 or Windows Server 2008 R2 operating systems.
Note: Starting in Windows Server 2008 R2 there is support for enrollment using the DCOM protocol across forests. This type of certificate enrollment across forests is supported on Windows 7, Windows Vista, and Windows XP clients, although it requires Active Directory objects such as templates to be copied manually from one forest to another. Return to top
Prior to the availability of Certificate Enrollment Web Services, AD CS required that client computers configured for certificate auto-enrollment be connected directly to the corporate network. Certificate Enrollment Web Services allows organizations to enable AD CS using a perimeter network. This allows users and computers outside the corporate network to enroll for certificates. For example, if an organization has an internal network and perimeter network environment, the web services could be run on a system in the perimeter network and connect to a CA running on the internal network. This design allows organizations to maintain existing network segmentation practices while still taking advantage of HTTPS enrollment.
Note: The Certificate Enrollment Web Service must be able to make an authenticated DCOM request to the CA.
For details on this mode, see the section Renewal-only mode. Renewal-only mode is primarily designed for the following scenario:
When deploying a Certificate Enrollment Web Services infrastructure, there are multiple requirements and considerations. These include:
The following installation requirements and capabilities apply to both the Certificate Enrollment Web Service and Certificate Enrollment Policy Web Service, unless otherwise specified:
Certificate Enrollment Web Services client computers must be computers running at least Windows 7 or Windows Server 2008 R2 operating systems. To utilize key-based renewal, client computers must be running at least Windows 8 or Windows Server 2012 operating systems. Return to top
Network connectivity requirements are a key part of deployment planning, particularly for scenarios where the Certificate Enrollment Web Policy Service and Certificate Enrollment Web Service will be hosted in a perimeter network. All client connectivity to both services occurs within an HTTPS session, so only HTTPS traffic is required between the client and the web services. The Certificate Enrollment Policy Web Service communicates with AD DS, using standard Lightweight Directory Access Protocol (LDAP) and secure LDAP (LDAPS) ports (TCP 389 and 636 respectively). The Certificate Enrollment Web Service communicates with the CA using DCOM. By default, DCOM uses random ephemeral ports. However, this behavior is configurable and the CA can be configured to reserve a specific range of ports to simplify firewall configuration. See Microsoft Knowledge Base article 154596: How to configure RPC dynamic port allocation to work with firewalls for more information. Return to top
If the Certificate Enrollment Policy Web Service is installed in a network location in which there is a firewall between it and a writeable domain controller, the following traffic types must be allowed through the firewall:
In order to make network traffic across the firewall manageable, configure the CA to use a restricted set of ports. On the firewall, create a rule allowing TCP traffic on the port numbers selected, from the network or host on which the Certificate Enrollment Web Service runs to the CA. For more additional information about configuring a firewall with a Microsoft CA, see the blog post Certificate Enrollment Requires a Custom Protocol. Return to top
The Certificate Enrollment Web Service and the Certificate Enrollment Policy Web Service support three different authentication methods:
Note: Windows 7 clients can authenticate anonymously to web services that use the policy and enrollment protocols. However, the Microsoft Certificate Enrollment Web services do not accept anonymous authentication requests.
Windows Integrated Authentication uses Kerberos to provide a seamless authentication flow for devices connected to the internal network and joined to a domain. This method is preferred for internal deployments because it leverages the existing Kerberos infrastructure present within AD DS and requires minimal changes to certificate client computers. Use this authentication method if you only need clients to access the web service while connected directly to your internal network. Return to top
If certificates will be provisioned to computers, then clients computers can use client certificate authentication. Client certificate authentication does not require a direct connection to the corporate network. Client certificate authentication is preferred over username and password authentication because it provides a more secure method of authenticating. However, this method requires that x.509 certificates be initially provisioned to clients by separate means. Use this authentication method if you plan to provide users with digital X.509 certificates for client authentication. This authentication method enables you to make the web service available on the Internet. In Windows Server 2008 R2, if you want to use certificate-based authentication from outside the domain (for a computer configured in a workgroup or that is a member of a domain from which there is no forest trust relationship), then you must also do the following:
or
3. Manually transfer the issued certificate from a computer inside the domain to the appropriate computer that is either configured in a workgroup or that is a member of a domain from which there is no forest trust relationship.
The simplest form of authentication is username and password. This method is typically used for servicing clients that are not directly connected to the internal network. It is a less secure authentication option than using client certificates, but it does not require provisioning a certificate to clients. Thus, it is often easier to implement than client certificate authentication. Use this authentication method if you would like users to enter a username and password to authenticate to the web service. This authentication method can be used when the web service is accessed on the internal network or over the Internet. Return to top
Delegation is the act of allowing a service to impersonate a user account or computer account in order to access resources throughout the network. When a service is trusted for delegation, that service can impersonate a user to use other network services. For general information about delegation and authentication, see Delegating authentication.
Delegation is required for the Certificate Enrollment Web Service account when all of the following are true:
the CA is not on the same computer as the Certificate Enrollment Web Service
Certificate Enrollment Web Service needs to be able to process initial enrollment requests, as opposed to only processing certificate renewal requests
the authentication type is set to Windows Integrated Authentication or Client certificate authentication
Delegation for the Certificate Enrollment Web Service is not required when:
If the Certificate Enrollment Web Service is running as the built-in application pool identity, you should configure delegation on computer account that is hosting the service. If the Certificate Enrollment Web Service is running as a domain user account, then you must first create an appropriate service principal name (SPN) and then configure delegation on the domain user account. To create an SPN for a domain user account, you can use the setspn command. The setspn command to create SPN for a user account named CES for the Certificate Enrollment Web Policy service running on a computer with a fully qualified domain name (FQDN) of cpandl-ces1.cpandl.com in the cpandl.com domain is as follows: setspn -s http/cpandl-ces1.cpandl.com cpandl\ces The specific type of delegation that you should configure depends upon the authentication method selected for the Certificate Enrollment Web Service:
The specific services that you should delegate are the host service and the Remote Procedure Call system service (RPCSS). To configure delegation, you can access the computer account or domain user account properties (as applicable to your situation) using Active Directory Users and Computers. Right-click the account and then click Properties. On the Delegation tab, configure the settings as described in this section depending upon the situation. For example, if you have configured client certificate authentication and are using a user account name CES to enable delegation to a certification authority with computer account named CPANDL-CA1, the Delegation tab should be set as shown in the following figure.
If an organization does not wish to enable delegation, but does run the Certificate Enrollment Web Service on a different computer from the CA, renewal-only mode can be implemented. Renewal-only mode does not require delegation. However, renewal-only mode does require that the CA Policy Module flag is enabled to accept renewal-only requests. To enable CA Policy Module flag to allow renewal-only, you must run the following command as an administrator on the CA: certutil -config "CAConfig" -setreg policy\EditFlags +EDITF_ENABLERENEWONBEHALFOF You must replace the CAConfig portion of the command with the actual CA configuration. You can see the CA Configuration by running the command certutil on the CA. The following example comes from the Test Lab Guide: Demonstrating Certificate Key-Based Renewal: Certutil -config "APP1.corp.contoso.com\IssuingCA-APP1" -setreg policy\EditFlags +EDITF_ENABLERENEWONBEHALFOF The CA must be restated after this command is run. When Certificate Enrollment Web Services is configured in renewal-only mode, the CA that issues the certificate must be the same CA used for certificate renewal. The CA will still be able to process standard certificate enrollment requests even after this change is implemented. For additional details on renewal-only mode, see the section entitled Renewal-only mode.
The Certificate Enrollment Web Service can run using a Managed service account (MSA), although the role service installation does not support this option. To configure the Certificate Enrollment Web Service to run as an MSA:
For more information about creating and managing MSA’s, see Service Accounts Step-by-Step Guide. Return to top
Microsoft conducts various performance tests during the development of its products. Using release candidate builds of Windows 7 and Windows Server 2008 R2, the following performance metrics were observed for the Certificate Enrollment Web Service. Note that these metrics are not a guarantee of performance within customer environments, and that they can be dramatically impacted by the hardware and network configuration used in a given environment.
Enrollment service processing was as follows. The single biggest factor affecting throughput was network latency.
Enrollment service mode
Delegation configuration
Requests / second
W3wp.exe Memory consumption
W3wp.exe CPU consumption
Normal
Constraint with Kerb only auth
60
120 M
%20 to %40
Renewal only
None
170
150 M
Item
Value
Note
Call duration
0.39 – 0.45 second
The time Certificate Enrollment Web Service spends to process one request
Calls per second
33
How many requests Certificate Enrollment Web Service can process per second
The following metrics described the overall time required to complete various request types from the time the client initiated the request until the time it was completed.
Request type
Round trip time
Enroll
14 seconds
Renew
12 seconds
Retrieve CA cert
3 seconds
QueryTokenStatus
2 seconds
As noted in the previous section, the primary factor governing throughput of the Certificate Enrollment Web Services design is network latency. Thus, hardware requirements planning should first begin at the network layer by ensuring that all Certificate Enrollment Policy Web Service and Certificate Enrollment Web Service endpoints are connected over high bandwidth, low latency links to each other and to back end CAs. Ideally, Gigabit Ethernet will connect these systems and there will be few, if any, network hops separating them.
When considering server hardware, the standard hardware platform used for web servers in your organization is a good place to start. Typically, web services are more efficiently scaled ‘out’ rather than ‘up’. In other words, if additional capacity is needed in the future, it’s typically more effective to add additional nodes, rather than adding memory or CPU capacity to existing ones. Policy and Certificate Enrollment Web Service endpoints can also be good candidates for running in a virtualized environment, such as Hyper-V. Return to top
Rather than relying on network load balancing (NLB) technologies, the Certificate Enrollment Policy Web Service and Certificate Enrollment Web Service client components have load balancing and fault tolerance logic built in. For example, the clients will automatically randomize the list of endpoints they’re provided and attempt to iterate through the list if the first endpoint is unresponsive. Thus, as long as multiple uniform resource identifiers (URIs) are published, basic load balancing and fault tolerance is built in.
Note that NLB should not be used to provide fault tolerance or high availability because NLB could route traffic to a host where the policy or web service is stopped or unavailable. If all endpoints are published behind a single NLB balanced URI, the built in client logic would not be able to try the next URI, which would result in a less fault tolerant solution than if no special load balancing was used at all.
General best practices for load balancing the policy and enrollment web services include:
Publish multiple enrollment and policy URIs, each with unique DNS names and preferably available through different network paths; allow the built in client logic to provide load balancing and fault tolerance
Do not publish multiple URIs behind a single URI (unless that URI is load balanced behind a device that is both network and application layer aware).
Do not use DNS round robin or other DNS load balancing techniques that do not provide application layer intelligence and routing
For Group Policy configured policy settings, you can configure two servers (URLs) as part of the same policy. As a result, both policy server URLs will be functionally equivalent. The client then selects one URL to use, based upon the following rules:
Note: To configure the load balancing behavior described below, Group Policy configured settings must be used. User configured policies do not enable multiple URLs to be configured as part of the same policy.
Once a policy server is selected there may be multiple enrollment servers to choose from. The client will pick an enrollment server using the URI that has the lowest priority number as defined in the enrollment policy. If two enrollment servers have the same priority, then:
The following sections discuss different configurations depending on the circumstances of the organization.
The most simple deployment scenario involves a single forest with intranet connected clients. In this design, the Certificate Enrollment Policy Web Service and Certificate Enrollment Web Service may be installed on an issuing CA, but it is recommended that they are installed on separate computers. If the Certificate Enrollment Policy Web Service and Certificate Enrollment Web Service are run on separate computers, the Certificate Enrollment Policy Web Service must be able to communicate with AD DS using LDAP. The Certificate Enrollment Web Service must be able to connect to the CA using DCOM. In intranet scenarios, Kerberos would typically be selected as the authentication type.
A more advanced intranet scenario involves multiple forests with centralized issuing services in only one (or some) of them. In this design, the forests are connected with a two-way forest trust and the CA and the certificate enrollment web services are hosted in the same forest. The advantages of this model are that it provides for a high degree of consolidation in multiple forest environments. Whereas in the past, each forest required its own CA for auto-enrollment, now all PKI services can be centralized, potentially resulting in a large reduction of the total number of CAs required. Again, because this is an intranet scenario, the most common authentication scheme to use would be Kerberos. Return to top
A new deployment option not previously feasible is a perimeter network or branch office facing Certificate Enrollment Web Service. Specifically, this deployment scenario provides the ability to enroll users and computers that are not directly connected to an organization’s network or connected over a virtual private network (VPN). In this design, the Certificate Enrollment Policy Web Service and the Certificate Enrollment Web Service are both placed in the perimeter network, and internet based clients enroll over HTTPS to these endpoints. This deployment model is ideally suited to domain users who often work remotely or branch office scenarios in which the VPN or direct connection back to the corporate network is unreliable. The scenario is depicted below. Note that a Read Only Domain Controller (RODC) can optionally be used. The external clients (remote users) have no access through the Corp firewall to the writeable domain controller or to the CA. The enrollment and policy web service servers have no access to the writeable domain controller. However, the Certificate Enrollment Web Service must be allowed to connect through the firewall to the CA over DCOM.
In perimeter network deployments, certificate or username and password based authentication would most likely be used by the clients to authenticate to the Certificate Enrollment Web Services. Return to top
For the Certificate Enrollment Web Service to be able to request certificates from a CA, it needs to delegate the call to the CA while impersonating the caller. This in turn means that the Certificate Enrollment Web Service account should have delegation enabled. For internet facing Certificate Enrollment Web Service endpoints, this may not be preferred because it represents an increased level of exposure to internet based threats.
To mitigate this risk, renewal-only mode allows the Certificate Enrollment Web Service to process only certificate renewal requests without delegation enabled. The Certificate Enrollment Web Service uses the original certificate, provisioned from within the internal network, to authenticate the renewal request sent over the internet. The Certificate Enrollment Web Service will then submit the request to the CA under its own credential, and the CA will renew the certificate based on the Active Directory information of the requester of the original certificate and/or the subject information in the original certificate. In this mode, new certificate enrollment requests will be denied by the Certificate Enrollment Web Service and will never reach the CA.
From a network design perspective, this scenario combines both the internal and perimeter network models discussed previously.
Key-based renewal mode is a feature introduced in Windows Server 2012 that allows an existing valid certificate to be used to authenticate its own renewal request. This enables computers that are not connected directly to the internal network the ability to automatically renew an existing certificate. To take advantage of this feature, the certificate client computers must be running at least Windows 8 or Windows Server 2012. You can use key-based renewal to allow certificate client computers outside your AD DS forest to renew their certificates before they expire. This includes clients that are configured in workgroups or clients that are members of other AD DS forests. An account in the forest of the CA must be used in order to obtain the initial certificate. However, once that certificate is distributed to the client, key-based renewal does not require forest trusts in order to allow for certificate renewal. Web1 must also have the root CA certificate in the Trusted Root Certification Authorities store before requesting a certificate renewal. For example, a certificate issued to a web server configured in a workgroup could be renewed by an Enterprise CA domain member. An example of such a configuration is shown in the following figure. Web1.treyresearch.com (Web1) is a member of a workgroup that has a certificate issued by CA1.corp.contoso.com (CA1). The certificate is valid for both Client Authentication and Server Authentication. CA1 is an Enterprise CA and member of the AD DS domain corp.contoso.com. Web1 can utilize Certificate Enrollment Web Services to renew its certificates automatically if key-based renewal is enabled. In this scenario, an administrator of Web1 would have to ensure that the URI of the Certificate Enrollment Policy Web Service is configured on Web1. You can see a step-by-step test lab guide demonstration of a similar scenario in Test Lab Guide: Demonstrating Certificate Key-Based Renewal. Another example configuration for key-based renewal is to allow for the automatic renewal of certificates that were provisioned across domains. For example, an initial certificate with the Client Authentication EKU from CA1.corp.contoso.com is requested by using a user account in the Corp.contoso.com domain. That certificate is then placed on Client1.cpandl.com. Client1 must also have the root CA certificate in its Trusted Root Certificate Authorities store before requesting a certificate renewal. Client1 is a member of the Cpandl.com domain. CA1 is an Enterprise CA in the corp.contoso.com domain. CA1.corp.contoso.com and Client1.cpandl.com are members of different forests. There is not a forest trust joining the two forests. Client1 can use key-based renewal to automatically renew its certificate with CA1. The URI of the Certificate Enrollment Policy Web Service can be distributed to Client1 using Group Policy configured on Cpandl.com. Note: The URI for the Certificate Enrollment Policy Web Service is something that you have to configure on certificate clients so they can locate the service. The URI for the service is set in the Internet Information Service (IIS) on the computer running Certificate Enrollment Policy Web Service. The URI has ADPolicyProvider_CEP as part of its name. Additional information about the URI is part of the Installation and Initial Configuration informational links in the following section. Note: You can see a step-by-step test lab guide demonstration of a cross-forest certificate enrollment scenario in the TechNet Wiki article Test Lab Guide Mini-Module: Cross-Forest Certificate Enrollment using Certificate Enrollment Web Services. Return to top
The methods and steps for the installation of Certificate Enrollment Web Services vary depending upon the operating system version on which you are implementing them. Certificate Enrollment Web Service and the Certificate Enrollment Policy Web Service running for Windows Server 2008 R2 can be installed using Server Manager only. The installation and configuration steps for these services on Windows Server 2008 R2 are described in the Certificate Enrollment Web Services in Windows Server 2008 R2 whitepaper. However, on computers running Windows Server 2012, you can install the Certificate Enrollment Web Service and Certificate Enrollment Policy Web Service using Server Manager or Windows PowerShell. The location of the installation instructions for computers running Windows Server 2012 vary depending upon the service and type of installation as follows: Instructions for installing and initially configuring the Certificate Enrollment Web Service on Windows Server 2012
Instructions for installing and initially configuring Certificate Enrollment Policy Web Service on Windows Server 2012
Note: If you need to install Certificate Enrollment Web Services on Server Core, use Windows PowerShell.
The Windows client contacts a Certificate Enrollment Policy Web Service to get certificate policy information consisting of:
There are two ways to configure the Certificate Enrollment Policy Web Service for users and computers: through Group Policy or locally on the client.
Once configured, applicable certificate enrollment policies will appear in the certificate enrollment wizard during interactive enrollments. The image below shows a Group Policy configured certificate enrollment policy named “Contoso Corporate Policy”. User configured policies appear under Configured by you.
When the client is asked to enroll, it will first enumerate enrollment policies that are registered on the computer. For each type of certificate (user or computer), the Group Policy configured certificate enrollment policies are enumerated first, then the user configured policies
Group policy configured policy server settings (listed under “Configured by your administrator” in the Certificate enrollment wizard) are stored under the following registry locations:
For user certificate policy
HKEY_CURRENT_USER\Software\Policies\Microsoft\Cryptography\PolicyServers\
For computer certificate policy
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\PolicyServers\
User configured policy server settings (listed under “Configured by you” in the Certificate Enrollment wizard) are stored under the following registry locations:
HKEY_CURRENT_USER\Software\Microsoft\Cryptography\PolicyServers\
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\PolicyServers\
In these locations, you will find a registry key for each URL. Each key is a hash of the URL. Under the registry key there are the following settings:
When the Certificate Enrollment Policy Web Service is contacted, the client obtains policy and maintains a local cache. Client computers store enrollment policy for the computer computer and user in different locations:
In the cached certificate enrollment policy file, there is an XML element called nextUpdateHours. This file determines how long the cache file is valid. After that period of time, the certificate enrollment policy must be obtained again from the server. Return to top
When a user or computer accesses an enrollment policy server or an enrollment server, the user or computer must authenticate to the service. If the authentication method is username/password or client authentication certificate then a pop-up will appear asking for credentials.
The checkbox “Remember my credentials” can be checked to store credentials on the local system in the vault. Credentials are encrypted. Subsequent connections using the client to the same Certificate Enrollment Policy Web Services server or Certificate Enrollment Web Services server will attempt to use the credential stored in the vault.
You can browse the user vault through the user interface by going to Control Panel->User Accounts->Credential Manager. There is no user interface to browse the computer vault. However, the certutil -credstore command allows you to display the vault for the computer and user. It also will allow you to add and remove entries from either credential vault.
Storing credentials in the vault is useful when auto-enrollment is used. If auto-enrollment cannot authenticate to the service, it will skip that service and be unable to enroll/renew the certificate. Auto-enrollment will attempt to use credentials stored in the vault to authenticate to a service.
Devices running Windows RT cannot join an AD DS domain, which prevents them from being able to utilize domain-based certificate enrollment options. However, devices running Windows RT can use Certificate Enrollment Web Services to obtain and renew certificates. If Certificate Enrollment Web Services are configured to allow user name and password authentication, a user or administrator of a device running Windows RT could connect to the Certificate Enrollment Policy Web Service URI to obtain an initial certificate by supplying domain user credentials. After the initial certificate is placed on the device running Windows RT, key-based renewal can be used to renew the certificate before it expires. For more information, see the PKI blog article: Certificate for WinRT devices and non-domain member devices.
The following commands are provided as a reference for use in advanced configuration scenarios, such as disaster recovery or troubleshooting and are not required for default usage.
certutil –config “{CA Config String}” –enrollmentServerURL
Enrollment Server URL[0]: Priority 1
Authentication 4
Username – 4
AllowRenewalsOnly 0
https://enrollmentserver.contoso.com/CA1_CES_UsernamePassword/service.svc/CES
certutil –config “{CA Config String}” –enrollmentServerURL https://enrollmentserver.contoso.com/CA1_CES_UsernamePassword/service.svc/CES delete
certutil –config “{CA Config String}” –enrollmentServerURL https://enrollmentserver.contoso.com/CA1_CES_UsernamePassword/service.svc/CES {AuthType} {Priority} {AllowRenewalsOnly}
where:
AuthType = either “UserName” or “ClientCertificate”
Priority = 1
AllowRenewalsOnly = 1
There are multiple types of logging that you can enable to help in diagnosing issues with Certificate Enrollment Web Services. The following sections discuss these types of logging. Return to top
Certificate Enrollment Policy Web Service and Certificate Enrollment Web Service utilize the Windows Eventing infrastructure for logging. Event Viewer can be used to view and manage their logs, by drilling down into the following locations:
Applications And Services Logs\Microsoft\Windows\EnrollmentPolicyWebService
Applications And Services Logs\Microsoft\Windows\EnrollmentWebService
Locations of web.config files:
for Certificate Enrollment Policy Web Service: <%windir%>\systemdata\CEP\ADPolicyProvider_CEP_<Authentication Type>\web.config
for Certificate Enrollment Web Service:
<%windir%>\systemdata\CES\<CA Name>_CEP_<Authentication Type>\web.config
The event log level can be changed by adding a new key/value to the web.config file under the <AppSettings> section at the end of the file:
For the Enrollment Policy Server
<add key="LogLevel" value="4" />
For the Enrollment Server
<add key="EventLogLevel" value="4" />
Event Log level values available:
Description Value
Off 0
Error 1
Warning 2
Info 3
Verbose 4 Return to top
When Event Logging does not help to investigate an Enrollment Policy Server or Enrollment Server issue, tracing can be enabled to show any exceptions or communication problems at the Windows Communication Foundation layer.
Certificate enrollment web services are web applications. To configure them to trace run time logs, open the web.config file and follow the steps below.
1. Find the following section in the web.config file:
<system.diagnostics>
<sources>
<source name="System.ServiceModel" switchValue="Off" propagateActivity="true">
2. Change the value "Off" can be changed to any of the following Debug Level Tracing values : Critical, Error, Warning, Information, Verbose, ActivityTracing, All.
Trace Log File Locations:
Enrollment Policy Server
Location:
<%windir%>\systemdata\CEP\ADPolicyProvider_CEP_<Authentication Type>\Traces\
Files:
Traces-ADPolicyProvider.xml
Traces-PolicyServer.xml
Traces-ServiceModel-PolicyServer.xml
Enrollment Server
<%windir%>\systemdata\CES\<CA Name>_CES_<Authentication Type>\Traces\
Traces-EnrollmentServer.xml
Traces-ServiceModel-EnrollmentServer.xml
If the Tracing directory does not exist, create the directory and give read and write permissions to the application pool credentials the Certificate Enrollment Web Service or Certificate Enrollment Policy Web Service uses. If necessary, open the web.config in service configuration editor and modify trace settings appropriately.
tracelog.exe -rt -start schannel -guid #37D2C3CD-C5D4-4587-8531-4696C44244C8 -f .\schannel.etl -flags 0x4000ffff -ft 1
tracelog -stop schannel
tracefmt -p <symbols location>\traceformat schannel.etl -o schannel.out
Certsrv logging is useful to help determine why a request from Enrollment Server to the Certification Authority has failed.
To enable CA debug logging, enter the following command on the CA machine :
certutil –setreg ca\debug 0xffffffe3
The log file is in the following location: %windir%\certsrv.log
The enrollment policy service uses the CertEnroll client to read templates. Any failure in this process may be captured by the CertEnroll debug log on the policy server.
To enable debug logging for the CertEnroll client, execute the following command:
Certutil –setreg enroll\debug 0xffffffe3
The log file is in the following location by default: %windir%\CertEnroll.log
On the computer running the Certificate Enrollment Web Policy Service, the log file may be located in the profile directory for the identity of the policy service application pool (WSEnrollPolicyWebServer): %Systemroot%\Users\WsEnrollmentPolicyServer
LDAP tracing can be useful to troubleshoot communications between the certificate enrollment policy service and Active Directory.
Steps to enable LDAP Tracing ( using the Enrollment Policy Server w3wp.exe as an example )
For more information on LDAP tracing, see the following MSDN article: http://msdn.microsoft.com/en-us/library/aa366152(VS.85).aspx
In cases where requests seem to make it to Certificate Enrollment Web Service but are not properly received by the CA, it can be useful to log DCOM traffic between the enrollment service and the CA. This method provides more application specific protocol data than a network trace and is typically easier to parse. Note that Certificate Enrollment Web Service automatically sends the URI used in requests to the CA for diagnostic usage.
CertEnroll / CryptoAPI
Web Services client (WebServices.dll)
WinHTTP / SOAP
SSL / Kerberos
To see all HTTP requests the web services client sends to the policy and enrollment service, enable WINHTTP logging.
Use the following command:
netsh winhttp set tracing trace-file-prefix="d:\temp\winhttplog" level=verbose format=hex state=enabled
The file is located in %systemdrive%\temp\
The filename starts with “winhttplog*”.