Some things that occurred to me after the last post: 1) Tomcat versions before 4.1.29 (which seems to be rapidly on its way to GA status) don't handle this case well if the Request has a body (e.g. SOAP messages). 2) Assuming that 1) isn't the case, what will happen is that Tomcat will request that the client renegotiates the connection (legal under the RFC) to include clientAuth. If your client is broken wrt renegotiations, then you will have a problem.
"Bill Barker" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > "Bill Harrelson" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > Thanks, I'm not using browsers, this is for application-to-application > > security. I have a test application which has its own keystore, its > > certs and tomcat's certs are in its store. Its certs and tomcats certs > > are in tomcats store. They are in a chain from a trusted authority. > > This all works perfectly if client-auth=true on the 443 connector. So it > > does not appear to be a certs problem. It fails when I set client-auth > > to false and set client-cert to true on the application deployment > > descriptor. > > > > I would be happy to turn commons-logging to the values you suggest, > > but don't have a clue how to do that. (is this a -D parameter to > > tomcat?) > > If you are using log4j, then you just configure it as normal for log4j. > Otherwise (assuming that you are using a 1.4 JVM), then add > org.apache.tomcat.util.net.level=debug > to your logging.properties file. > > > > > Thanks for the assistance, if you can point me to some > > documentation on changing logging (and also if possible on how to > > write your own realms) I would be grateful. > > > > TIA, > > > > Bill > > > > > > On 28 Oct 2003 at 23:10, Bill Barker wrote: > > > > > > > > "Bill Harrelson" <[EMAIL PROTECTED]> wrote in message > > > news:[EMAIL PROTECTED] > > > > Thank you very much. It's nice to find people that know this stuff. > > > > > > > > Unfortunately > > > req.getAttribute("org.apache.coyote.request.X509Certificate"); > > > > > > > > also returns null when CLIENT-AUTH is set to false. Do I have some > > > configuration problem > > > > I don't know about? > > > > > > IFAIK, all of MSIE/Netscape7/Mozilla will automatically reject certs > > > that haven't got a signer in (the for want of a better word :) > > > TrustStore. Of course, you have to include your signer in Tomcat's > > > TrustStore (or the cert will be rejected). > > > > > > It would be helpful if you could turn up your commons-logging level to > > > 'debug', or even 'trace' for the 'org.apache.tomcat.net' Selector, and > > > report back. > > > > > > > > > > > I have seen several mentions on newsgroups that these attributes > > > > are > > > supposed to work, > > > > but nobody talks about whether client-auth is set to true or false. > > > > They > > > work just fine if > > > > client-auth is true. I'm hoping there's a solution if client-auth > > > > is > > > false, as tomcat (or coyote) > > > > certainly gets the certificate according to javax.net.debug=all, and > > > validates it as known to > > > > its keystore, it's hard to believe that it just throws it away. I'm > > > trying to set context for my > > > > application based on which company is connecting by looking up the > > > DN/PubKey in an > > > > internal database. The request gets through to the application, I > > > > just > > > can't get the cert. > > > > > > > > The idea of using CLIENT-CERT with my own realm is an interesting > > > > one. I > > > guess you're > > > > saying that CLIENT-CERT on the application works exactly like > > > CLIENT-AUTH=TRUE > > > > works for the Coyote connector which I had hoped but hadn't found to > > > > be > > > true, but that may > > > > be the realm problem). > > > > > > > > Okay, so I wrote my own realm and put it in the application context > > > > like > > > this (modeled on > > > > JDBCRealm): > > > > <Context path="/Application" docBase="Reflector" debug="0" > > > > crossContext="true" > > > > > <Realm className="com.myco.myappname.myRealm" debug="99" > > > > driverName="sun.jdbc.odbc.JdbcOdbcDriver" > > > > connectionURL="jdbc:odbc:CATALINA2"/> > > > > </Context> > > > > > > > > and in my app deployment-descriptor: > > > > > > > > <login-config> > > > > <auth-method>CLIENT-CERT</auth-method> > > > > <realm-name>myApp Certificates Realm</realm-name> > > > > </login-config> > > > > > > > > I get the Realm to start and see the startup messages, (after > > > > putting an > > > large! number of > > > > jars in the classpath) and I still get this error from the app: > > > > > > > > <snip> > > > > E> </head><body><h1>HTTP Status 400 - No client certificate chain in > > > > this > > > reques > > > > t</h1><HR size="1" noshade><p><b>type</b> Status > > > report</p><p><b>message</b> > > > > <u> > > > > No client certificate chain in this > > > > request</u></p><p><b>description</b> > > > <u>The > > > > request sent by the client was syntactically incorrect (No client > > > certificate ch > > > > ain in this request).</u></p><HR size="1" noshade><h3>Apache > > > Tomcat/4.1.24</h3>< > > > > /body></html> > > > > </snip> > > > > > > > > The certificate never gets into my Realm for authorization. But of > > > > course > > > it does if I set > > > > CLIENT-AUTH to true. > > > > > > > > What am I doing wrong? > > > > > > > > Thanks in advance, > > > > > > > > Bill > > > > > > > > > > > > > > > > On 26 Oct 2003 at 14:39, Bill Barker wrote: > > > > > > > > > > > > > > "Bill Harrelson" <[EMAIL PROTECTED]> wrote in message > > > > > news:[EMAIL PROTECTED] > > > > > > To whoever can help: > > > > > > > > > > > > I have an application which requires certificates, and a bunch > > > > > > of servlets which don't. In my application I need to determine > > > > > > the originating client of the certificate-based connection > > > > > > (which comes from an enterprise application). I can do this if > > > > > > I can get access to either the request Principal, or the > > > > > > certificate itself. > > > > > > > > > > > > I have tried to use > > > > > > req.getUserPrincipal(); > > > > > > req.getAttribute("javax.servlet.request.X509Certificate"); and > > > > > > req.getAttribute("javax.net.ssl.peer_certificates"); > > > > > > > > > > > > > > > > This is specific to Tomcat 4.1 and higher, but: > > > > > req.getAttribute("org.apache.coyote.request.X509Certificate"); > > > > > > > > > > should work. Of course, this ties your application to Tomcat and > > > > > there is no guarantee that future versions of Tomcat will continue > > > > > to support it (although currently 5.0 does). > > > > > > > > > > > all return null unless CLIENT-AUTH=true in server.xml is set, > > > > > > (in which case the x509cert attribute returns the cert chain > > > > > > the rest > > > > > > always return null) > > > > > > but this requires certificates for all access which is what I > > > > > > don't want. > > > > > > > > > > > > I also tried setting <Valve > > > > > > className="org.apache.catalina.valves.CertificatesValve" > > > > > > certificates="true" debug="1"/> > > > > > > in the context for the application but it didn't seem to help. > > > > > > > > > > > > > > > > CertificatesValve does nothing if you are using the Coyote > > > > > connectors. > > > > > > > > > > > I've also tried various combinations with CLIENT-CERT > > > > > > authorization in the deployment descriptor for the application. > > > > > > Some of the combinations simly block the interaction (saying no > > > > > > client-cert presented, when there is one.) > > > > > > > > > > > > > > > > This is the usual way. However, you have to use MemoryRealm, and > > > > > enter the DN of all of your certs into tomcat-users.xml. > > > > > Alternatively, you write your own Realm that decides which certs > > > > > you like. > > > > > > > > > > > I'm running 4.1.24 and 4.1.27 on XP Pro and Win2000. > > > > > > > > > > > > Can anyone help? > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Bill > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > > > --- 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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
