Hello Guillaume, I have unfortunately more issues on security.
Is seems to be impossible to activate "needClientAuth" on a consumer endpoint so that the provider endpoint has to send his certificate as well. I get a javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate Is there something known with that? Is there a testcase in servicemix where all this stuff is tested? Who did the complete ssl stuff in servicemix? If I ever solve my security stuff I provide you with documentation about that. ;-) Cheers, Thomas Thomas TERMIN wrote: > I'm not an ssl expert either! ;-) > > No wouldn't say that the sun implementation doesn't support multiple > keys but the behaviour is strange and with one key in the keystore it > works always fine. I don't know why. What you get during the deployment > is an UnrecoverableKeyException. But I didn't mean that the consumer > endpoint can accept only a single certificate because you can have > multiple certificates in a truststore. So your endpoint can trust > multiple clients with different certificates. It is the same for the > provider endpoint IMHO. > > Cheers, > Thomas > > > > Guillaume Nodet wrote: >> What happens when you do that with multiple keys ? >> Are you saying that sun implementation does not support multiple keys ? >> This means that on a consumer endpoint, you can only accept >> a single certificate, right ? What about the provider endpoint ? >> Sorry for my ignorance, but I'm not an ssl expert and I may have >> missed something ... >> >> On 11/8/06, Thomas TERMIN <[EMAIL PROTECTED]> wrote: >>> Hello Guillaume, >>> >>> I tried your solution and it still does not work! Unfortunately! >>> >>> I did the following in conf/security.xml >>> >>> <sm:keystoreManager id="keystoreManager"> >>> <sm:keystores> >>> <sm:keystore name="default" >>> path="classpath:keystore.jks" >>> keystorePassword="servicemix" >>> keyPasswords="smx=smx" /> >>> <sm:keystore name="midas" >>> path="classpath:keystore.jks" >>> keystorePassword="servicemix" >>> keyPasswords="server-alias=password" /> >>> <sm:keystore name="midas-trust" >>> path="classpath:truststore.jks" >>> keystorePassword="trustpass"/> >>> </sm:keystores> >>> </sm:keystoreManager> >>> >>> >>> xbean.xml for the http consumer endpoint >>> >>> <http:endpoint service="bes:remote-request-start" >>> endpoint="endpoint" >>> role="consumer" >>> locationURI="https://cuba:8192/BESlocalRequest/"; >>> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"; >>> soap="false" > >>> <http:ssl> >>> <http:sslParameters managed="true" >>> keyAlias="server-alias" >>> keyPassword="password" >>> >>> keyStore="midas" >>> keyStorePassword="servicemix" >>> trustStore="midas-trust" >>> >>> trustStorePassword="trustpass"/> >>> </http:ssl> >>> </http:endpoint> >>> >>> What happens is that you have a KeyManager (registerd on jndi with >>> multiple FileKeystoreInstance instances). The key alias and the password >>> are stored in a List. >>> >>> The problem what I see is that in the FileKeystoreInstance class the >>> keystore file is again loaded in the loadKeystoreData method and after >>> that you give this keystore (with again multiple keys) to the init >>> method of the KeyManagerFactory: >>> >>> keyFactory.init(keystore, (char[]) keyPasswords.get(keyAlias)); >>> >>> So the key alias is again not used except to get the password. I thought >>> you create for each key an inmemory keystore and give the right key >>> store to the init method. In tis way the init method would get just one >>> key with the correct password. There wouldn't be any issues with >>> multiple keys then because the sun implementation would never see >>> multiple keys. >>> >>> Sorry but I can't really explain this stuff! ;-) But I hope it is >>> understandable though. Maybe I just didn't get something correctly! >>> >>> >>> >>> Cheers, >>> Thomas >>> >>> >>> >>> Thomas TERMIN wrote: >>>> Thanks Guillaume! >>>> >>>> I will try that out tomorrow. Basicly that solve our problem in >>>> servicemix but we have also jetty as a webcontainer deployed in >>>> servicemix so we have still the problem here. >>>> >>>> Guillaume Nodet wrote: >>>>> If you set the managed="true" attribute on the ssl parameters >>>>> for the servicemix-http component, you will use the >>>>> org.apache.servicemix.http.jetty.ServiceMixSslSocketConnector >>>>> instead of the standard jetty ssl connector. This one handle >>>>> the keyAlias parameter. >>>>> >>>>> To use this, you will need to define a >>>>> org.apache.servicemix.jbi.security.keystore.KeystoreManager >>>>> instance (see /conf/security.xml for an example) like the following: >>>>> >>>>> <sm:keystoreManager id="keystoreManager"> >>>>> <sm:keystores> >>>>> <sm:keystore name="default" >>>>> path="classpath:keystore.jks" >>>>> keystorePassword="servicemix" >>>>> keyPasswords="smx=smx" /> >>>>> </sm:keystores> >>>>> </sm:keystoreManager> >>>>> >>>>> You will need to configure it on the component configuration, using >>>>> either a JNDI name or a direct reference. Unfortunately, there is >>>>> currently no way to set it for the endpoint itself, though it >>> should be >>>>> easy to modify. >>>> If I have some time I will look at it but I can't make it at the >>> moment. >>>> Cheers, >>>> Thomas >>>> >>>> >>>>> On 11/6/06, Thomas TERMIN <[EMAIL PROTECTED]> wrote: >>>>>> Guillaume, >>>>>> >>>>>> We have some issues with ssl here. As I said before you can set the >>>>>> key-alias parameter but it is not used at the moment from >>> servicemix to >>>>>> create a sslSocketConnector. But the bigger problem is that jetty >>> does >>>>>> not support that. Jetty reads the keystore from the keystore file >>> and if >>>>>> there is more than one key in this store it gives an exception. The >>>>>> thing is I can fix that in jetty as well as in servicemix. But I >>> have no >>>>>> contacts to the jetty community. So one thing is if I would fix that >>>>>> could you bring this patch faster in the jetty code as I could >>> (Assumed >>>>>> that you have better contacts). The second thing is if you are >>>>>> interested at all on improve this things. >>>>>> >>>>>> So what I would do is I would read the keystore file in jetty as >>> already >>>>>> done and would create inmemory keystores for every alias. So I would >>>>>> have a hash table or something where you could get the keystore for a >>>>>> specific given alias. The only thing in servicemix then is to get the >>>>>> key-alias (if it is set in the http endpoint configuration) and >>> call a >>>>>> jetty getter method for the key alias. The Ssl socket connector >>> can then >>>>>> get the specific keystore from the hast table and intialise the >>> complete >>>>>> ssl stuff with the right given key. >>>>>> >>>>>> Hope it was understandable. ;-) >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Cheers, >>>>>> Thomas >>>>>> >>>>>> Thomas TERMIN wrote: >>>>>>> Thanks Guillaume it is a nice feature in servicemix but it seems >>> to be >>>>>>> not supported from the SslSocketConnector (jetty). There is no such >>>>>>> attribute unfortunately. >>>>>>> >>>>>>> Do you have any ideas? >>>>>>> >>>>>>> Cheers, >>>>>>> Thomas >>>>>>> >>>>>>> Guillaume Nodet wrote: >>>>>>>> The SslParameters class has a keyAlias attribute that you >>>>>>>> can use for that. >>>>>>>> >>>>>>>> On 11/3/06, Thomas TERMIN <[EMAIL PROTECTED]> wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Who can I specify the alias for a key in the keystore for >>> secure ssl >>>>>>>>> consumer endpoints? Or is that basicly impossible to have more >>>>>> than one >>>>>>>>> key in the keystore? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Thomas Termin >>>>>>>>> >>>> >>> >> > >
