.NET通过TLS 1.2删除客户端证书 [英] .NET dropping client certificate over TLS 1.2

查看:105
本文介绍了.NET通过TLS 1.2删除客户端证书的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

您好,似乎已经以一百万种不同的方式询问了该问题的某种形式,但是许多问题没有答案,或者答案不适用于我.

Hello it seems some form of this question has been asked a million different ways but many don't have answers, or the answers don't apply to me.

我们有一个简单的.NET小服务,它可以调用现在仅支持TLS 1.2的第三方API.

We have a trivial little .NET service that calls out to a 3rd party API that is only supporting TLS 1.2 now.

        var requestHandler = new WebRequestHandler();
        var clientCert = GetClientCert("THUMBPRINT");

        requestHandler.ClientCertificates.Add(clientCert);
        var encodedHeader = "FOO";
        var httpClient = new HttpClient(requestHandler) { BaseAddress = new Uri("https://foo.bar.com/rest/api/") };
        httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", encodedHeader);

        var httpResponse = httpClient.GetAsync("").Result;
        var responseContent = httpResponse.Content.ReadAsStringAsync().Result;

当我将安全协议显式设置为1.2或以默认值为1.2的框架为目标时,客户端证书不是进入服务器的数据包的一部分.我已经在Wireshark中对其进行了检查,并且证书从未超过1.2.此时,服务器将发送致命警报握手失败(40),这将导致以下.Net异常:

When I explicitly set the security protocol to 1.2, or target a framework that defaults to 1.2, the client certificate is not part of the packet that goes to the server. I've examined it in Wireshark and the certs are never present over 1.2. At that point the server sends the Fatal Alert Handshake Failure (40) which results in the following .Net exception:

The request was aborted: Could not create SSL/TLS secure channel.

我可以通过Chrome或Postman(本机)拨打相同的电话,并且效果很好.如果我将协议设置为1.1,则可以正常工作.但是,如果我通过.NET将其运行为1.2,则每次都会失败.即使我根本不添加我的客户端证书,我在Wireshark中也会得到相同的确切错误和相同的流量.

I can make the same call through Chrome or Postman (native) and it works fine. If I set the protocol down to 1.1 it works fine. But if I run it as 1.2 through .NET it fails every time. I get the same exact error and same traffic in Wireshark even if I purposely do not add my client certificate at all.

我通过 https://www.ssllabs.com/运行了第三方端点,并且评分很好.我在任何一侧都看不到任何地方的MD5签名.一切都使用带有RSA加密的sha1或sha256签名.

I ran the 3rd party endpoint through https://www.ssllabs.com/ and it grades out fine. There are no MD5 signatures anywhere that I can see on either side. Everything is signed with sha1 or sha256 with RSA encryption.

我已启用跟踪.以下输出似乎表明查找证书或其私钥没有问题:

I have tracing enabled. The following output seems to indicate there is no issue finding the certificate or its private key:

System.Net Information: 0 : [19512] SecureChannel#41622463 - Certificate is of type X509Certificate2 and contains the private key.
System.Net Information: 0 : [19512] SecureChannel#41622463::.AcquireClientCredentials, new SecureCredential() (flags=(ValidateManual, NoDefaultCred, SendAuxRecord, UseStrongCrypto), m_ProtocolFlags=(Zero), m_EncryptionPolicy=RequireEncryption)
System.Net Information: 0 : [19512] AcquireCredentialsHandle(package = Microsoft Unified Security Protocol Provider, intent  = Outbound, scc     = System.Net.SecureCredential)
System.Net Information: 0 : [19512] InitializeSecurityContext(credential = 
System.Net.SafeFreeCredential_SECURITY, context = 1ed7465db80:1f1d854c910, targetName = foo.bar.com, inFlags = ReplayDetect, SequenceDetect, Confidentiality, AllocateMemory, InitManualCredValidation)
System.Net Information: 0 : [19512] InitializeSecurityContext(In-Buffers count=2, Out-Buffer length=133, returned code=ContinueNeeded).

我还打开了SCHANNEL事件日志记录.在那里,我可以看到它使用私钥获取了客户端证书.

I also have SCHANNEL event logging turned on. There I can see it picking up the client cert with the private key.

The TLS client credential's private key has the following properties:

   CSP name: Microsoft Enhanced Cryptographic Provider v1.0
   CSP type: 1
   Key name: {some hex here}
   Key Type: key exchange
   Key Flags: 0x0

 The attached data contains the certificate.

接着是与Wireshark中的Alert数据包相对应的错误:

Followed by the error that corresponds to the Alert packet in Wireshark:

A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 40.

我完全没有主意.感觉就像.Net中的错误.我们有一会儿认为这与我们的客户证书是不完整的信任链,因为我们的证书包仅包含客户证书和中间CA.但是我们从供应商那里获得了根CA,现在Windows表示该证书是合法的.

I am completely out of ideas. It feels like a bug in .Net. We thought for a moment that it was an incomplete trust chain with our client certificate, because our cert package only had the client cert and an intermediate CA. But we got the Root CA from the vendor and now Windows says the cert is legit.

我在Wireshark中注意到的一件有趣的事情是,我们在成功调用后发送客户端证书和中间CA.我不知道它如何选择中间CA,因为我只提取客户端证书以附加到请求.为什么一旦拥有根CA也就不提交根CA?我的直觉告诉我问题可能仍然在这里的某个地方,但我无法证明.任何地方的任何日志中都没有任何记录表明信任链失败.

One interesting thing I notice in Wireshark is that we send the client cert AND the intermediate CA on successful calls. I don't know how it's picking up the intermediate CA because I only pull in the client cert to attach to the request. Why wouldn't it also submit the root CA once we had it? My gut tells me the problem may still lie in here somewhere but I can't prove it. There is nothing in any logs anywhere that indicate a trust chain failure.

我什至还挂接了ProcMon,看我是否能看到任何不对劲但没有跳出来的东西.伙计,我用我花的时间就可以用Java重写整个事情.

I've even hooked up ProcMon as well to see if I could see anything amiss but nothing jumped out. Man I could have rewritten the whole thing in Java in the amount of time I've spent on this.

我尝试过的其他一些方法不起作用:

Some other things I have tried that didn't work:

定位.Net 4.8

targeting .Net 4.8

机器商店与用户商店

直接从pfx加载

HttpWebRequest而不是HttpClient

HttpWebRequest instead of HttpClient

带有SslStream的TcpClient

TcpClient with SslStream

较新的Windows 10版本

newer Windows 10 release

编辑我刚刚读到一些内容,说SHA-1签名也与MD5一起从TLS 1.2中删除了.我们的客户证书已在SHA-1中签名.我想可能就是这样,我们正在与供应商联系.

EDIT I just read something that says SHA-1 signatures were also removed from TLS 1.2 along with MD5. Our client cert is signed in SHA-1. I think this might be it and we are contacting our vendor.

推荐答案

我的问题和解决方案最终与该问题相同.唯一的区别是我的客户证书是SHA1而不是MD5..NET显然也将放弃SHA1证书.

My problem and my solution ultimately ended up being the same as this one. The only difference is that my client cert was SHA1 not MD5. .NET is clearly dropping SHA1 certificates as well.

本文为我提供了线索,因为其他帖子表明SHA1仍然被接受.我的SHA1证书在.NET之外仍然有效.

This article gave me the clue, because other posts indicated that SHA1 was still accepted. My SHA1 certs still worked outside of .NET.

https://tools.ietf.org/id/draft-ietf-tls-md5-sha1-deprecate-00.html

这篇关于.NET通过TLS 1.2删除客户端证书的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆