Link to home
Start Free TrialLog in
Avatar of LEONEL ROCHA
LEONEL ROCHAFlag for Uruguay

asked on

Error 12175 calling WINHTTP_CALLBACK_STATUS_REQUEST_ERROR consuming a web service with soap protocol via HTTPCLIENT POST

I am consuming a web service with soap protocol performing a POST with httpclient. The server refuses the connection with this result:

An error occurred while sending the request. Error 12175 calling WINHTTP_CALLBACK_STATUS_REQUEST_ERROR, 'Security error'.|Status Code=500|Reason Line=Internal Server Error|Content=An error occurred while sending the request. Error 12175 calling WINHTTP_CALLBACK_STATUS_REQUEST_ERROR, 'Security Error'.


Can someone give me a clue as to the reason for that message?


Avatar of gr8gonzo
gr8gonzo
Flag of United States of America image

Since it's a security error, my first guess would be to check the remote site's security settings.


1. Make sure it has a valid SSL certificate that your machine trusts (or whichever machine is the one sending the request to the server).


2. Make sure the remote server isn't just running some really old security settings (e.g. old ciphers). If the server is public-facing, then you can always run an SSL test / audit on it here (safe and free and only takes about a minute and has no negative impact on your server):

SSL Server Test (Powered by Qualys SSL Labs) 


3. If it's not public facing, then you'd have to check internally. There are a few tools to do that, but your best bet would be to download and run Telerik Fiddler. It's a free debugging proxy and you can enable HTTPS interception so that you can see the SSL handshake that is happening and look at the details (e.g. what the certificate looks like, what protocol it's trying to use, etc). However, it only works on the machine that is running it, so if you're running this POST test from your own workstation, then Fiddler should work fine. If you're running the POST from some other server, like an ASP.NET page, then that won't work unless you can -also- attempt the POST from your machine.


The only thing that might indicate that it's NOT a certificate issue is that you're getting an HTTP 500 error, which would typically mean that it's getting past the initial handshake step. 


Usually if there was an authentication problem, you'd get a different HTTP error code, like 403, although a site -could- choose to send a 500, even if it's not the correct response code. However, Fiddler could be very illuminating here.

Avatar of LEONEL ROCHA

ASKER

thks gr8gonzo. I will proceed with your recommendations.

LR


Hi gr8gonzo.

1. The certificates are for testing and were not issued by a trusted entity. In the web.config file I added the following to not perform that control:

  <system.net>
    <settings>
      <servicePointManager checkCertificateName="false" checkCertificateRevocationList="false" />
    </settings>
  </system.net>


2. Security TLS1.3 and TLS1.2


3. Using Fiddler, and sending the envelope from the COMPOSER tab, the connection results OK and I receive the following response:

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
    <env:Header/>
    <env:Body>
        <env:Fault>
            <env:Code>
                <env:Value>env:Receiver</env:Value>
            </env:Code>
            <env:Reason>
                <env:Text xml:lang="en-US">The signature or decryption was invalid</env:Text>
            </env:Reason>
        </env:Fault>
    </env:Body>
</env:Envelope>


Using Fiddler I get a response from the service, but if I use httpclient I still get the same error. 


Any other suggestions?


LR

1    0.000000    192.168.0.10    200.40.1.73    TCP    66    57151 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1
2    0.005004    200.40.1.73    192.168.0.10    TCP    66    443 → 57151 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1380 SACK_PERM=1 WS=128
3    0.005187    192.168.0.10    200.40.1.73    TCP    54    57151 → 443 [ACK] Seq=1 Ack=1 Win=131072 Len=0
4    0.005726    192.168.0.10    200.40.1.73    TLSv1.2    242    Client Hello
5    0.012296    200.40.1.73    192.168.0.10    TCP    54    443 → 57151 [ACK] Seq=1 Ack=189 Win=64128 Len=0
6    0.013634    200.40.1.73    192.168.0.10    TLSv1.2    1434    Server Hello
7    0.013634    200.40.1.73    192.168.0.10    TCP    1434    443 → 57151 [ACK] Seq=1381 Ack=189 Win=64128 Len=1380 [TCP segment of a reassembled PDU]
8    0.013634    200.40.1.73    192.168.0.10    TLSv1.2    1167    Certificate, Server Key Exchange, Server Hello Done
9    0.013808    192.168.0.10    200.40.1.73    TCP    54    57151 → 443 [ACK] Seq=189 Ack=3874 Win=131072 Len=0
10    0.057230    192.168.0.10    200.40.1.73    TCP    54    57151 → 443 [FIN, ACK] Seq=189 Ack=3874 Win=131072 Len=0
11    0.061566    200.40.1.73    192.168.0.10    TCP    54    443 → 57151 [FIN, ACK] Seq=3874 Ack=190 Win=64128 Len=0
12    0.061628    192.168.0.10    200.40.1.73    TCP    54    57151 → 443 [ACK] Seq=190 Ack=3875 Win=131072 Len=0


View from frame 8 onwards. My app does not validate the certificate and closes the connection at this step:

Authentication: The client verifies the server's SSL certificate with the certificate authority that issued it. This confirms that the server is who it claims to be, and that the client is interacting with the real owner of the domain.


Why can this happen? Is there any way to fix it? Skip this check?



Are you using client certificate authentication, or does your SOAP message have any sort of digital signature (like a SAML assertion) ?


That message is indicating the remote server is getting trouble with either verifying a digital signature (which would require it to have some public key), or decrypting a value (which would likely require a private key).


Now, there's a small chance that the message you're seeing in Fiddler could be due to Fiddler itself. Fiddler acts as a man-in-the-middle proxy so it intercepts HTTPS messages, decrypts and then logs them and re-encrypts which means the keypair in the middle is different. Most servers are okay with this but some will reject it (they'll do something called certificate pinning).


But it's hard to know whether that's the issue here or not unless you can have the remote server enable logging so you can see if the request makes it through with Fiddler disabled.

Finally my problem was solved with this sentence: System.Net.ServicePointManager.ServerCertificateValidationCallback += (sender, cert, chain, sslPolicyErrors) =>true;

ASKER CERTIFIED SOLUTION
Avatar of gr8gonzo
gr8gonzo
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial

Yes, I understand, you are correct. But in the meantime I can test the consumption of the service since I have a tool that generates the C# code for me. I just placed a support ticket again with my provider to fix the issue. As soon as I have the answer I'll let you know. I suppose that in two or three days I will have the answer. As an alternative I am evaluating using the Chilkat function library.