Phase4 Error responses are not signed which leads to "Unable to verify document signature" error on failed sending attempt instead of the actual error message

[alfchristensen]

Hi!

After the successful test using the standalone to send a peppol document, I now need to implement the maven dependency in order to send documents using our actual application. I am using version 5.5.0 of both oxalis and as4.

When trying to return the test document to the testbed I get the following error:
"javax.xml.crypto.MarshalException: It is forbidden to use algorithm http://www.w3.org/2000/09/xmldsig#rsa-sha1 when secure validation is enabled" and "network.oxalis.api.lang.OxalisTransmissionException: Unable to verify document signature".

Any idea how I can solve this? Please see my pom.xml, oxalis.conf, java class, and log attached in the zip file.

Best Regards
Alf Christensen
files.zip

[dladlk]

Please check the java version you use - such error can occur in java 17, where secure validation is activated by default.
Oxalis 5.5.0 requires java 8.

[alfchristensen]

Not sure if this is any help, but here is what ChatGPT-4 responded to the stacktrace:

The error message you're seeing is related to SOAP security policies not being satisfied in your application. The parts of the policy that aren't being satisfied are related to:

The received token not matching the token inclusion requirement ({http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}X509Token).
The SOAP Body not being signed ({http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignedParts).
This could be due to a misconfiguration in your security settings, possibly in the way you're signing your SOAP messages, or due to using an incorrect or expired certificate. Here are a few things you could check:

Check your security token: Make sure that you're using the correct security token and it meets the requirements defined by the policy. If you're using an X509 token, check to ensure it's not expired and is included as required by the policy.

Sign your SOAP body: If your SOAP body isn't being signed as required by the policy, you'll need to include this in your message creation process. Check your SOAP message generation code and make sure that it includes a step to sign the body of the message using the correct certificate.

Check your SOAP version: Different SOAP versions may have different requirements for security. Ensure that your application is using the correct SOAP version according to your WS-Security policy.

Policy Misalignment: It is possible that your server and client may have different understandings of what the policy should be. If the client's understanding of the policy (in terms of which parts must be signed, what tokens are needed, etc.) doesn't match what the server expects, these kinds of errors can occur. Make sure to align these policies on both ends.

Check the WSDL file: If you're generating client-side code from a WSDL file, make sure that this file is up to date and matches the server's implementation.

[dladlk]

Is it possible that there is something new or something else going on with the new testbed documents that triggers an error the signing functionality in the org.apache.cxf.ws.policy.PolicyVerificationInInterceptor package?

As I understand from OxalisCommunity/Oxalis-AS4#205 , Phase4 implementation of AS4 Peppol profile does not sign any error responses. That is why Oxalis fails with this error when server rejects a document. And Phase4 is used in this new testbed.

I still hope that Phase4 is updated to sign the rejections as it does not sound logical for me...

So I would recommend you to look into logged original response for now to see what it reports as failure.

For example, in the last case, it could be that the document info is expired, or there is some issue with finding it... So try to get a newest document (and I guess a new document id), do the SBD change and send it back as fast as possible.

In general, new testbed is released just a week ago, so theoretically there could be issues with it.

[alfchristensen]

For example, in the last case, it could be that the document info is expired, or there is some issue with finding it... So try to get a newest document (and I guess a new document id), do the SBD change and send it back as fast as possible.

Just reset the testbed and received a new document. Changed only the sender and receiver as specified and tried to respond. Still the same error of soap message not being signed:

Jun 14, 2023 2:50:11 PM org.apache.cxf.ws.policy.PolicyVerificationInInterceptor handle SEVERE: Inbound policy verification failed: These policy alternatives can not be satisfied: {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}X509Token: The received token does not match the token inclusion requirement {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignedParts: Soap Body is not SIGNED

So I would recommend you to look into logged original response for now to see what it reports as failure.

Judging from the logs it does not seem like Oxalis tries to send at all? Could that be the case, or do you think it is just the response from the testbed that is causing this? Referring to what you said in your previous post. The testbed is running but shows nothing in the Audit log (attached picture).

One thing: I have the oxalis:latest-11 (docker image running 6.0.0-RC4) running in an Azure container. It passes the certificate test and receives the document. THEN I copy the file to my application utilizing the maven dependency running on my local computer, and try to send it back. Using the same p12 certificate as the docker container and the same jks file.

Do you think I should contact the people working with the testbed, or du you think this error relates to my implementation or files?

logfile from my application and xml attached.

new_trial_06_14.zip
new_trial_06_14.log

[dladlk]

Judging from the logs it does not seem like Oxalis tries to send at all?
In your logs you can see, that Oxalis made a request:

2023-06-14 14:54:54,594 INFO [org.apache.cxf.services.DummyImpl.REQ_OUT] REQ_OUT
    Address: https://phase4-controller.testbed.peppol.org/as4
    HttpMethod: POST
    Content-Type: multipart/related; type="application/soap+xml"; boundary="uuid:832275bb-ce69-4bd8-9205-892ac75a50f0"; start="<root.message@cxf.apache.org>"; start-info="application/soap+xml"
    ExchangeId: 398a5b96-4859-4d19-85bc-4e624074fe0c
    ServiceName: outbound-service
    PortName: port
    PortTypeName: DummyImpl
    Headers: {Accept=*/*, User-Agent=Oxalis 6.0.0-RC3 / AS4 6.0.0-RC3 / PNO000567}
    Payload: 
...

And in 400 ms it received response:

2023-06-14 14:54:54,931 INFO [org.apache.cxf.services.DummyImpl.RESP_IN] RESP_IN
    Address: https://phase4-controller.testbed.peppol.org/as4
    Content-Type: application/soap+xml;charset=UTF-8
    ResponseCode: 200
    ExchangeId: 398a5b96-4859-4d19-85bc-4e624074fe0c
    ServiceName: outbound-service
    PortName: port
...

You can see the response after Payload: text. If you copy the contents and format it as XML, you can see the error message inside Error\Description tag:

<?xml version="1.0" encoding="UTF-8"?>
<S12:Envelope xmlns:S12="http://www.w3.org/2003/05/soap-envelope">
	<S12:Header>
		<eb:Messaging...>
			<eb:SignalMessage>
				<eb:MessageInfo>
					<eb:Timestamp>2023-06-14T12:54:53.311Z</eb:Timestamp>
					<eb:MessageId>da8983b6-9259-4d10-a2f3-2fca7bcd6c08@phase4.openpeppol.playground</eb:MessageId>
					<eb:RefToMessageId>e06e59c4-060e-4907-b623-1d050d164d59@host.docker.internal</eb:RefToMessageId>
				</eb:MessageInfo>
				<eb:Error category="Content" errorCode="EBMS:0004" refToMessageInError="e06e59c4-060e-4907-b623-1d050d164d59@host.docker.internal" severity="failure" shortDescription="Other">
					<eb:Description xml:lang="en">Invoked AS4 message processor SPI com.helger.phase4.peppol.servlet.Phase4PeppolServletMessageProcessorSPI@2244b9b5 on 'e06e59c4-060e-4907-b623-1d050d164d59@host.docker.internal' returned a failure: TBErrorResponse{errorCode='-4115', errorDescription='Unable to correlate request with Document's Identifier [PNO000567-4-20230614T094641]', trace='d068d330-be90-4726-9f27-339b6e060f75'}</eb:Description>
					<eb:ErrorDetail>An undefined error occurred.</eb:ErrorDetail>
				</eb:Error>
			</eb:SignalMessage>
		</eb:Messaging>
	</S12:Header>
	<S12:Body/>
</S12:Envelope>

which is again similar as before.

Error message:

Invoked AS4 message processor SPI com.helger.phase4.peppol.servlet.Phase4PeppolServletMessageProcessorSPI@2244b9b5 on 'e06e59c4-060e-4907-b623-1d050d164d59@host.docker.internal' returned a failure: TBErrorResponse{errorCode='-4115', errorDescription='Unable to correlate request with Document's Identifier [PNO000567-4-20230614T094641]', trace='d068d330-be90-4726-9f27-339b6e060f75'}

But Oxalis expects even errors to be signed - that is why you get another exception further.
Anyway, I guess it worth contacting Peppol testbed support and send them the whole above error message including trace ID, maybe there is some issue now...

[alfchristensen]

Hello again @dladlk

Just got a response on my Jira ticket from Phillip Helger. He stated that this issue is caused by the requirement for signed error responses in Oxalis, and pointed me this thread: OxalisCommunity/Oxalis-AS4#205

After having read the discussion, I see there are some disagreement on policy and thus implementation. Do you have any suggestions for what I can do to get around this in the meantime? If I you will consider changing the Oxalis implementation, that would be very good for me to know also.

Best Regards
Alf Christensen