最近新的业务服务使用 ASP.NET Core 2.1 来实现，开发环境是 Windows 正常，然后放到测试服务器 CentOS 7 也一切正常。测试通过后部署到阿里云的 CentOS 7 上，在安装完其它需要的环境后，跑其它业务一直正常，但有一个业务需要 HttpClient 调用其它 https 的 RESTful 接品报了异常，在该服务器上调用 dotnet restore 会有同样的错误
The SSL connection could not be established
网上找解决方法，.NET Core 2.1 中对 Sockets 进行重大改进，NET Core 2.1中的更高层级网络 API（包括HttpClient和Kestrel）现在基于.NET sockets.。在早期版本中，这些更高级别的API基于原生网络实现。新的实现最大的成就就是性能，它比现有的实现快得多，还有其他好处。默认 HttClient 使用了新的实现，网上解决方案把环境 DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER 将该值设置为 false 或 0，就使用 .NET Core 2 一样实现。在启动时代码中加入也可以实现同样的效果
AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler"，false);
但这个方案在我们的服务器上行不能，调用 HttpClient 请求 https 直接报 Segmentation fault 崩溃，啥日志也没记有
在网上找到原因，是调用了旧版 libcrypto.so.1.0.0 导致的，网上有 Debian 解决方法
apt-get remove ssl1.0.0.0
但我在服务看并没有安装有这个，只能另想办法，下面是解决的步骤
1. 用 GDB 调试 Segmentation Fault 错误位置
# gdb --args dotnet SSLTestApp.dll (gdb) r [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib64/libthread_db.so.1". [New Thread 0x7ffff5e2c700 (LWP 10161)] [New Thread 0x7ffff562b700 (LWP 10162)] [New Thread 0x7ffff4e2a700 (LWP 10163)] [New Thread 0x7ffff42b0700 (LWP 10164)] [New Thread 0x7ffff7e74700 (LWP 10165)] [New Thread 0x7fffeea42700 (LWP 10166)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffeea42700 (LWP 10166)] 0x00007fffeeb9b2e0 in trust_1oidany () from /usr/local/lab/openssl/lib/libcrypto.so.1.0.0 Missing separate debuginfos, use: debuginfo-install dotnet-hostfxr-2.1-2.1.2-1.x86_64 dotnet-runtime-2.1-2.1.2-1.x86_64
2. 原来是安装 PHP 环境时安装依赖了旧版的 libcrypto，并改了 /usr/local/lab/openssl 链接到旧版，知道就好解决了。
3. 将 /usr/local/lab/openssl 软链接到新的位置即可
unlink /usr/local/lab/openssl ln -s /usr/local/ssl /usr/local/lab/openssl
评论列表，共 0 条评论
暂无评论