Microsoft.AspNet.SignalR.Client启动报错：无法创建SSL/TLS安全通道

你此前的TLS相关配置全部添加在服务端，本次Could not create SSL/TLS secure channel报错是WPF客户端发起HTTPS握手阶段就失败，请求还未到达本地服务端，所以服务端配置不会生效。
出现两个ngrok地址表现不一致的核心原因是：

• 个人ngrok账号默认允许TLS1.0/1.1/1.2版本握手
• 客户ngrok账号（通常是企业版/付费版）后台默认配置了禁用低版本TLS，仅允许TLS1.2及以上版本握手
  而.NET Framework 4.5.2默认的全局TLS策略仅启用TLS1.0，所以访问客户ngrok地址时握手失败，Chrome浏览器自带独立的TLS栈不受.NET Framework策略限制，因此可以正常访问。

步骤1：在WPF客户端入口添加全局TLS配置 #

在WPF应用启动的最早执行节点（比如App.xaml.cs的OnStartup方法第一行，或者MainWindow构造函数的第一行）添加以下代码：

// 显式启用所有支持的TLS版本，优先使用高版本
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;
ServicePointManager.Expect100Continue = true;
// 开发环境临时跳过证书校验，生产环境建议移除，自行实现证书合法性校验逻辑
ServicePointManager.ServerCertificateValidationCallback += (sender, cert, chain, sslPolicyErrors) => true;

注意：.NET Framework 4.5.2原生已支持TLS1.2，不需要额外安装系统补丁，只要显式指定协议即可生效。

步骤2：确认客户ngrok账号的TLS配置 #

登录客户的ngrok管理后台，进入对应的端点配置页面，检查TLS最小版本设置：

• 如果设置为TLS1.3，请调整为TLS1.2，.NET Framework 4.5.2不原生支持TLS1.3协议
• 确认没有配置额外的IP白名单、客户端证书校验等限制规则

步骤3：验证非SignalR请求是否正常 #

添加配置后，可以先用普通HTTP请求测试客户ngrok地址是否能正常访问，排除SignalR本身的问题：

using (var client = new WebClient())
{
    // 输出内容正常则证明TLS配置已生效
    var result = client.DownloadString("客户ngrok的HTTPS根地址");
}

步骤4：重新测试SignalR连接 #

完成上述配置后重新启动WPF客户端，发起SignalR连接即可正常握手。

内容的提问来源于stack exchange，提问作者Ian GM