客户端和服务器无法通信，因为它们不具备通用算法 - SSLStream
client and server cannot communicate, because they do not possess a common algorithm - SSLStream
已经回答了很多类似的问题，none 个答案对我目前的情况有帮助。
在 windows 服务中，我们有 TCPL SSL 流和连接到该流的客户端。
我已经创建了一个 .NET 客户端，并且能够使用 IIS Crypto 通过 Strict TLS 1.2 成功访问服务器。
我们正在尝试使用 Lantronix xport Pro 访问服务器，但下面的行抛出异常
stream.AuthenticateAsServer(serverCertificate, false, SslProtocols.Ssl3| SslProtocols.Tls | SslProtocols.Tls11 | SslProtocols.Tls12, True);
仅当启用严格的 TLS 1.2 时才会发生异常。如果我们启用了 SSL3 协议，则一切正常，没有任何问题。
使用 WireShark，我可以看到客户端使用以下密码发送 TLS 1.2 请求
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
根据上面的 MSDN，密码支持 TLS 1.2
使用严格的 TLS 1.2
从我们为测试目的创建的 .net 客户端连接时没有任何问题
正在使用 open ssl 创建自签名证书。服务器是 运行 windows 服务器 2012 R2.
我不确定我应该为特定于 TLS 1.2 的 SSLstream 尝试哪些选项？
除了 .net 客户端通信之外，我还需要做什么特定的事情吗？
任何关于跟踪此问题的建议都很好
根据 Lantrix Pro 请求更新
Frame 33845: 112 bytes on wire (896 bits), 112 bytes captured (896 bits) on interface 0
Ethernet II, Src: Pronet_c7:bb:29 (00:20:4a:c7:bb:29), Dst: Vmware_99:95:c7 (00:50:56:99:95:c7)
Internet Protocol Version 4, Src: 10.10.110.71, Dst: 10.10.110.10
Transmission Control Protocol, Src Port: 38182, Dst Port: 28000, Seq: 1, Ack: 1, Len: 58
Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 53
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 49
Version: TLS 1.2 (0x0303)
Random: 8a f5 6f 9e 92 65 43 c7 45 9b 57 ff dd a4 22 45 ...
GMT Unix Time: Nov 16, 2043 20:38:22.000000000 Central Standard Time
Random Bytes: 92 65 43 c7 45 9b 57 ff dd a4 22 45 12 16 cb 41 ...
Session ID Length: 0
Cipher Suites Length: 10
Cipher Suites (5 suites)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 (0x0060)
Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x0064)
Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)
TL;DR：客户端坏了。看起来供应商几乎没有向旧产品添加最少的 TLS 1.2 支持，同时保留不安全的密码并且未能添加对当前使用的 SHA-256 签名证书的支持。
客户端只发送一个非常小的 TLS 1.2 握手。它只包含 5 个密码（其中 3 个 EXPORT 密码严重不安全，3DES 密码稍微不安全，但 AES128-SHA 是可以接受的）。而且，与其他 TLS 成功的 1.2 握手相比，它不包含 signature_algorithm TLS 扩展。
此扩展是 TLS 1.2 的新扩展。它用于告诉服务器支持哪些签名算法。如果未提供扩展名，它将默认为 SHA1 和 RSA 提供的密码。从 RFC 中引用：
If the client does not send the signature_algorithms extension, the
server MUST do the following:
- If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
sent the value {sha1,rsa}.
但是，服务器提供了一个带有 RSA 密钥但以 SHA-256 作为散列的证书。因此，该证书将与接受的签名算法不匹配，并且握手失败。如果服务器改为允许 TLS 1.1 或更低版本，则握手将成功，因为这些较低协议版本会忽略 signature_algorithm 扩展，因此服务器可以发送它拥有的 SHA-256 签名证书。
从提供的 pcaps 中使用 openssl s_client 的捕获可以看出，如果客户端提供 signature_algorithm 扩展并支持 RSA 和 SHA-256，则 TLS 1.2 握手有效。
已经回答了很多类似的问题，none 个答案对我目前的情况有帮助。
在 windows 服务中，我们有 TCPL SSL 流和连接到该流的客户端。
我已经创建了一个 .NET 客户端，并且能够使用 IIS Crypto 通过 Strict TLS 1.2 成功访问服务器。
我们正在尝试使用 Lantronix xport Pro 访问服务器，但下面的行抛出异常
stream.AuthenticateAsServer(serverCertificate, false, SslProtocols.Ssl3| SslProtocols.Tls | SslProtocols.Tls11 | SslProtocols.Tls12, True);
仅当启用严格的 TLS 1.2 时才会发生异常。如果我们启用了 SSL3 协议，则一切正常，没有任何问题。
使用 WireShark，我可以看到客户端使用以下密码发送 TLS 1.2 请求
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
根据上面的 MSDN，密码支持 TLS 1.2
使用严格的 TLS 1.2
从我们为测试目的创建的 .net 客户端连接时没有任何问题正在使用 open ssl 创建自签名证书。服务器是 运行 windows 服务器 2012 R2.
我不确定我应该为特定于 TLS 1.2 的 SSLstream 尝试哪些选项？
除了 .net 客户端通信之外，我还需要做什么特定的事情吗？
任何关于跟踪此问题的建议都很好
根据 Lantrix Pro 请求更新
Frame 33845: 112 bytes on wire (896 bits), 112 bytes captured (896 bits) on interface 0
Ethernet II, Src: Pronet_c7:bb:29 (00:20:4a:c7:bb:29), Dst: Vmware_99:95:c7 (00:50:56:99:95:c7)
Internet Protocol Version 4, Src: 10.10.110.71, Dst: 10.10.110.10
Transmission Control Protocol, Src Port: 38182, Dst Port: 28000, Seq: 1, Ack: 1, Len: 58
Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 53
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 49
Version: TLS 1.2 (0x0303)
Random: 8a f5 6f 9e 92 65 43 c7 45 9b 57 ff dd a4 22 45 ...
GMT Unix Time: Nov 16, 2043 20:38:22.000000000 Central Standard Time
Random Bytes: 92 65 43 c7 45 9b 57 ff dd a4 22 45 12 16 cb 41 ...
Session ID Length: 0
Cipher Suites Length: 10
Cipher Suites (5 suites)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 (0x0060)
Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x0064)
Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)
TL;DR：客户端坏了。看起来供应商几乎没有向旧产品添加最少的 TLS 1.2 支持，同时保留不安全的密码并且未能添加对当前使用的 SHA-256 签名证书的支持。
客户端只发送一个非常小的 TLS 1.2 握手。它只包含 5 个密码（其中 3 个 EXPORT 密码严重不安全，3DES 密码稍微不安全，但 AES128-SHA 是可以接受的）。而且，与其他 TLS 成功的 1.2 握手相比，它不包含 signature_algorithm TLS 扩展。
此扩展是 TLS 1.2 的新扩展。它用于告诉服务器支持哪些签名算法。如果未提供扩展名，它将默认为 SHA1 和 RSA 提供的密码。从 RFC 中引用：
If the client does not send the signature_algorithms extension, the server MUST do the following:
- If the negotiated key exchange algorithm is one of (RSA, DHE_RSA, DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent the value {sha1,rsa}.
但是，服务器提供了一个带有 RSA 密钥但以 SHA-256 作为散列的证书。因此，该证书将与接受的签名算法不匹配，并且握手失败。如果服务器改为允许 TLS 1.1 或更低版本，则握手将成功，因为这些较低协议版本会忽略 signature_algorithm 扩展，因此服务器可以发送它拥有的 SHA-256 签名证书。
从提供的 pcaps 中使用 openssl s_client 的捕获可以看出，如果客户端提供 signature_algorithm 扩展并支持 RSA 和 SHA-256，则 TLS 1.2 握手有效。