We're using JBoss 4.0.5.GA, bundled with Tomcat 5.5.20.
Security vulnerabilities were found in Tomcat 5.5 and Tomcat 6.0 and
in Tomcat 5.5.26 and 6.0.16, and users are advised to upgrade.
The design of Tomcat folders/files in JBoss 4.0.5.GA doesn't match the
We switched from JSSE to the APR and OpenSSL about 6 months. We
converted all existing keys and certs to the format required by OpenSSL.
It was not hard. Some people say it can't be done, but they're wrong.
After 6 months with openSSL, I say it's easier to use than JSSE. We use
Don't assume your SSL session or connection hasn't been invalidated just
because you aren't asked to choose a certificate from your browser certs when
you log in again. In our system (Tomcat 5.5.33), I know that our HTTP session
and Single Sign-on session are invalidated upon logout, and we
I can see why it looks like the server is sending the message, but I think
there's some reference that's being missed. The SSL debug should show Client
messages and Server messages.
One thing that's certain, the SSLv2 ClientHello is a client message sent by the
Sounds like you installed it perfectly, otherwise no https connection to
your web server would be possible. The problem with trust is on the
client/browser side. You need to install the 3rd party Root CA cert on
your client so your browser will trust your server's certificate.
Subject: RE: Installing CA cert on SSL enabled webserver
The browser says the cert is issued by the server itself and it should
be issued by the 3rd party CA (in this case, GoDaddy), right?
From: Adamus, Steven J. [mailto:steven.j.ada...@saic.com]
Most if not all browsers let you view the certificate that was received
from the web server. You won't receive one unless you have an https
connection. If you can view it and verify it's the correct one, then
it's been installed correctly and the connection is encrypted.
You're probably referring to a DoD or similar security requirement. In
the Web Server STIG, Rule ID SV-2236r8 says, Installation of compilers
on production web server is prohibited. The explanation provided is,
The presence of a compiler on a production server facilitates the
Nothing is going on. When the smartcard is removed, nothing goes across
the wire, so how could Tomcat possibly invalidate the session?
I've been down the same road and never found any acceptable logging
solution within the APR. Every APR/OpenSSL issue we've had over the last
3 years has been resolved using WireShark. Wireshark is indispensable.
Mail list logo