Hi Olve, IMO the behaviour you describe is not a bug.
> 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. -----Original Message----- From: Olve Hansen [mailto:[EMAIL PROTECTED] Sent: 29 November 2008 15:51 To: [email protected] Subject: Signature validation not querying in truststore/cacerts for certificate alias I am currently investigating a "bug" and I have patched the AbstractCrypto class as described in my previous post (http://mail-archives.apache.org/mod_mbox/ws-wss4j-dev/200811.mbox/%3C20 [EMAIL PROTECTED]). I can see during debugging that the patch works, as I find the alias of my added key, and thus it must come from my own (non-default) keystore. This led me one step further in the process, but I am now stopped again... 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), as the following threaddump shows: at org.apache.ws.security.components.crypto.CryptoBase.getAliasForX509Cert( CryptoBase.java:214) at org.apache.ws.security.components.crypto.CryptoBase.getAliasForX509Cert( CryptoBase.java:194) at org.apache.ws.security.message.token.SecurityTokenReference.getX509Issue rSerialAlias(SecurityTokenReference.java:520) at org.apache.ws.security.message.token.SecurityTokenReference.getX509Issue rSerial(SecurityTokenReference.java:498) at org.apache.ws.security.processor.SignatureProcessor.verifyXMLSignature(S ignatureProcessor.java:280) at org.apache.ws.security.processor.SignatureProcessor.handleToken(Signatur eProcessor.java:85) at org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurity Engine.java:311) at org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurity Engine.java:228) at org.springframework.ws.soap.security.wss4j.Wss4jSecurityInterceptor.vali dateMessage(Wss4jSecurityInterceptor.java:498) at org.springframework.ws.soap.security.AbstractWsSecurityInterceptor.handl eRequest(AbstractWsSecurityInterceptor.java:104) [snip] I am of the opinion that public certificates of trusted parties should go into the truststore, and not in the key-store, but WSS4J is unable to support this organisation of stores. I see that checking both stores is done already getAliasForDN(..) via getAlias(..). Are there any reasons why the X509 alias lookup methods doesn't query the truststore/cacerts? I propose checking first in keystore for the getAliasForX509Cert(..) methods as well. All of the getAliasForX509Cert(..)-methods checks for the alias only in the keystore, not in the truststore (aka cacerts). I guess this should be done symmetrically for all those methods,if it should be done at all that is. I have tried this approach for the org.apache.ws.security.components.crypto.CryptoBase#getAliasForX509Cert and it works fine... Anyone who has any thoughts about this? BTW, this is done in WSS4J version 1.5.4, using Spring-WS version 1.5.5. Regards, Olve Hansen -- View this message in context: http://www.nabble.com/Signature-validation-not-querying-in-truststore-ca certs-for-certificate-alias-tp20748366p20748366.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]
