Hi, I have Tomcat 5.0.28 running on more than one client with a SSL connector that allows identification with spanish certificates FNMT, DNIe and Camerfirma (among others).
Today one client called me and tells me that when logging with DNIe from IE gets no response, whereas if you they try to access with other certificate or Firefox can access sucessfully. I have checked i it and I have found that other clients still log in with IE and DNIe. (other clients, other tomcat (same version), other servers)
They haven´t touch anything in the firewall that provides access to Tomcat and they have tried to restart Tomcat to see if it works and nothing.
When I look at the tomcat´s console the only thing I get is:
02-Aug-2010 11:50:21 org.apache.tomcat.util.net.TcpWorkerThread Runit
SEVERE: Remote Host / XXX.XXX.XXX.XXX SocketException: Connection reset
Where XXX.XXX.XXX.XXX is the IP of my computer and time y when I tried
Any idea where might be the problem?
Thanks a lot in advance
The first thing to note is that you are currently running an unsupported version of Tomcat, which in Apache terms means that it's extremely unlikely to get any more upgrades or patches. It's in beta now, but a stable release of Tomcat 7.0 is likely to happen towards the end of this year, which will put you a full 3 versions behind the current release.
A detailed answer to the question requires more information, such as the exact versions of the server operating system, the JVM type and version, how you've configured the SSL connector and whether you're using APR or not.
This type of problem most often appears when a client has unexpectedly terminated the request, or disconnected before the request has completed, implying that the source is at the client end of the connection - it's often an unintended consequence of a user deciding to view a different page before a previous request has finished.
In your case, you state that some clients are not having the same problem; in order to track down the source you should monitor the access, error and application logs and match individual requests to the log entries. Look for commonalities between source IP address, User-agent and try to get exact details of the environment of the client which has identified the problem. If there is definitely only one client experiencing the problem, then you'll need to determine what's different about their configuration. It's possible that there's nothing wrong with your application, but that a server or network misconfiguration is the cause of the fault.
Even recent releases of the Sun JDK/JRE don't have all of the Certificate Authorities in use currently, which is another possibility for the cause - though I wouldn't expect to see a connection reset event as a symptom - but still, check the client isn't using a certificate from a new CA.
I can't guarantee it would make any difference, but I'd strongly recommend putting a testing and deployment plan together to bring your environment up to reasonably current versions, particularly as there are vulnerabilities in SSL which are likely to unpatched in the setup you describe. Tomcat 5.5 should be the minimum version you're running on, if upgrading the JVM to a recent version is a problem.