With a bit of help, I figured out the 'null cert chain' problem. The problem is with a known bug in tomcat 4.x (and the 5.x too.) See tomcat bug #1400 and #19610 in the bug database at http://jakarta.apache.org/tomcat/bugreport.html It basically says that tomcat can't handle a server keystore with more then one entry. (It's also claimed that the alias for that entry must be 'tomcat' though i used a different alias just fine with tomcat 4.x).
To fix this, put only the server certificate in the keystore (the one that the connector points to) and then in the jdk directory under jre/lib/security/cacerts you can add any CA certificates that the server needs to know about. The tomcat people said they WONT FIX the problem since it affects such a small number of people. ha! The whole authentication system could be polished off a bit (support crl's, ocsp protocol, etc) without much work to make ssl the norm rather then a frustrating add-on. anyhow, I'll stop my ranting. Hope this helps.
Thanks for the suggestions (and glad you got it working). They were very helpful.
I already had 2 separate keystore files (one with just the server cert and one with all the client certs). And I didn't want to muck with the cacerts file. So I got it to work under Tomcat by doing this before starting JBoss:
set JAVA_OPTS=%JAVA_OPTS% -Djavax.net.ssl.trustStore=<my_truststore_path>
Under Jetty, this standard way of redefining the truststore didn't seem to have any effect. So with Jetty, the only way I could get it to work was to do 2 things:
In the SunJsseListener config added the line
And modified the keystore file (also specified in SunJsseListener config) to include both the server cert and the client certs!
If anybody has a suggestion for how to configure Jetty to allow 2 separate keystore files AND/OR to allow both Tomcat and Jetty SSL configs to be based on the same artifacts, I'd love to hear about it.