调试失败的 HTTPS Web 请求

本文关键字：Web 请求 HTTPS 失败 调试 | 更新日期: 2023-09-27 17:56:19

>我正在编写一个小程序，它将使用HTTPS和HttpWebRequest类向服务器发出GET请求。服务器（显然）具有服务器证书。它还希望客户端提供证书。

但是，在发出请求时，我收到一个System.Net.WebException，指出无法建立安全的TLS/SSL连接。我很快发现服务器的证书无效。假设这是导致异常的原因，我尝试使用以下代码接受无效证书（不幸的是，更新证书不是一种选择）：

ServicePointManager.ServerCertificateValidationCallback += delegate {
    return true;
};

然而，这并没有解决问题。

由于异常没有提供任何详细信息，因此很难实际确定导致它的原因。我覆盖无效服务器证书的尝试是否不起作用？服务器是否不信任我提供的客户端证书？我是否没有以正确的方式加载客户端证书？

我很想了解如何调试此类问题的提示。不幸的是，我无法访问服务器或其日志。

以下是代码的重要部分：

ServicePointManager.ServerCertificateValidationCallback += delegate {
    return true;
};
HttpWebRequest req = (HttpWebRequest)WebRequest.Create(url); // url is an HTTPS URL.
X509Certificate clientCert = new X509Certificate("certificate.crt", "password");
req.ClientCertificates.Add(clientCert);
WebResponse resp = req.GetResponse(); // This fails!

调试失败的 HTTPS Web 请求

在上面打一些描摹！在调试这些东西时，跟踪是你最好的朋友。我曾经有一个客户端无法连接到我们启用SSL的服务。使用跟踪，我发现有人将系统时钟移到了我们的证书到期日期之后。但我离题了。

启用所有适用的跟踪源，并查看日志中是否显示有趣的内容。

Durgaprasad Gorti有一篇古老的（2005年）但很棒的帖子，你应该看看。它将准确显示要添加的源，并且他还在其中使用自定义验证回调显示一些SSL跟踪。

来自同一篇博客文章的示例 app.config：

<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
  <system.diagnostics>
    <trace autoflush="true" />
    <sources>
      <source name="System.Net">
        <listeners>
          <add name="MyTraceFile"/>
        </listeners>
      </source>
    </sources>
    <sharedListeners>
      <add
      name="MyTraceFile"
      type="System.Diagnostics.TextWriterTraceListener"
      initializeData="System.Net.trace.log"
    />
    </sharedListeners>
    <switches>
      <add name="System.Net" value="Verbose" />
    </switches>
  </system.diagnostics>
</configuration>

希望这能为您提供更多数据。

一些想法：

  1. TLS 定义了一些错误代码和警报。SSL/TLS 库通常在引发异常时提供此代码。也许您可以在服务器日志中找到此信息。

  2. 当服务器发送其证书链时，可能会缺少一些证书。例如，如果服务器仅发送其证书，则如果存在一些中间 CA 证书，则客户端可能无法将此证书附加到根证书。

  3. 如果客户端需要使用证书进行身份验证，则服务器应发送接受的根证书的名称。我之前的观点在这里也是有效的，如果缺少一些中间证书，则无法在其证书和服务器发送的根之间构建链。客户端找不到合适的证书（因为私钥不可用）是另一个可能的问题。

我同意马库斯上面的解决方案。我曾经遇到过类似的问题，我发现最好的办法是在调试器下获取该异常。

如果可以在本地运行生成并在调试器中查看该异常，则必须向下钻取多个级别，然后才能找到问题的真正内容。

在我正在考虑的情况下，我必须浏览 4 或 5 个内部异常，然后才能获得具体告诉我问题所在的消息。

我发现在 .Net 中的许多情况下都是如此 - 你会得到一个异常，它有一个非常通用的错误消息，你需要在进入问题的实质之前向下潜入几个"innerException"级别。

希望这有帮助。

相关文章：