0

Our customer met a fail when they were authenticated via Client Certificate Authentication.

The use IISCrypto completed their Tls1.2 configuration. The SSL protocols and TLS1.1 are marked disabled.

And they use IISCrypto completed their Cipher Suite configuration.

I checked Cipher Suite\ .net Framework version \ OS version \ Renegotiation of TLS \ Server Certificate Setting \ API Gateway Settings \ Windows Services. But I cannot get any result.

Then I try to write some troubleshooting program to test the comunication and handshake sequence. I got nothing.

Curl.exe and openssl s_client were ok when send message with Client certificate, but it always failed in C#, my code is like:

X509Certificate2 cert = new X509Certificate2(@"C:\Communicate.pfx", "xxxxx");
HttpClient client = null;
System.Net.Http.WebRequestHandler _internalHandler = new System.Net.Http.WebRequestHandler();
_internalHandler.UseProxy = false;
_internalHandler.ClientCertificates.Add(cert);
_internalHandler.ServerCertificateValidationCallback = ((obj, x509, chain, policyError) =>
{
     return true;
});
client = new HttpClient(_internalHandler);
client.BaseAddress = new Uri(string.Format("https://{0}:{1}/", args[0], int.Parse(args[1])));

================================Update====================== I tried to write a TCP requester to test. It succeed. It seems the client certificate selection handler is different between HttpClient\WebRequest and SslStream.

X509Certificate2 cert = new X509Certificate2(@"C:\Communicate.pfx", "xxxxxxxx");
            X509Certificate2Collection col = new X509Certificate2Collection();
            col.Add(cert);
            TcpClient client = new TcpClient(args[0], int.Parse(args[1]));
            Stream stream = client.GetStream();
            SslStream ssl = new SslStream(stream, false, new RemoteCertificateValidationCallback((a, b, c, d) =>
            {
                return true;
            }), 
            new LocalCertificateSelectionCallback((sender, targetHost, localCertificates, remoteCertificate, acceptableIssuers)=>
            {
                return cert;
            }));
            ssl.AuthenticateAsClient("1.1.1.1", col, System.Security.Authentication.SslProtocols.Tls12, false);
            
            string x = "GET /api/TimebasedProxy/ HTTP/1.1\r\n";
            x += "Host:1.1.1.1\r\n";
            x += "Content-Type: application/json\r\n";
            x += "Connection: Close\r\n\r\n";
            byte[] xs = Encoding.UTF8.GetBytes(x);
            ssl.Write(xs, 0, xs.Length);

================Update=============

I got the reason: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\SendTrustedIssuerList is set to 1 at the server side. (https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#sendtrustedissuerlist)

But customer is running their server under Windows Server 2012R2, who set SendTrustedIssuerList to 1? ==========================Update============= IISCrypto did it. What ever you did with IISCrypto, IISCrypto always sets SendTrustedIssuerList to 1. It is a bug.

Zonas Sun
  • 41
  • 4

1 Answers1

0

I got the reason: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\SendTrustedIssuerList is set to 1 at the server side. (https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#sendtrustedissuerlist)

But customer is running their server under Windows Server 2012R2, who set SendTrustedIssuerList to 1?

IISCrypto did it. What ever you did with IISCrypto, IISCrypto always sets SendTrustedIssuerList to 1. It is a bug.

Zonas Sun
  • 41
  • 4