Warning: If you do not perform these additional steps, then your certificate clients will receive the following error message when they attempt to enroll for a certificate using Certificate Enrollment Web Services: The endpoint address URL is invalid
Tip: You can accomplish the same thing using the command line with appcmd for IIS Open a Command Prompt or Windows PowerShell as an administrator on the computer that is running the Certificate Enrollment Web Services. Change to the %systemroot%\system32\inetsrv directory, so you can use the appcmd utility. Run the command appcmd list apps to see a list of applications running on the computer. Identify the Certificate Enrollment Web Services application that you want to modify. This application should have CES in the APP name and is typically running in the applicationPool:WSEnrollmentServer. Run the command appcmd list config "Default Web Site/<appname>" /section:appsettings. Replace the <appname> with the name of the Certificate Enrollment Web Services application that you identified in the previous step. Run the command appcmd config "Default Web Site/<appname>" /section:appsettings /"[key='URI'.value:"<newURI>". Replace <appname> with the application name you identified in step 3. Replace <newURI> with the same URI that you saw in Step 4, except for each space in the URI, replace it with %20. See the following figure for an example of these commands. Restart the IIS server (iisreset).
The Windows PowerShell script in this section performs the following tasks:
Note: You may have to modify your Windows PowerShell executionpolicy implementation to run the script and you will have to be a local IIS Administrator. You can copy and paste the following script into a file PS1 file. Ensure that you run it from an elevated Windows PowerShell prompt.
The script in this section performs the following:
The advantages of this script (compare to the previous solution that uses certutil.exe tool) are: a) Do not require manual CA name typing. The script automatically checks all CES URLs in Active Directory; b) do not require manual character replacement. URLs are encoded automatically; c) keeps URL parameters (priority, authentication, renewal settings) without a change. A caller is not required to update them manually; d) handles all additional special characters (not only space character) that require additional encoding. Note: You may have to modify your Windows PowerShell executionpolicy implementation to run the script and you will have to be running the script as a member of Enterprise Admins (or have the necessary permissions to write to the Active Directory Configuration container). You can copy and paste the following script into a file PS1 file. Ensure that you run it from an elevated Windows PowerShell prompt.
001002003004005006007008009010011012013014015016017018019020021022023024025026027028029Add-Type -AssemblyName System.Web# Connect to Enrollment Services container in configuration naming context$RootDSE = [ADSI]"LDAP://RootDSE"$ConfigContext = "CN=Enrollment Services,CN=Public Key Services,CN=Services," + $RootDSE.configurationNamingContext$adsi = [ADSI]"LDAP://$ConfigContext"$adsi.psbase.Children | ForEach-Object { if (!$_) {return} # prepare an array for new (fixed) URLs $entries = @() # enumerate all CES URLs for the current CA server $_."msPKI-Enrollment-Servers" | ForEach-Object { if (!$_) {return} # retrieve priority, authentication and renewal settings. They are not changed. $priority = $_[0].ToString() $authentication = $_[2].ToString() $RenewalOnly = $_[4].ToString() # extract current URL. We use regexp to grab only required part if ($_ -match "https.+service\.svc/CES") { $url = $matches[0] # encode extracted URL if necessary. If no encoding is required, the URL is not changed $url = [web.httputility]::UrlPathEncode($url) # build final entry for current CES entry and add it to array $entries += $priority + "`n" + $authentication + "`n" + $RenewalOnly + "`n" + $url } } # write encoded URLs back to Active Directory $_."msPKI-Enrollment-Servers" = $entries $_.SetInfo()} Acknowledgement: Thanks to Vadims Podans for his contribution of the Windows PowerShell scripts
Is there any way to fix this issue when there is no web services enrollment, just straight up AD enrollment?
-------------------------
Answer by Kurt Hudson: If you mean enrolling inside the domain using Windows client computers, you should not require any modifications. However, Brian Komar has discovered that there is an issue in this area with NDES enrollment (non-Windows devices) do not understand the lack of %20 in the URL. A code fix/patch (software update) was written and has been preliminarily tested by Brian. However, it is not yet publically released. That is probably more information than you were seeking, but it is relevant to this issue. In short, this issue should not affect any standard certificate enrollment requests from domain joined Windows client computers.
That is as much as I know as of right now: May 2, 2013.
I think that no fix required when you use direct AD enrollment.