Julius: thanks for your reply. Here is what I got from running java -jar commons-ssl.jar -t <host>:<port> -c <cert.jks> -p <password>
java.lang.NoClassDefFoundError: org/bouncy/castle/jce/provider/JDKX509CertificateFactory Wrinting: ======================================================= HEAD / HTTP/1.1 Host: ... Reading: ======================================================= HTTP/1.0 200 OK Server: Netscape Certificate Server: https Date: .... Server Certificate Chain for: [<host>:<port>] ======================================================= cert3 Valid: <effective date> - <ending date> s: CN=cert3,OU=Servers,... i: CN=DEV-TEST Authority, OU=Servers, ... -----BEGIN CERTIFICATE----- .......... -----END CERTIFICATE----- DEV-TEST Authority Valid: <effective date> - <ending date> s: CN=DEV-TEST Authority,OU=Servers,... i: self-signed -----BEGIN CERTIFICATE----- .......... -----END CERTIFICATE----- What can you make of this? Thanks, JT PS: I have been tracing this for a while, and I notice that there are 2 handshake (as you would probably know this already). The first handshake is the establishment of the ssl which the client was able to trust the server's certificate or chain (this worked). The second handshake is actually when we hit the require authenticate path (GET /lockdownpath HTTP/1.1). It is here that java did not either read the certificate request or not able to present the client certificate at all thus server refuse the entry. I look at the server logs and it states that the client did not present any certificate. --- Julius Davies <[EMAIL PROTECTED]> wrote: > Hi, JT, > > #1. Not possible. The client cert will be > presented for all paths. This is because the socket > is established before "GET /path" or "POST /path" is > sent to the server. But I'm just being pedantic > here. > > [I think #1 can "appear" possible when servers use > "sslServer.setWantClientAuth( true )" instead of > "sslServer.setNeedClientAuth( true )." But the > client cert will still be presented for the very > first URL requested.] > > #5. Can you try the "ping" utility with > commons-ssl? After downloading "commons-ssl.jar", > please type: > > java -jar commons-ssl.jar > > Hopefully the instructions that print out from that > will be self-explanatory. Don't forget to include > the "-t" for "target". I always forget! And I > wrote it! > > If you get any bind exceptions, try specifying a > local port (such as 54321). There's one RHEL3 > machine at my office that always complains about > that for some reason, not sure why. > > Can you show us the output the "Ping" utility gets > back from your server? I'm especially interested in > the HTTP headers you get back, or the SSL > exceptions. > > > yours, > > Julius > > http://juliusdavies.ca/commons-ssl/ > > ps. please CC both httpclient-user and myself in > any replies. I don't seem to get httpclient emails > any more at work. I think we're having spam > filtering issues... probably going to start > subscribing from my gmail account instead... but > I'm lazy... > > ================================================== > All: > > 1. The server is authenticating only on a certain > path. > 2. I am using commons-ssl with httpclient > 3. I used the EasySSLProtocolSocketFactory > 4. I have set my KeyMaterial > 5. When I hit the required authenticated > path/location, it seems that the client is not > presenting the cert. > 6. I tested out using openssl and it works. I do > see > the client certificate request from the server and > the > client presents the correct cert. > > I am confused. > > Any help is much appreciated, > JT > > > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
