"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]

Reply via email to