Description
example like:
System.Net.Http.Functional.Tests.SocketsHttpHandler_HttpClientHandler_SslProtocols_Test.GetAsync_AllowedSSLVersion_Succeeds(acceptedProtocol: Tls13, requestOnlyThisProtocol: False) [FAIL]
System.AggregateException : One or more errors occurred. (One or more errors occurred. (Authentication failed, see inner exception.)) (One or more errors occurred. (The SSL connection could not be established, see inner exception.))
---- System.AggregateException : One or more errors occurred. (Authentication failed, see inner exception.)
-------- System.Security.Authentication.AuthenticationException : Authentication failed, see inner exception.
------------ System.ComponentModel.Win32Exception : The client and server cannot communicate, because they do not possess a common algorithm.
---- System.AggregateException : One or more errors occurred. (The SSL connection could not be established, see inner exception.)
-------- System.Net.Http.HttpRequestException : The SSL connection could not be established, see inner exception.
------------ System.Security.Authentication.AuthenticationException : Authentication failed because the remote party sent a TLS alert: 'ProtocolVersion'.
---------------- System.ComponentModel.Win32Exception : The message received was unexpected or badly formatted.
There is some optimization in Windows that breaks the handshake in some uncommon cases. Following sequence will fail in step 3 if same SNI (e.g. TargetName) is used.
1) Client SslProtocol.None -> Server SslProtocol.Tls13
2) Client SslProtocol.None -> Server SslProtocol.Tls12
3) Client SslProtocol.None -> Server SslProtocol.Tls13
While this is not great, it seems like Windows is not going to be changed. To stabilize our tests we can use distinct SNI for each protocol version (or GUID)