.net 调试失败HTTPS WebRequest

olhwl3o2  于 2023-05-19  发布在  .NET
关注(0)|答案(3)|浏览(155)

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

gzszwxb41#

在上面画点痕迹!在调试这些东西时,跟踪是您最好的朋友。我曾经有一个客户端无法连接到我们启用SSL的服务。通过跟踪,我发现有人将系统时钟移到了我们的证书到期日期之后。但我跑题了。
启用所有适用的跟踪源,并查看日志中是否出现了一些有趣的内容。
有一个旧的(2005年),但excellent post由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>

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

nfs0ujit

nfs0ujit2#

一些想法:

  1. TLS定义了一些错误代码和警报。SSL/TLS库通常在抛出异常时提供此代码。也许你可以在服务器日志中找到这些信息。
    1.服务器发送证书链时可能缺少一些证书。例如,如果服务器仅发送其证书,则如果存在某个中间CA证书,则客户端可能无法将此证书附加到根证书。
    1.如果客户端希望使用证书进行身份验证,则服务器应该发送接受的根证书的名称。我之前的观点在这里也是有效的,如果缺少一些中间证书,则无法在其证书和服务器发送的根之间构建链。客户端找不到合适的证书(因为私钥不可用)是另一个可能的问题。
xzv2uavs

xzv2uavs3#

我同意Markus上面的解决方案。我曾经遇到过类似的问题,我发现最好的办法是在调试器下获取异常。
如果您可以在本地运行一个构建并在调试器中查看该异常,那么在到达问题的真实的实质之前,您必须向下钻取几个级别。
在我所考虑的情况下,我必须查看4或5个innerException,然后才能看到具体告诉我错误的消息。
我发现这在.Net中的许多情况下都是正确的--你会得到一个异常,它有一个非常通用的错误消息,你需要深入几个“innerException”级别,然后才能看到问题的实质。
希望这能帮上忙。

相关问题