Julius:
Again thanks for your reply. I did use
EasySSLProtocolSocketFactory. This is why the client
was able to make thru the first SSL handshake because
it is able to trust any CA. (As a side note, I think
there is sufficient samples/docs for using
EasySSLProtocolSocketFactory.)
I also tried the TrustSSLProtocolSocketFactory with
both the server certificate and the signer of the
server certificate as the trust chain. Here it also
passed thru the first SSL handshake but did not seem
to present the client certificate during the second
handshake.
thanks,
JT
Here is my test client code:
mport org.apache.commons.httpclient.HttpClient;
import
org.apache.commons.httpclient.methods.GetMethod;
import
org.apache.commons.httpclient.protocol.Protocol;
import org.apache.commons.ssl.HttpSecureProtocol;
import org.apache.commons.ssl.TrustMaterial;
import org.apache.commons.ssl.KeyMaterial;
import org.apache.commons.httpclient.contrib.ssl.*;
import javax.net.ssl.SSLHandshakeException;
import java.net.URL;
public class SslClientExample {
/* argument 0: host
1: port number */
public static void main( String[] args )
throws Exception
{
HttpSecureProtocol f =
new EasySSLProtocolSocketFactory();
//HttpSecureProtocol f = new HttpSecureProtocol();
// here's where we start trusting server's CA:
//f.addTrustMaterial(new TrustMaterial(
// "my_cacerts.jks",
// "changeit".toCharArray()));
f.setKeyMaterial (new KeyMaterial("mycert.p12",
"changeit".toCharArray()));
Protocol trustHttps = new Protocol("https",
f,
Integer.parseInt(args[1]));
Protocol.registerProtocol("https", trustHttps);
HttpClient client = new HttpClient();
GetMethod httpget = new GetMethod(args[0]);
client.executeMethod(httpget);
String s = httpget.getStatusLine().toString();
System.out.println( "HTTPClient: " + s );
System.out.println(
httpget.getResponseBodyAsString());
}
}
--- Julius Davies <[EMAIL PROTECTED]> wrote:
> James,
>
> Hope you don't mind me switching this conversation
> to "httpclient-user"
> instead of "httpclient-dev".
>
> I think the results below show that commons-ssl is
> able to present the
> client certificate. I should probably fix things up
> a little to make
> doubly sure of that (the commons-ssl "ping" utility
> is only showing the
> server certs in its output), but for now let's focus
> on your code
> instead.
>
> #1. Are you using EasySSLProtocolSocketFactory like
> this? There is no
> documentation actually telling you to do this, so I
> don't blame you if
> you missed this:
>
> EasySSLProtocolSocketFactory easy = new
> EasySSLProtocolSocketFactory();
>
> // These next two lines are where commons-ssl fits
> in:
> KeyMaterial km = new KeyMaterial(
> "/path/to/cert.jks" );
> easy.setKeyMaterial( km );
>
> // Back to usual "EasySSLProtocolSocketFactory" as
> detailed in
> // httpclient-contrib javadocs:
> Protocol easyhttps = new Protocol("https", easy,
> 443);
> Protocol.registerProtocol("https", easyhttps);
> HttpClient client = new HttpClient();
> GetMethod httpget = new
> GetMethod("https://localhost/";);
> client.executeMethod(httpget);
>
>
> #2. I would actually recommend against using
> EasySSLProtocolSocketFactory in production
> environments. Instead I
> would use the Ping utility to download the server
> cert you want to trust
> (cut & paste the base64 PEM output into a separate
> file), and then use
> AuthSSLProtocolSocketFactory instead.
>
> But if you do that, you will have to also deal with
> server cert expiry,
> which can be annoying. Mind you, if you're using
> client certs, you
> already have to deal with client cert expiry!
>
>
> yours,
>
> Julius
>
> http://juliusdavies.ca/commons-ssl/
>
>
>
> On Fri, 2006-06-10 at 03:56 -0700, James Vu wrote:
> > 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...
> > >
> > >
> ==================================================
>
=== message truncated ===
__________________________________________________
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]
