----- 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.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.X509Certificat > > > > > > > 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.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] > > > > >
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
