Hi Mary Thanks for that. However my understanding of TLS mutual authentication is that the client does send a certificate. I had a look at the TLS spec (http://www.ietf.org/rfc/rfc2246.txt) and quoted it below. I think it agrees with me - "Following the hello messages, the server will send its certificate, if it is to be authenticated. Additionally, a server key exchange message may be sent, if it is required (e.g. if their server has no certificate, or if its certificate is for signing only). If the server is authenticated, it may request a certificate from the client, if that is appropriate to the cipher suite selected. Now the server will send the server hello done message, indicating that the hello-message phase of the handshake is complete. The server will then wait for a client response. If the server has sent a certificate request message, the client must send the certificate message. The client key exchange message is now sent, and the content of that message will depend on the public key algorithm selected between the client hello and the server hello. If the client has sent a certificate with signing ability, a digitally-signed certificate verify message is sent to explicitly verify the certificate."
Kind Regards, Eamonn -----Original Message----- From: Mary Thompson [mailto:[email protected]] Sent: 26 May 2009 22:35 To: [email protected] Subject: Re: AW: AW: Send X509Certificate with request Hi Eamonn, In TLS mutual authentication the client does not send a certificate. If the server has been configured for clientAuthentication, the server sends a challenge message to the client requesting that it reply with a signed version of the challenge. The client looks to see what user it is running as. This is probably in some configuration file completely separate from any of the WS-security stuff which is all about signing the soap messages. I haven't tried to use cxf https yet, but you should be looking for a username that indexes to a keyEntry in some keystore or else just a pkcs12 file (or a keystore with just one keyentry) for the client. I just found this link which seems relevant http://osdir.com/ml/java.jetty.support/2003-01/msg00243.html. Apparently in the Java implementations the server sends a list of acceptable certs or cert issuers, which the client tries to match. There is a setKeyStore method in org.mortbay.jetty.security.SslSocketConnector you could use to select a keystore with just one keyentry, which might do what you want. Hope this helps a bit. There tends to be a lot of confusion about users, keys and certificates especially if you are using both TLS and WS-Security. Mary Michael Szalay wrote: > Hi > > yes, thats that I was looking for. Its just the tls authentication... > > Is there a programmatic way to set that property you mentioned to a client to > send a specific certificate? > > Regards Michael > > > -----Ursprüngliche Nachricht----- > Von: Eamonn Dwyer [mailto:[email protected]] > Gesendet: Dienstag, 26. Mai 2009 11:42 > An: [email protected] > Betreff: RE: AW: Send X509Certificate with request > > > Hi Michael > I'm just getting back to your original question, - does the authentication > have to be done "above" the transport or could you just let the TLS mutual > authentication mechanism do the work for you? > For example just setting the following on endpoint's tlsServerParameter > configuration would force the client to present a certificate to the service > for authentication > <cxfsec:clientAuthentication want="true" required="true"/> > > Regards, > Eamonn > > -----Original Message----- > From: Mayank Mishra [mailto:[email protected]] > Sent: 25 May 2009 12:51 > To: [email protected] > Subject: Re: AW: Send X509Certificate with request > > Hi Michael, > > I remember one way to send the public key certificate with your request from > client to server. There is a "DirectReference" KeyIdentifier for Signature > operation (make "signatureKeyIdentifier" property to "DirectReference"). > > If we use this your certificate is included as a BinarySecurityToken (BST) > in the message and a direct reference to this BST is used. But at the > receiving side (say on server) you have to manually tweak the code of WSS4J > to extract out the certificate yourself. > > With Regards, > Mayank > > On Wed, May 20, 2009 at 8:58 PM, Daniel Kulp <[email protected]> wrote: > >> On Wed May 20 2009 9:32:34 am Tom wrote: >>> AFAIK you do not add a certificate to the request, the request only is >>> signed. Certificates are added to the keystores on each side, so the >>> signature can be created / verified. >> Not ALWAYS true. If the WS-SecurityPolicy specifies an KeyValueToken as a >> token type, then the Security engine would output an RSAKeyValue key in the >> security header which WOULD be the full key. That key can then be used >> to >> sign the message, encrypt, etc.... Not really "secure", but useful for an >> endorsing mechanism. >> >> On the receiving side, you WOULD need to write a callback handler to >> validate >> the key. By default, WSS4J will reject the key as it won't know whether >> to >> trust it or not. >> >> Dan >> >>> Tom >>> >>> Michael Szalay wrote: >>>> Thanks for the link. But the document describes the signing of the >>>> request, not adding a certificate to the http request for mutual >>>> authentication, right? >>>> >>>> Regards >>>> >>>> Michael >>>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: Glen Mazza [mailto:[email protected]] >>>> Gesendet: Mittwoch, 20. Mai 2009 15:19 >>>> An: [email protected] >>>> Betreff: Re: Send X509Certificate with request >>>> >>>> >>>> >>>> http://www.jroller.com/gmazza/entry/implementing_ws_security_with_the? >>>> >>>> HTH, >>>> Glen >>>> >>>> mszalay wrote: >>>>> Hi all >>>>> >>>>> I have a question using Apache CXF as a client for a web service. >>>>> I would like to send a certificate within the request for mutual >>>>> authentication. >>>>> >>>>> How can I programmatically add a certificate to the request? >>>>> I looked for a method like TLSClientParameters.addCertificate but >>>>> I have not found somehing like that. >>>>> >>>>> Regards >>>>> >>>>> Michael >> -- >> Daniel Kulp >> [email protected] >> http://www.dankulp.com/blog >>
