Secure Socket Layer, or SSL, certificates are frequently used to confirm the identity of a server before consuming its services and to secure communications with the server. Typically, when an Apache web server is used to load balance requests to one or more Apache Tomcat servers (including VMware’s commercial version, tc Server), the SSL encryption and certificate authentication is terminated at the web server. Communication between the Apache web server and Tomcat is then trusted and in clear text.
However, there are organizational security policies and B2B scenarios that could mandate secure communication between Apache web server and Tomcat. Furthermore, it could be important to restrict access to Tomcat to known instances of Apache web server.
This tutorial will provide details for a configuration option that enables SSL communication and client certificate authentication between Apache Web Server and Tomcat.
At a high level, this tutorial provides instructions to
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).
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.