Client Authentication via Tomcat
There have been various posts regarding Tomcat's inability to successfully complete client authentication, particularly with Microsoft's IE. We've discovered the answer to Tomcat's problem. It turns out that as part of the client-cert request in the standard SSL protocol, the server side sends a _stringified_ version of each trusted certificate. The string version is a standard representation of the distinguished name of the signer of a trusted certificate, such as and so on. Now, it appears that IE does a simple string comparison of its trusted certs against this list to figure out what certificates are trusted. IE doesn't look at the certificates themselves (which are also included in the SSL handshake) during this initial screen - it looks simply at the stringified version of the signer. This means that if there's any difference between the way that the server stringifies the signer and the way IE stringifies the signer, IE's match fails, and IE will never recognize the trusted certificate. With this background, the problem turns out to be the following: (1) The Microsoft certificate authority allows an email address in the root certificate's distinguished name. This isn't exactly standard (my reading of the DN standard is that only an X501 item can appear in the DN and there isn't a clear item for email address) but it is very common. (2) When Microsoft stringifies a certificate's signer, it uses "E=" as the marker for the email address. (3) When Tomcat stringifies a certificate's signer, it uses "EmailAddress=" as the marker for the email address. (4) Since IE and Tomcat don't agree on the stringified version of the email address, IE's string match fails to recognize a root certificate that includes an email address. The fix: we re-installed the Microsoft cert authority and specified a distinguished name for the authority that did not include an email address. After re-installing the certs in both Tomcat and IE, the two were able to exchange a client cert without a problem. I speculate that Netscape looks for trusted roots in the SSL handshake differently, which is why we were able to get client authentication working with Netscape, even with the email address in the root.
RE: TC4.0 catalina classloader exception
I had a similar problem, except that I also had a sealed-data exception. In
my case, it turned out that the (sealed) jar file crimson.jar is in both the
lib and server directories. I fixed my problem by unsealing the .jar file --
that is, by un-jaring the file and then re-jaring it.
-Original Message-
From: David Wall [mailto:[EMAIL PROTECTED]]
Sent: Saturday, March 17, 2001 1:28 PM
To: [EMAIL PROTECTED]
Subject: TC4.0 catalina classloader exception
I am getting the following exception running Tomcat 4.0b1:
RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested
exception is:
java.lang.ClassNotFoundException: access denied to class loader
java.rmi.ServerException: RemoteException occurred in server thread; nested
exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested
exception is:
java.lang.ClassNotFoundException: access denied to class loader
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception
is:
java.lang.ClassNotFoundException: access denied to class loader
java.lang.ClassNotFoundException: java.security.AccessControlException:
access denied (java.io.FilePermission
/usr/local/apache1.3.19/WebPub/pub/WEB-INF/classes/- read)
<>
I'm not sure what is going wrong. I am starting catalina with the
"-security" option which I need since I'm using RMI. I even made the
catalina.policy file contain only:
grant {
permission java.security.AllPermission;
};
So there really should be no security exception. Anybody know why this
exception is being thrown?
Thanks,
David
re: Client authentication with Tomcat + SSL
Version: Tomcat 4.0b1 OS: Win2000 SP1 This is a follow-up to a message posted by Jeff Lansing on 13-Feb-2001. His problem, like mine, is the following. If Tomcat is configured to require client authentication ono an SSL socket, Microsoft's IE (5.5 SP1 running with 128-bit encryption) presents the browser-side user with an empty which-certificate-to-send dialog box. That is, IE is declining to send any client certs to Tomcat. This is not (at least in my case) a Tomcat configuration problem, since a normal (no client auth) SSL connection to the same Tomcat works just fine. I have some info to add to Jeff's message: o I turned on the JSSE debugging via set CATALINA_OPTS=-Djavax.net.debug=all With debugging turned on, I can verify that Tomcat is in fact sending a list of CAs from the cacert repository that includes the signer of the cert loaded in the browser. In fact, the same CA signed both the Tomcat cert and the user cert. The CA is an internal Templar Corp CA running Microsoft's certificate authority stuff on a Win2000 server. Visual inspection seems to imply that the problem isn't in Tomcat (but read on...). If anybody really, really wants to double-check me, I'll be happy to send the session.txt file by return mail -- it's almost 200k long, though. o The browser does create a proper dialog box if the server is Microsoft's IIS configured to ask for client authentication. The IIS certificate was generated by the same CA as Tomcat's and is structurally the same (same extensions etc). o Netscape 6.0 will deliver a client cert if asked by Tomcat. The Netscape cert in question is identical to the one loaded into IE -- to get a cert into Netscape, I had to export the public/private keys from IE and load 'em into Netscape. I ran Tomcat with JSSE debugging turned on and verified that the user certificate was in fact being delivered to Tomcat. I'm at a loss to figure out what's going on. It's starting to smell like a config problem in IE, but I can't figure out what it could be -- and anyway, a config problem in IE doesn't explain why IE happily delivers the client cert to IIS. Anybody have any clues?? R.W. Shore Templar Corporation Alexandria VA
