这种证书验证失败的情况在测试环境出现、生产环境正常，大概率是测试环境的网络或证书配置和生产环境不一致导致的，下面是几个常见的排查和解决思路：

1. 检查测试环境是否使用了自定义S3端点（比如本地模拟服务或私有存储） #

如果你的测试环境用了MinIO、LocalStack这类模拟S3的服务，或者内部私有存储，它们的SSL证书可能是自签名的，而代码默认会严格验证证书有效性。解决方法：

• 如果你用的是AWS SDK for .NET，可以在客户端配置里临时跳过证书验证（重要提醒：仅在测试环境使用，生产环境绝对不能这么做，会带来安全风险）：

  var config = new AmazonS3Config
  {
      ServiceURL = "https://your-test-s3-endpoint",
      // 跳过证书验证逻辑
      ServerCertificateValidationCallback = (sender, cert, chain, sslPolicyErrors) => true
  };
  var s3Client = new AmazonS3Client(config);
  

• 更安全的方式是把测试环境的自签名证书添加到测试服务器的受信任根证书库中，让系统认可该证书的合法性。

2. 排查测试环境的网络代理/防火墙设置 #

不少公司的测试环境会通过代理访问外部服务，代理可能会替换S3的原始SSL证书（比如用公司内部证书做中间人代理），这就会导致证书验证不通过。解决方法：

• 联系运维团队，把S3的域名（比如*.amazonaws.com）添加到代理的「无需SSL拦截」白名单；
• 或者将代理使用的根证书安装到测试服务器的受信任证书存储中。

3. 确认测试环境的系统时间是否准确 #

SSL证书的有效性验证依赖于系统时间，如果测试服务器的系统时间和实际时间偏差过大（比如早于证书生效时间或晚于过期时间），也会触发证书验证失败。解决方法：

• 同步测试服务器的系统时间到公共NTP服务器，确保时间准确无误。

4. 检查AWS SDK版本和区域配置 #

旧版本的AWS SDK可能对某些区域的证书支持有缺陷，或者测试环境的S3区域配置和生产环境不一致，导致请求到了错误的端点。解决方法：

• 把AWS SDK升级到最新稳定版本；
• 确认测试环境的AmazonS3Config中指定的区域和实际使用的S3存储桶区域完全一致。

内容的提问来源于stack exchange，提问作者Mohammad Amir