Update April 8, 2025:

This issue has been fixed in the Forms 12 Spring 2025 Release: Accept the untrusted certificate set on the IIS server when validating the certificate used for WCF connections. (BugID: 565802)

You can see other changes from: Laserfiche 12 Release Information

Get the latest Laserfiche Forms 12 package from: Laserfiche 12 - Downloads

-------

We resolved this through a support case after digging through the source code to figure out exactly which function was resulting in this exception. The next release of the utility will contain an update that eliminates this misleading error.

Long story short:

If you see the error:

System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)
at System.Net.PooledStream.EndWrite(IAsyncResult asyncResult)
at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)
--- End of inner exception stack trace ---
at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)
--- End of inner exception stack trace ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at DMZConfigurationUtility.DMZConfignUtility.<ValidateCertificate>d__28.MoveNext()

This is NOT about the client certificate you're trying to configure, it's about the local https/443 certificate on the machine on which you're running the utility. Incredibly deceptive, in context. If there's a client certificate error, you should see the string "ERROR: Invalid certificate."

I'm going to share the function here, because it's helpful in understanding what goes wrong:

		private async Task ValidateCertificate(string thumbprint)
		{
			DMZConfigFileLogger.Current.LogTrace("Validating IIS access to certificate's private key.", "ValidateCertificate");

			var localFqdn = Dns.GetHostEntry("LocalHost").HostName;
			var URL = $@"https://{localFqdn}/Forms/webapi/v1/WcfSettings/ValidateIISRightsForCertificate?thumbprint={thumbprint.ToLower()}";
			HttpClient client = new HttpClient();
			client.BaseAddress = new Uri(URL);
			client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
			HttpResponseMessage response = await client.GetAsync("");
			if (response.IsSuccessStatusCode)
			{
				var result = await response.Content.ReadAsStringAsync();
				if (result != "\"Success\"")
				{
					throw new Exception(Resources.ERROR_CERTIFICATE_INVALID, new Exception(result));
				}
			}
			else
			{
				throw new Exception(string.Format(Resources.FAILED_TO_CONNECT, URL, string.Format(Resources.STR_HTTP_STATUS_CODE, response.StatusCode)));
			}
		}

This is the critical bit:

Dns.GetHostEntry("LocalHost").HostName;
var URL = $@"https://{localFqdn}/Forms/webapi/v1/WcfSettings/ValidateIISRightsForCertificate?thumbprint={thumbprint.ToLower()}"; 

The utility is making an HTTPS request to a web services endpoint for the local Forms IIS instance, passing the client certificate thumbprint as a URL parameter. The URL is constructed using the result of the .NET Dns.GetHostEntry("Localhost") function, which returns the hostname (FQDN if domain-joined) of the local machine.

You can run that exact function in PowerShell with:

[System.Net.Dns]::GetHostEntry("LocalHost")

In a typical DMZ scenario, machine is not domain joined and has a hostname like "FormsDMZ". Which means the constructed URL is:

https://FormsDMZ/Forms/webapi/v1/WcfSettings/ValidateIISRightsForCertificate?thumbprint=ABC123

And the TLS certificate bound to port 443 for IIS likely covers whichever nice DNS alias you're using, like "publicforms.example.com", and NOT the local machine hostname "FormsDMZ". 

The web request to the client certificate validation endpoint above subsequently fails to go through due to the hostname mismatch with the IIS TLS certificate and surfaces the system-level error:

System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

Ironic.

This can also affect the internal/primary Forms instance if you're using an alias (e.g., forms.example.com). and the internal IIS certificate doesn't cover the machine's FQDN hostname (e.g., lfprodweb01.example.com).

As a workaround, you can:

1. Generate a temporary certificate (self-signed or otherwise) that covers whatever the output of "[System.Net.Dns]::GetHostEntry("Localhost")" is as a Subject Alternative Name (SAN) ("FormsDMZ", etc.).
   1. If your client authentication cert already has the local hostname in its SAN field and also has the Server Authentication role ("Enhanced Key Usage"), you can use it for this purpose.
2. Trust it on the local machine (if necessary, as with a self-signed cert).
3. Swap the certificate binding for https/443 in IIS to use this temp cert.
4. Run the Forms Multi-Server Configuration Utility.
5. The web request to https://FormsDMZ/Forms/webapi/v1/WcfSettings/ValidateIISRightsForCertificate?thumbprint=ABC123 will pass TLS validation so the actual client certificate check occurs.
6. Resolve any other issues (open firewall ports to the internal/primary Forms instance, etc.) and complete configuration.
7. Swap the https/443 certificate back to the original one. Don't forget to do this.

We'll get a better way to handle this sorted out in a future update of the utility. In the meantime, the workaround above should get you past the error in these scenarios.