> > if you are indeed getting an HTTP Response Code of 403, then you have
> > already made the connection and successfully sent your HTTP Request.
> > That might mean that some other required authentication has failed.
>
> myConnection.getResponseCode(); does in fact return 403
right, but is that indeed what the server is sending?
IOW, I don't know if we can trust Java and maybe it gets a TCP error
and tells you that it's a 403 HTTP code.
Just as, IIRC, it treats a 4xx response code as it it were an I/O
exception.
> >If client cert auth fails, then the server drops the connection and you
> >wouldn't get to the point of receiving an HTTP response.
>
> If I understand what your saything then the certificate was in fact
> sent from my app and authentication failed elsewhere. But, I receive a
> 403 response if I dont' have the cert installed in my broswer.
Well then, that might be server specific behavior. Things aren't
standardized. IIRC, on failed client cert auth, Firefox--> Tomcat gives
a tcp error of something like 100257, while with IE--> Tomcat, you just
get the dropped connection.
(A wrinble is that Tomcat only accepts X509, not PKCS12.)
I can sympathize that most of what is happening is unseen by you. Maybe
you can trying experimenting locally. Stunnel gives good logging on
connection attempts and you can set up server sockets with it. You can
now also get pre-compiled OpenSSL for Windows. I can look that URL up
if you need it.
>Seems
> like I get that error only when the cert is missing. Is my thinking on
> setting the default keystore within the sevlet correct or is there a
> default store that jsse is using... like cacerts.
In the URL that I gave p[reviously, there's a reference to seemingly
IBM specific client-side properties:
* com.ibm.CSI.performTransportAssocSSLTLSRequired (true or false)
* com.ibm.CSI.performTransportAssocSSLTLSSupported (true or false)
Maybe that's the key. Since (if I'm reading you correctly) your servlet
is really the client, then the properties and keys you want to use are
part of the server's JVM, not the servlet engine.
> I've tried placing
> the key in cacerts and that doesn't help either..
yes, I'd think that the cacerts file is only for the Certificate
Authority certs
>Seems like this
> should be a very straight forward task Im just struggling horribly with
> finding the solution.
>
> Thanks again.
javerra - 15 Sep 2006 15:16 GMT
I set javax.net.debug to true just to double check that the server was
hitting the right stores
Now I am even more confused.
[9/15/06 10:11:46:468 EDT] 0000002a ServletWrappe A SRVE0242I:
[TestConnection]: Initialization successful.
[9/15/06 10:11:46:531 EDT] 0000002a SystemOut O keyStore is:
c:\wn.jks
[9/15/06 10:11:46:531 EDT] 0000002a SystemOut O keyStore type is
: JKS
[9/15/06 10:11:46:531 EDT] 0000002a SystemOut O init keystore
[9/15/06 10:11:46:609 EDT] 0000002a SystemOut O trustStore is:
C:\Program
Files\IBM\Rational\SDP\6.0\runtimes\base_v6\java\jre\lib\security\cacerts
[9/15/06 10:11:46:609 EDT] 0000002a SystemOut O trustStore type
is : jks
[9/15/06 10:11:46:609 EDT] 0000002a SystemOut O init truststore
[9/15/06 10:11:47:421 EDT] 0000002a SystemOut O
X509TrustManagerImpl: checkServerTrusted
[9/15/06 10:11:47:437 EDT] 0000002a SystemOut O
X509TrustManagerImpl: Certificate [
... what follows is the certificate chain received from the server.
then. my exception occurs.
The keystore and trust store are correct. I can't think of any reason
why this shouldn't be working.
bikemh - 15 Sep 2006 19:00 GMT
> I set javax.net.debug to true just to double check that the server was
> hitting the right stores
Right, seemingly it's telling you:
- the Java keystores are valid, in that there are no errors extracting
keys from either
- the client accepts the cert from the server, and the signing
authority on the cert is in cacerts
but there is no info there on what happens with client cert auth,
whether a cert is sent or not; or if sent, whether it is rejected
> Now I am even more confused.
>
[quoted text clipped - 21 lines]
> The keystore and trust store are correct. I can't think of any reason
> why this shouldn't be working.
javerra - 15 Sep 2006 19:18 GMT
Is there anything that I can do to pinpoint where this failure may be
occuring. Like you said obviously it is occuring after my acceptance
of the servers certificate chain. Is there some debug I can set? Is
there a way to see what certificates the server is requesting from the
client and if they're actually being sent? This is a bit frustrating
but Im learning a lot from the quality responses I've been getting.
Thanks!!!
> > I set javax.net.debug to true just to double check that the server was
> > hitting the right stores
[quoted text clipped - 34 lines]
> > The keystore and trust store are correct. I can't think of any reason
> > why this shouldn't be working.
javerra - 06 Oct 2006 01:14 GMT
Found the answer to the problem. Turns out that the certifacte the
client sent me did not include the whole certificate chain. There was
an intermediate certificate that was missing that was causing the
handshake to fail. I had the intermediate in internet explorer which
explains why it worked in the browser. To get the intermediate
certificate into my keystore I imported the client cert that was sent
to me then select the option within internet explorer to export the
entire certificate chain. I then used this new keystore in my code and
bingo.