> We want to set up a keystore holding only our service priv/pub key pair, > and a truststore for all client-keys.
The truststore should contain the CA-cert that signed the client certs, not the actual client certs. So essentially you're getting an error in the signature processor because it can't find the client cert in the keystore. One way around this, is to sign using direct reference rather than issuer-serial, and thus include the X.509 cert in the SOAP request. > So this actually means that verifyTrust is broken, since it requires that > the cert is in keystore for validation of the signature, but when it comes > to trustVerification it always checks the keystore first. No I don't think so. Are you looking at the latest version on trunk? I fixed a bug in this method since 1.5.4 was released. The logic is as follows: - Search the keystore/truststore for the transmitted certificate (direct trust) - Else look for the CA that issued the cert in either the keystore or truststore - Check the trust path of the issuer So this should work fine if the CA of the cert is in the truststore but not in the keystore. Having said that, some work definitely needs to be done on separation of concerns for the next release. Colm. -----Original Message----- From: Olve Hansen [mailto:[EMAIL PROTECTED] Sent: 02 December 2008 13:22 To: [email protected] Subject: RE: Signature validation not querying in truststore/cacerts for certificate alias Colm O hEigeartaigh wrote: > > Hi Olve, > > IMO the behaviour you describe is not a bug. > I agree, I have read the javadocs on the getAliasForX509Cert method more carefully, and I understand a bit more. But then I don't understand the best way to do what I want to do. Colm O hEigeartaigh wrote: > >> During the signature processing of a message I find that the signature >> validation doesn't even try to check in the truststore for the > certificate >> (getAliasForX509Cert only checks in the keystore) > > There is a separation of concerns in WSS4J between signature > verification and trust verification. The SignatureProcessor only cares > about validating the signature, it doesn't care about if the certificate > is trusted or not, and that's why it doesn't search the truststore. > > The trust verification takes place at a latter stage, line 516: > > https://fisheye.springframework.org/browse/spring-ws/trunk/security/src/ > main/java/org/springframework/ws/soap/security/wss4j/Wss4jSecurityInterc > eptor.java?r=1351 > > I agree though that some work is needed in this area in terms of clarity > and consistency...something to look at for the next release I guess. > > Colm. > Thaks for the pointer, I have now been digging a bit in the spring-ws and wss4j code and found the following. First, let me give some context about the case at hand.. We are developing a service that receives encrypted order from many clients, and we get encrypted and signed messages at the endpoint. The replies are also encrypted and signed. We want to set up a keystore holding only our service priv/pub key pair, and a truststore for all client-keys. Using the current version of WSS4J I then get the following error when separating this way, also after I have the patched version from my other recent mail, allowing me to specify what truststore to use. DEBUG org.springframework.ws.soap.security.wss4j.Wss4jSecurityInterceptor [] - Validating message [AxiomSoapMessage {http://www.w3.org/2001/04/xmlenc#}EncryptedData] with actions [Encrypt Signature] (Wss4jSecurityInterceptor.java:485) WARN org.springframework.ws.soap.security.wss4j.Wss4jSecurityInterceptor [] - Could not validate request: The signature or decryption was invalid; nested exception is org.apache.ws.security.WSSecurityException: The signature or decryption was invalid (AbstractWsSecurityInterceptor.java:256) DEBUG org.springframework.ws.server.MessageTracing.sent [] - Sent response [AxiomSoapMessage {http://schemas.xmlsoap.org/soap/envelope/}Fault] for request [AxiomSoapMessage {http://www.w3.org/2001/04/xmlenc#}EncryptedData] (MessageDispatcher.java:179) If I change getAliasForX509Cert to also look for certificates in the truststore, this works. I see from the javadoc on that method, that this might not be the ideal way to do it. What I want to accomplish is an easy way for the people maintaining this service after I have left (yes I am a consultant) so that we can use the keystore defined in WebSphere. Also I want the public keys of the client-services to be only one place. I can of course point to the cacerts/truststore for the validationSignatureCrypto property in spring-ws, using the truststore as keystore... As it is now, if we separate trust and keystore totally, a signature has to be in the keystore to be verified as a valid signature. Next the verifyCertificateTrust method in Wss4jSecurityInterceptor.java utltimately calls org.apache.ws.security.handler.WSHandler#verifyTrust, and that method checks first for the cert in the keystore, (getAliasForX509Cert:997) and then in both key and truststore, but first in keystore (getCertificates:1005). So this actually means that verifyTrust is broken, since it requires that the cert is in keystore for validation of the signature, but when it comes to trustVerification it always checks the keystore first. Hmm, this became a long email - does this makes sens? -- Olve ----- -- Olve Hansen -- View this message in context: http://www.nabble.com/Signature-validation-not-querying-in-truststore-ca certs-for-certificate-alias-tp20748366p20791998.html Sent from the WSS4J mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
