[ https://issues.apache.org/jira/browse/WSS-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15513675#comment-15513675 ]
Colm O hEigeartaigh commented on WSS-588: ----------------------------------------- Yes, see here: http://ws.apache.org/wss4j/config.html The "signatureKeyIdentifier" changes the key identifier. There's a table at the end that gives other values apart from "IssuerSerial". Yep, in this scenario it makes sense to use "DirectReference" instead. > Server-side signature validation on client fail with only certificate CA is > in the client truststore > ---------------------------------------------------------------------------------------------------- > > Key: WSS-588 > URL: https://issues.apache.org/jira/browse/WSS-588 > Project: WSS4J > Issue Type: Bug > Components: WSS4J Core > Affects Versions: 2.0.4 > Environment: Servicemix server using cxf+wss4j for WS-Security purpose > Reporter: Libois Claude > Assignee: Colm O hEigeartaigh > Labels: easyfix > > I have a webservices which is secured by WS-Security+Policy. > I currently use Signature only for server response. > However I keep having the same error on client side: > {code} > Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: The > signature or decryption was invalid > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:160) > at com.sun.proxy.$Proxy34.submit(Unknown Source) > at > client.OffresEmploiClientUserToken.doCall(OffresEmploiClientUserToken.java:93) > at > client.OffresEmploiClientUserToken.main(OffresEmploiClientUserToken.java:63) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) > Caused by: org.apache.wss4j.common.ext.WSSecurityException: The signature or > decryption was invalid > at > org.apache.wss4j.dom.processor.SignatureProcessor.handleToken(SignatureProcessor.java:194) > at > org.apache.wss4j.dom.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:428) > at > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessageInternal(WSS4JInInterceptor.java:278) > at > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:190) > at > org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.handleMessage(PolicyBasedWSS4JInInterceptor.java:129) > at > org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.handleMessage(PolicyBasedWSS4JInInterceptor.java:112) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:802) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1645) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1533) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1336) > at > org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56) > at > org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215) > at > org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) > at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:652) > at > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:516) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:425) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138) > ... 8 more > {code} > My client truststore is set so that I only have the signer CA. > *I have noticed that if I set the signer certificate in the client > truststore, it works !* > I did a wireshark snoop and found that in the response part coming from the > server: > {code} > <ds:X509Data><ds:X509IssuerSerial><ds:X509IssuerName>1.2.840.113549.1.9.1=#16107465737473736c40666f72656d2e6265,CN=XXXXX</ds:X509IssuerName><ds:X509SerialNumber>12428414237952637822</ds:X509SerialNumber></ds:X509IssuerSerial></ds:X509Data> > {code} > The problem is that 12428414237952637822 isn't the CA(issuer) serial number > but the signer serial number ! > I have digged a little bit into the code I have found something that looks > weird to me in the WSSecSignature class : > {code} > case WSConstants.ISSUER_SERIAL: > String issuer = certs[0].getIssuerX500Principal().getName(); > java.math.BigInteger serialNumber = > certs[0].getSerialNumber(); > {code} > i'm wondering why in the last line we don't take the issuer serial number > ???? -> > {code} java.math.BigInteger serialNumber = > certs[0].getIssuerX500Principal().getSerialNumber();{code} > I can't see how this can work since the client compare the serial number > provided with the serial number of the CA in the Merlin class: > {code} > if (x509cert.getSerialNumber().compareTo(serialNumber) == 0) > {code} > Hope I was clear enough. > I have checked in the latest version of the WSSecSignature and I still see > the same line... > Best Regards, > Claude -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org