AWS Lambda .NET Core 3.1 请求API出现SSL连接建立失败认证异常

该故障90%以上概率和Let's Encrypt旧交叉签名根证书（DST Root CA X3）过期、.NET Core 3.1自带的根证书信任列表逻辑缺陷相关：其他平台请求正常是因为新操作系统/运行时已经信任了ISRG Root X1独立根证书，但AWS Lambda的.NET Core 3.1运行时环境的信任链校验逻辑存在特殊处理，刚好触发了校验失败。

可按以下优先级排查修复： #

• 第一步：调整API服务端证书链配置
  多数Let's Encrypt自动签发工具默认会保留包含DST Root CA X3的兼容证书链，.NET Core 3.1的校验逻辑会优先走旧根的校验路径，哪怕新根已经被信任也会校验失败。可手动把服务端证书链切换为仅包含ISRG Root X1的最短链，大部分场景改完即可恢复。
• 第二步：替换过时的WebRequest实现
  当前使用的WebRequestAPI在.NET Core中已经被标记为过时，底层SSL校验逻辑存在已知缺陷，建议替换为HttpClient单例实现，示例代码如下：

  // 注意HttpClient需设置为全局单例，不要每次请求都新建
  private static readonly HttpClient _httpClient = new HttpClient();
  // 请求逻辑
  using var request = new HttpRequestMessage(HttpMethod.Get, APIurl);
  request.Headers.Accept.Add(new System.Net.Http.Headers.MediaTypeWithQualityHeaderValue("application/json"));
  request.Headers.Authorization = new System.Net.Http.Headers.AuthenticationHeaderValue("Bearer", _APIToken); // 按实际认证Scheme调整
  using var response = await _httpClient.SendAsync(request, HttpCompletionOption.ResponseHeadersRead);
  response.EnsureSuccessStatusCode();
  // 后续处理响应内容
  

• 第三步：临时校验修复（仅建议应急使用，不推荐长期保留）
  如果需要快速恢复业务，可以在服务启动时添加全局证书校验回调，严格过滤合法证书的校验规则，不要直接跳过所有证书校验：

  ServicePointManager.ServerCertificateValidationCallback += (sender, cert, chain, sslPolicyErrors) =>
  {
      if (sslPolicyErrors == SslPolicyErrors.None) return true;
      // 此处填入你的API证书指纹或者Let's Encrypt合法证书的颁发者信息做校验
      return cert.Issuer.Contains("ISRG Root X1") && cert.GetCertHashString().Equals("你的证书大写指纹值");
  };
  

• 第四步：确认Lambda运行时环境配置
  检查近期是否更新过Lambda的层配置、运行时镜像：.NET Core 3.1已经停止官方支持，AWS的运行时镜像如果有隐性更新也可能导致根证书信任列表变更，有条件的话建议将运行时升级到.NET 6+的LTS版本，从根本上解决旧运行时的缺陷。

快速验证方法 #

可以在Lambda代码中添加证书链打印的调试逻辑，输出请求时获取到的证书链每个节点的颁发者、过期时间，即可直接定位是否触发了旧根证书的校验失败。

内容的提问来源于stack exchange，提问作者Aaron Gayle