If we look at the Client Hello details in the trace we see that the client sends TLS 1.0 request to the server: We know that the TLS and cipher suites are negotiated in the SSL handshake so those are the first things to check. Then the client sends the "Client Hello" in the fourth frame (frame # 818) but instead of a "Server Hello" reply it receives a RESET package from the server as seen in the sixth frame (frame # 822) – you can see the R flag, which stands for TCP RST (reset) is indicated on the frame. Trace above shows that the TCP handshake is successfull (the first three frames). (Please note that the TMG is just the name of the server, and not the "Threat Management Gateway", sorry for the confusion) You can see a screenshot of the network trace I captured while I reproduce the same problem: It is up to you to choose the tool to capture and analyze a network trace. I personally choose Network Monitor but some of you may prefer Wireshark over Network Monitor. In our case it is OK to capture and take a look at the trace from client machine as we are currently trying to understand if TCP and SSL handshake is done sucessfully. That is because you can check if the same traffic / package sent from the client arrives at the remote server without a problem. Note that it is always suggested to capture the network trace from both client and the server (even from the intermediate devices or servers, such as proxies, when possible), because capturing network traces from different nodes (e.g.: client and the server) could help analyzing the issue more detail. Now it is a good time to capture a network trace from the machine where our client, ASP.net application, is hosted to check TCP and SSL handshake. Cipher suite negotiation also happens here.For example, if the client supports both TLS 1.0 and TLS 1.2, and the server supports only TLS 1.0, the SSL handshake may start with TLS 1.2 by client, and then it may actually happen in TLS 1.0 when server replies with "I support TLS 1.0 and let's continue with that" message. If the server responds with a lower TLS version and if the client supports that TLS version, SSL handshake continues with that TLS version.If the client sends a TLS version lower than the server supports the negotiation fails.Then the server responds with a SERVER HELLO package which includes the SSL / TLS versions and the cipher suits that it supports.
Client sends a CLIENT HELLO package to the server and it includes the SSL / TLS versions and the cipher suites it supports.Here is what happens after a TCP handshake as a summary:
I suggest you to read it if your unfamiliar with it. SSL handshake is greatly explained here, so I will not dive into all of the details. Note that the TCP and SSL handshake happens whenever an HTTPS request made. Since we don't have a good information in our browser test, we move to the second step of our troubleshooting which is to check if the TCP and SSL handshake is done without a problem. NET configuration, TLS negotiation in the SSL handshake may behave differently. When it is an ASP.NET application that runs as a client, depending on the. This difference may cause different behaviors.Īlso, when testing with browser, we rely on the browser TLS negotiation settings and its choices during the SSL handshake. When ASP.NET application is used it will use the computer account's store. Remember that our ASP.NET web application is making an HTTP web request to URL so our ASP.NET web application is acting as a client here.Īlthough a browser can be used to test the communication, this may not be the safest way to test each and every scenario because this test will use current user's certificate store.
Now we have faced another problem but the browser test did not show any problem so the certificate seems valid in our browser test, and, we are still seeing the very same error message telling us that the existing connection is forcibly closed by the remote host. We made some basic tests, such as a "browser test" and found that the certificate was not valid. In our first scenario, we troubleshooted a "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel" error message. This is the second part of our series of articles about troubleshooting TLS / SSL communications problems when you make Http Web Request or WCF queries from your ASP.NET applications to SSL endpoints.
0 kommentar(er)
