调试失败的 HTTPS WebRequest

Question

我正在编写一个小程序，它将使用 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!

Answer 1

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

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

有一个旧的（2005）但是Durgaprasad Gorti 的优秀帖子，您应该看看。它将准确地向您显示要添加的源，并且在其中还使用自定义验证回调显示了一些 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>

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

Answer 2

一些想法：

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

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

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

Answer 3

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

如果您可以在本地运行构建并在调试器中查看该异常，那么您必须深入几个级别才能了解问题的实质。

在我想到的情况下，我必须先查看 4 或 5 个内部异常，然后才能看到具体告诉我出了什么问题的消息。

我发现在 .Net 中的许多情况下，这往往是正确的 - 您将得到一个异常，其中包含非常通用的错误消息，并且您需要深入了解几个“innerException”级别，然后才能解决问题的实质。

希望这有帮助。