Thanks. Actually I had intended to try 4.1.29 after your comment, and went last night to the jakarta pages to see if I could find it to download and try. I couldn't find it last night, but with the added impetus of your suggestion implying availability and a bit of educated guesses, I found it this morning.
Thanks again. Bill On 30 Oct 2003 at 0:11, Bill Barker wrote: > > ----- Original Message ----- > From: "Bill Harrelson" <[EMAIL PROTECTED]> > To: "Bill Barker" <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> Sent: Wednesday, October 29, 2003 > 11:34 PM Subject: Re: Help with access to certificate on HTTPS > > > > Ah! > > > > Thank you very much. My Request indeed has a multi-part MIME body. > > (case > # 1) I > > guess I'm out of luck until 4.1.29. I guess that I'll have to run > > two > instances of tomcat, one > > listening on 443 without client-auth, and one listening on another > > port > with client-auth. Any > > problems with this? > > > > I'd strongly suggest testing with 4.1.29. From the votes on the dev > list, it is currently strongly likely to get voted as 'GA', so you > would be only an 'early-adapter'. > > > Thanks for all your help. > > > > Bill > > > > (hmmm, I don't have a logging.properties file, never heard of it, > > - > where would it go and > > what would be in it? Or rather, can you point me to the setup > instructions? I'm also not > > using Log4j yet.) > > > > On 29 Oct 2003 at 22:52, Bill Barker wrote: > > > > > 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.X509Certificat > > > > > > > > > e"); and > > > > > > > > > req.getAttribute("javax.net.ssl.peer_certificates"); > > > > > > > > > > > > > > > > > > > > > > > > > This is specific to Tomcat 4.1 and higher, but: > > > > > > > > req.getAttribute("org.apache.coyote.request.X509Certif > > > > > > > > icat e"); > > > > > > > > > > > > > > > > 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.CertificatesValv > > > > > > > > > e" > > > > > > > > > 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] > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
