Inconsistent header transforms defaults between YARP and Forwarder

YARP Direct Proxy for one of the endpoint screams with the following error:

The SSL connection could not be established, see inner exception

Inner exception says:

Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.

In the current, non-YARP proxy solution, the problem is solved (or rather, by-passed) by setting the ServerCertificateCustomValidationCallback flag:

public class IgnoreSslHandler : HttpClientHandler
{
    public IgnoreSslHandler()
    {
        if (Environment.IsDevelopment())
        {
            ServerCertificateCustomValidationCallback = DangerousAcceptAnyServerCertificateValidator;
        }
    }
}

But, HttpMessageInvoker with the HttpClientHandler that has the ServerCertificateCustomValidationCallback flag set to either true or to DangerousAcceptAnyServerCertificateValidator doesn’t seem to be used in the YARP.

Code snippet that is used for proxy context:

await httpProxy.ProxyAsync(httpContext, "https://url", httpClient, requestOptions, transformer);

Any idea how to solve that?

[Tratcher]

Ok, one more theory: HttpTransformer.TransformRequestAsync copies over all the request headers, including the external Host. That Host is used in the TLS SNI handshake rather than the host specified in the destination url. The destination doesn’t have a certificate matching that external Host so it refuses the connection.

In the full proxy flow we remove the external host by default to avoid this kind of conflict. You can do this in the direct proxy like this: https://github.com/microsoft/reverse-proxy/blob/2593b4c009f2c3a131cd4bf327115976aad2d7a6/samples/ReverseProxy.Direct.Sample/Startup.cs#L98-L99

HttpTransformer.Default should probably be updated to reflect the same defaults as the full proxy flow:

• X-Forwarders on
• OriginalHost off

[Tratcher]

HttpClient vs HttpMessageInvoker shouldn’t affect the SSL behavior.

Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.

That says the remote server terminated the connection, that’s not caused by a trust issue on your end. Do you have access to the remote server logs to find out why it killed the connection?