Dose anyone see and issue with the trace below other the 35 second FIN ACK, if there is a issue is the trace can you please enplane to me what i am missing please https://www.cloudshark.org/captures/e42f2386a047 your complaining of the browser takes to long to open the file on the server. asked 01 Feb '14, 21:23  Ernest Johnson |
2 Answers:
There is no issue in this trace besides the client NOT sending an HTTP request in the first session after TLS negotiation. answered 02 Feb '14, 00:25  mrEEde |
There are two connection attempts in the capture file. The first one (tcp.stream eq 0) shows a gap of ~35 seconds, before the client closes the connection. The second connection (tcp.stream eq 1) does not show that gap. I believe the following could have happened: There is a CRL dsitribution point in the cert of 195.35.91.51 (secure.worldpay.com): http://SVRSecure-G3-crl.verisign.com/SVRSecureG3.crl . Maybe your client tries to get that CRL (maybe even for the CAs) and is unable to fetch it for whatever reason. After some time it gives up as it realizes it cannot check the validity of that cert (behavior depends on the client TLS settings). During the second connection attempt it already knows it cannot get the CRL and thus it does not even try. As a result it continues with the HTTP request. Please check other communication attempts of the client while it is accessing 195.35.91.51. Maybe you'll see the (failing) attempt to fetch the CRL in some way (http, ldap or OCSP). Regards answered 03 Feb '14, 03:33  Kurt Knochner ♦ |
Thanks you so much for showing me that, now it is on the Server guys and the people who added the Cert to the box Thanks again Kurt
Tanks Kurt for the help, now it is not theme the network is good