Hi Raueber,
Wow! That's pretty low level SSL you got there! I have struggled for two
weeks with SSL and X509 stuff myself, mainly with certificates and have
learned 1) I don't really know squat about the SSL protocol, or 2) X509
certificate encodings (OIDs, etc). But I have learned 1) to appreciate the
complexity and amount of work that will be required to make things work
according to specifications, 2) even the big boy browsers don't have it ALL
correct, 3) reuse as much validated code as possible, and 4 ) from my
limited use of 5.5.12, Tomcat does seem to handle the SSL protocol
reasonable well (via the JSSE fold-in I think) but is still missing the
high level access to certificate data, or at least I have not figured out
how to get anything from the getUserPrincipal(), and 5) Mutual
Authentication
requires EVERYTHING to be PREFECT - its unforgiving.
I do believe I have Mutual Authentication working with the Tomcat, including
an SSL level Challenge/Response dialog with the user. Tomcat handles all of
the SSL, checks its tomcat-users.xml ACL for a match with the certificate's
CommonName, then checks the access permissions (roles) within the realm, and
honors the web.xml requests to restrict access to specific Servlet methods.
That having been said, I have no clue as to how to retrieve the specific
user related information from the HttpRequest object. I guess I should not
have been surprised at this, after all its not an HttpsRequest object. I
still need to figure out how to make this magic happen.
I'll pull together a care package of the stuff from the OpenSSL and post it
back to list. Works pretty good, but you have got to already know what you
are doing because the documentation has no meaningful tutorial or overview
for that very complex subject - I'll include some comments but remember my
limit experience.
Once you get you certificates and keystores correct, everything should fall
into place after that. In the mean time, plan on having Tomcat wired to its
server keystore as usual, but wired to its own trust.keystore - it beats
screwing up the JRE's cacerts while you experiment to get things right.
Good Luck,
- Daniel
----- Original Message -----
From: "Raueber Hotzenplotz" <[EMAIL PROTECTED]>
To: <tomcat-user@jakarta.apache.org>
Sent: Sunday, October 23, 2005 8:55 AM
Subject: KeyStore question
Hi all
I still want to use Tomcat with SSL (still not working). I've got a
servlet
that acts as a CA.
1. Question(s):
Should I have separate keystores (JKS) for the web application and the
Tomcat
server? Where do you usually place the Tomcat keystore? At the moment I'm
including the web application keystore in the war file and have the Tomcat
keystore stored somewhere else.
2. Question(s):
If I want to use SSL I don't need to change an existing servlet - Tomcat
handles secure requests. Is that correct? My problem is, web browsers
accept my
selfsigned certificates (https://localhost:8443) (after I tell them to do
so),
but as soon as I make a secure xmlrpc call to my servlet, I get
SSLHandshakeExeptions. Secure xmlrpc calls between two clients
(SecureWebServer/SecureXmlRpcClient) work. I've got my own 'open'
trustmanager
and hostnameverifier (see attached code). The only thing I changed was the
server.xml file (now includes keystore/password for Tomcat server). Are
there
any other things? I also tried to add my selfsigned certificate to
$JAVA_HOME/jre/lib/security/cacerts, but that didn't help either.
3. Question(s):
I've already asked in other places, but I still can't make it work. I
would be
a very happy person, if someone could post a complete client + server code
using SSL preferably xmlrpc using javax.net.ssl instead of com.net.ssl
(that's
a bit off topic). Do I need to implement my own
trustmanager/hostnameverifier
on both sides client and server or just on the client side?
Thanks!!
Rudi
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with
voicemail http://uk.messenger.yahoo.com
--------------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
