-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error sending with AS4: java.security.InvalidAlgorithmParameterException: Expected AttachmentTransformParameterSpec #69
Comments
Which versions of oxalis and oxalis-as4 do you use? |
We upgraded to oxalis 4.1.0. We first tried with oxalis-as4 4.1.0 as that was what we had used earlier this month when testing, but after that failed we tried upgrading to oxalis-as4 4.1.1 but with no luck. |
This seem a bit strange: org.apache.jcp.xml.dsig.internal.dom.ApacheOctetStreamData cannot be cast to org.apache.jcp.xml.dsig.internal.dom.ApacheOctetStreamData Which JDK are you using? |
java -version |
Could you try upgrading to: |
We have now just switched to openjdk version "1.8.0_242" no.difi.oxalis.as4.lang.OxalisAs4TransmissionException: Failed to send message Above this, we also get the following error messages: |
Can you show me the oxalis.xml of the inbound server and the oxalis.xml of the outbound sender? |
EDIT: Running Inbound and Outbound in separate containers fixed this issue in Wildfly as well. FWIW, we get the exact same Exceptions using Oxalis 4.1.0 and Oxalis AS4 4.1.1. It's flaky on our end though -- restarting the Outbound module always lets us transmit a single file before it starts failing again. If you're running other applications in the same Tomcat, you might want to look into whether they're using different versions of cxf or wss4j (and possibly santurio xmlsec?) There's a lot of "magic" in discovering the security protocols, so these things are liable to give surprising results when they're unable to discover implementations of various interfaces etc, or discover an unexpected version. We've not reported our problems, as we're running Oxalis in Wildfly 12, so we're fairly sure it's dependency hell biting us. (The Oxalis documentation is quite clear that we're on our own when we don't use Tomcat) |
There might be something to what @OysteinLq sais, beacuse of the following: The stacktrace show that an UnsupportedCallbackException is thrown in AttachmentCallbackHandler. In the calling class we see this: AttachmentRequestCallback attachmentRequestCallback = new AttachmentRequestCallback();
attachmentRequestCallback.setAttachmentId(attachmentId);
try {
attachmentCallbackHandler.handle(new Callback[]{attachmentRequestCallback});
} catch (Exception e) {
throw new TransformException(e);
} This tells us that the argument is indeed an instance of AttachmentRequestCallback, so the execption shouldn't have been thrown. It sounds very much like a classpath issue of some sort. |
Hi again. I have now testet for a classpath-issue in my sender component by doing the following: public class As4TestSender { This class is run from a sh-file that is defined as follows: It is run in a directory that only have these jar-files, the sh-file, and the class file, and nothing else. Running this file then gives these error messages: no.difi.oxalis.as4.lang.OxalisAs4TransmissionException: Failed to send message |
What about the the oxalis-standalone. Does that work as expected? |
Have now tried running it as standalone with the following: And I get this error: |
I use the following commandline when sending to my local test AP: java -DOXALIS_HOME=/c/dev/peppoltest/.oxalis \
-classpath "standalone/*;as4/*" eu.sendregning.oxalis.Main \
-cert ap.cer \
-f 9000432.xml \
--protocol peppol-transport-as4-v2_0 \
-u "http://localhost:8080/oxalis/as4" You do not need to specify sender and receiver, because those are automatically extracted from the SBDH in the file you are sending, I am not sure if you can use the -u parameter when communicating with a production endpoint. You should test against an AP using a TEST certficate. |
Hi, we are experiencing a similar issue in production where we are experiencing an exception caused by org.apache.wss4j.common.ext.WSSecurityException: javax.xml.crypto.dsig.TransformException: javax.security.auth.callback.UnsupportedCallbackException: Unsupported callback. On further inspection, this is happening during the processing of the SignedInfo where we have a reference such as:
We checked the libraries for the correct handlers, and all of the above algorithms should be supported. We also see a similar processing that leads to success (altough not in the SignedInfo).
We are on the latest commit on both Oxalis (1126a75) and Oxalis AS4 (b3f5cfd). Edit: It seems to process correctly after we restart, but then stops processing correctly after a while (~2 hours). |
Do you have an outbound servlet or similar on the same http server instance as the oxalis-inbound? |
When conformance testing we had problems running two instances of the same war on one tomcat server. The problems disappeared when we ran two tomcat servers instead. |
Yes we will try to set up two tomcat-instances as a workaround. After quite a lot of testing, we finally got a few of the EHFs through when using the standalone-approach. But once the Sender-Servlet was used once, all as4 -receivings from then on erred due to some conflict, possibly because the sender servlet has it's own copy of the as4-files. |
This is a bug in WSS4J: https://issues.apache.org/jira/projects/WSS/issues/WSS-660 |
I am closing the issue. Will reopen if I get new reports. |
Suggested workaround for Oxalis-AS4 NemHandel eDelivery, which should work also on Oxalis-AS4 with the same CXF version: https://github.com/dladlk/oxalis-nemhandel-tomcat-multiple-instances |
Nice summary :) |
Just realised I probably first posted my issue first in the wrong repository, difi/oxalis instead of difi/Oxalis-As4, sorry about that. As the deadline for as4 is today I post it here too.
We did the AS4 testing earlier this month, but due to issue #452 in difi/oxalis, we have avoided upgrading our production server until the end of month, as we wanted AS2 to still work against older servers.
However, when we upgraded yesterday, we started getting error messages when sending as4:
no.difi.oxalis.as4.lang.OxalisAs4TransmissionException: Failed to send message
at no.difi.oxalis.as4.outbound.As4MessageSender.send(As4MessageSender.java:91)
Caused by: javax.xml.ws.soap.SOAPFaultException: Cannot setup signature data structure
at org.apache.cxf.jaxws.DispatchImpl.mapException(DispatchImpl.java:285)
Caused by: org.apache.cxf.interceptor.Fault: Cannot setup signature data structure
at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:237)
Caused by: org.apache.wss4j.common.ext.WSSecurityException: Cannot setup signature data structure
Original Exception was org.apache.wss4j.common.ext.WSSecurityException: Expected AttachmentTransformParameterSpec
Original Exception was java.security.InvalidAlgorithmParameterException: Expected AttachmentTransformParameterSpec
at org.apache.wss4j.dom.message.WSSecSignatureBase.addReferencesToSign(WSSecSignatureBase.java:221)
Caused by: org.apache.wss4j.common.ext.WSSecurityException: Expected AttachmentTransformParameterSpec
Original Exception was java.security.InvalidAlgorithmParameterException: Expected AttachmentTransformParameterSpec
at org.apache.wss4j.dom.message.WSSecSignatureBase.addAttachmentReferences(WSSecSignatureBase.java:304)
Caused by: java.security.InvalidAlgorithmParameterException: Expected AttachmentTransformParameterSpec
at org.apache.wss4j.dom.transform.AttachmentContentSignatureTransform.init(AttachmentContentSignatureTransform.java:66)
I am really at a loss to what is the problem. Anyone who experiences the same, and have found a solultion to this?
Btw, it seems that the first time I send after a tomcat-reboot, I also get these errors:
Caused by: javax.xml.ws.soap.SOAPFaultException: A security error was encountered when verifying the message
at org.apache.cxf.jaxws.DispatchImpl.mapException(DispatchImpl.java:285)
Caused by: org.apache.cxf.binding.soap.SoapFault: A security error was encountered when verifying the message
at org.apache.cxf.binding.soap.interceptor.Soap12FaultInInterceptor.unmarshalFault(Soap12FaultInInterceptor.java:156)
org.apache.cxf.binding.soap.SoapFault: A security error was encountered when verifying the message
at org.apache.cxf.ws.security.wss4j.WSS4JUtils.createSoapFault(WSS4JUtils.java:236)
Caused by: org.apache.wss4j.common.ext.WSSecurityException: org.apache.jcp.xml.dsig.internal.dom.ApacheOctetStreamData cannot be cast to org.apache.jcp.xml.dsig.internal.dom.ApacheOctetStreamData
at org.apache.wss4j.dom.processor.SignatureProcessor.verifyXMLSignature(SignatureProcessor.java:399)
Caused by: java.lang.ClassCastException: org.apache.jcp.xml.dsig.internal.dom.ApacheOctetStreamData cannot be cast to org.apache.jcp.xml.dsig.internal.dom.ApacheOctetStreamData
at org.apache.wss4j.dom.transform.AttachmentContentSignatureTransform.transform(AttachmentContentSignatureTransform.java:104)
The text was updated successfully, but these errors were encountered: