PHOSS AP 0.10.0 outbound AS4 always fails with TRANSPORT_ERROR_NO_RETRY and "A Peppol Reporting item can only be created AFTER sending"

[ajay2280]

PHOSS AP 0.10.0 always returns TRANSPORT_ERROR_NO_RETRY with Phase4PeppolException: A Peppol Reporting item can only be created AFTER sending
Environment
• PHOSS AP: 0.10.0
• phase4: 4.5.1
• peppol-commons: 12.5.3
• Java: Temurin OpenJDK 21.0.11
• Database: PostgreSQL
• Deployment: Docker
• Storage: Filesystem
• Peppol Stage: TEST
Management Status:

{
  "build.version":"0.10.0",
  "version.phase4":"4.5.1",
  "database.type":"postgresql",
  "peppol.stage":"test",
  "peppol.sending.enabled":true,
  "peppol.receiving.enabled":true,
  "storage.mode":"filesystem",
  "status":"UP"
}

---

Scenario
We are testing invoice exchange between two Peppol participants using PHOSS AP.
Participants:
Sender : 0235:POP000798
Receiver : 0235:POP000700
Both participants are registered in SMP.
The receiver endpoint resolves correctly from SMP:
https://uatas4.webtel.ae/as4
The receiver certificate is successfully retrieved from SMP.
Both sender and receiver are configured correctly, receiving is enabled, and the PHOSS AP instance is healthy.

---

What Works
We have verified the following:
• PHOSS AP starts successfully.
• Database schema is created correctly.
• PostgreSQL connection works.
• SMP lookup succeeds.
• Endpoint URL is resolved correctly.
• Receiver certificate is downloaded successfully.
• HTTPS endpoint is reachable.
• /management/status reports UP.
• peppol.receiving.enabled=true.
• Payload is successfully generated.
• Outbound transaction is inserted into PostgreSQL.
• Outbound payload file is created successfully.
Current document path stored in database:
/generated/outbound/2026/07/13/09/xxxxxxxx.out
The previous filesystem issue (/dataoutbound/...) has already been fixed.

---

Problem
Every outbound transmission fails with:

{
  "sendingResult":"TRANSPORT_ERROR_NO_RETRY",
  "sendingError":"Failed to transmit outbound AS4 message to 'https://uatas4.webtel.ae/as4'",
  "sendingException":{
      "class":"com.helger.phase4.peppol.Phase4PeppolException",
      "message":"A Peppol Reporting item can only be created AFTER sending"
  }
}

Stack trace:

com.helger.phase4.peppol.Phase4PeppolException:
A Peppol Reporting item can only be created AFTER sending

at Phase4PeppolSender.createPeppolReportingItemAfterSending()
at OutboundOrchestrator.processPendingOutbound()
...

---

Receiver Status
Receiver reports:

{
    "status":"UP",
    "peppol.receiving.enabled":true,
    "peppol.sending.enabled":true
}

The endpoint is accessible.
GET /as4
→ 405 Method Not Allowed
POST /as4 (without Content-Type)
→ 400 Bad Request
Therefore nginx and the PHOSS AP endpoint are reachable.

---

What We Have Already Verified
We have spent considerable time eliminating possible causes.
Verified:
• TLS connectivity
• HTTPS endpoint
• Nginx reverse proxy
• SMP lookup
• Receiver certificate retrieval

phase4.properties.txt
webapp.properties.txt
docker-compose.yml
phoss.log
application.properties.txt

docker-compose.yml
phoss.log

• Filesystem permissions
• Docker configuration
• PostgreSQL
• PHOSS startup
• Receiving enabled
• Sending enabled
• Java keystore loaded successfully
• PFX certificate loaded correctly
The outbound payload is created successfully, therefore storage is no longer the issue.

---

Log Output
PHOSS logs only show:
Outbound sending exception

com.helger.phase4.peppol.Phase4PeppolException:
A Peppol Reporting item can only be created AFTER sending
No SSL exception, HTTP exception, socket exception, or AS4 processing exception is logged before this.
It appears that the original transport exception is being replaced by the reporting exception.

---

Questions

1. Is this a known issue in PHOSS AP 0.10.0 / phase4 4.5.1?
2. Is there a way to log or expose the original transport exception instead of only:
   Phase4PeppolException:
   A Peppol Reporting item can only be created AFTER sending
3. Could this be a regression in PHOSS AP 0.10.0?
4. Is there any known issue when two different Peppol participants are hosted on the same PHOSS AP instance and both resolve (via SMP) to the same /as4 endpoint?
   We would appreciate any guidance on how to identify the underlying transport failure.
   Thank you.

[phax]

Thanks for your detailed report. The main problem is a broken truststore.

1. phase4 4.5.0 changed the default. The log states it explicitly at phoss.log startup:

Phase4PeppolHttpClientSettings: AP TLS connections use the JVM default truststore (no implicit trust-all) … Call HttpClientSettings.setSSLContextTrustAll() to restore pre-4.5.0 behaviour

2. Pre-4.5.0 phase4 trusted all TLS peers; from 4.5.0 it uses the JVM default truststore for outbound SMP + AS4.
3. You broke the JVM default truststore. docker-compose.yml sets -Djavax.net.ssl.trustStore=/data/certs/cacerts -Djavax.net.ssl.trustStorePassword=changeit, and that cacerts file is empty/invalid (hence "trustAnchors parameter must be non-empty"). So there is no CA chain to validate the SMP or receiver TLS certs against.
4. Your mitigation attempts are invented keys that do nothing. phase4.client.tls.trustall=true, phase4.reporting.enabled=false, phase4.peppol.reporting.enabled=false, etc. are not recognized phoss-ap/phase4 configuration properties - They have zero effect.

So the proposed fix you: stop overriding the truststore with an empty file. Either remove -Djavax.net.ssl.trustStore=…/cacerts -Djavax.net.ssl.trustStorePassword=changeit entirely (let the container JRE's own $JAVA_HOME/lib/security/cacerts be used — it contains the public roots that sign smp.webtel.in / uatas4.webtel.ae), or point it at a real copy of the JRE cacerts (password changeit) with any missing/private CA roots imported. If the UAT receiver uses a private/self-signed CA, import that CA into the truststore you are passing in.

The follow up problem with the Reporting error message is indeed a bug and will be handled separately.

[phax]

phoss-ap v0.10.4 will fix the problem with the unexpected reporting image. Additionally, the truststore is checked for emptiness on startup.

@ajay2280 please confirm that the above proposals fixes your issues

[ajay2280]

Dear team, Thank you for the quick response. I removed the custom JVM truststore completely: ``` -Djavax.net.ssl.trustStore=/data/certs/cacerts -Djavax.net.ssl.trustStorePassword=changeit ``` restarted the container (docker compose down && docker compose up -d) and confirmed that the application now uses the default JVM truststore. The previous trust Anchors parameter must be non-empty error is gone. However, outbound AS4 transmission still fails with: TRANSPORT_ERROR_NO_RETRY followed by: Phase4PeppolException: A Peppol Reporting item can only be created AFTER sending No SSLHandshakeException, PKIX, or other transport exception is logged anymore. Since the reporting exception is masking the real transport error, could you advise how to enable logging of the underlying exception? Is there a DEBUG/TRACE logger for the outbound AS4 HTTP client or phase4 transport layer that would expose the original failure? Best regards, Ajay sharma

[ajay2280]

Is the fix already available on the main branch, or should we wait for the official v0.10.4 release? If it is already merged, could you point us to the commit hash so that we can build and test it? From: Philip Helger ***@***.***> Sent: 14 July 2026 04:07 PM To: phax/phoss-ap ***@***.***> Cc: ajay ***@***.***>; Mention ***@***.***> Subject: Re: [phax/phoss-ap] PHOSS AP 0.10.0 outbound AS4 always fails with TRANSPORT_ERROR_NO_RETRY and "A Peppol Reporting item can only be created AFTER sending" (Issue #58) [https://avatars.githubusercontent.com/u/196219?s=20&v=4]phax left a comment (phax/phoss-ap#58)<#58 (comment)> phoss-ap v0.10.4 will fix the problem with the unexpected reporting image. Additionally, the truststore is checked for emptiness on startup. @ajay2280<https://github.com/ajay2280> please confirm that the above proposals fixes your issues — Reply to this email directly, view it on GitHub<#58?email_source=notifications&email_token=AKACSZVS5CLVNQABADKOQWL5EYEM5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJWHAZDGMBQG4YKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4968230070>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKACSZWF4NK7WO6C2FATCX35EYEM5AVCNFSNUABGKJSXA33TNF2G64TZHMYTCMZTGYYTIOJWGE5US43TOVSTWNBYHAYTAMBYGM4DLILWAI>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/AKACSZS23YWMV5FMPDXRBMD5EYEM5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJWHAZDGMBQG4YKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android<https://github.com/notifications/mobile/android/AKACSZSWFZBJRYCBNZRPJDL5EYEM5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJWHAZDGMBQG4YKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[phax]

You can just test with the main branch - I don't have immediate plans for a new release atm

[phax]

Hi @ajay2280,

Good news: the AS4 transmission is actually not the problem — with your symptoms (TRANSPORT_ERROR_NO_RETRY + the "AFTER sending" reporting error) the send to the receiver was never even attempted. The failure happens one step earlier, during validation of the receiver's AP certificate (from the SMP lookup), before phase4 opens the connection. That step throws a non-retriable error, and pre-0.10.4 the reporting bug masks it — which is exactly why you see no PKIX/SSL exception.

The real reason is already recorded in your current logs, no rebuild needed. Please search phoss.log for:

The configured receiver AP certificate is not valid (at ...) ... Reason: <X>

The Reason will be one of these — in order of likelihood for a UAT endpoint:

1. unsupported certificate issuer → Peppol stage mismatch. uatas4.webtel.ae is a test/pilot endpoint, so its AP certificate is a Peppol TEST cert. If your AP is configured for the production Peppol stage, it validates against the production Peppol CA and rejects it. Make sure your configured Peppol stage matches the network the receiver is registered in.
2. certificate revocation status could not be determined → OCSP/CRL responder unreachable. Revocation checking is hard-fail by default. If your container can't reach the OCSP/CRL endpoints (firewall/proxy), the cert is treated as invalid. Ensure outbound access to the OCSP/CRL URLs (via your HTTP proxy if you use one).
3. certificate is already expired / is revoked — the receiver cert is genuinely bad.

If for some reason that line isn't in your log, set logger com.helger.phase4 to DEBUG and retry — the underlying exception with full stacktrace is logged before the masking.

For reference, the v0.10.4 fix (already on main) removes the masking, so the real error will then be logged directly at ERROR level and stored in the sending report (C3 cert check result).

[phax]

@ajay2280 have you been able to resolve the issue?

[ajay2280]

No its not yet. There must be some issue in Phoss Ap because its working fine with oxalis Ng. From: Philip Helger ***@***.***> Sent: 20 July 2026 11:08 PM To: phax/phoss-ap ***@***.***> Cc: ajay ***@***.***>; Mention ***@***.***> Subject: Re: [phax/phoss-ap] PHOSS AP 0.10.0 outbound AS4 always fails with TRANSPORT_ERROR_NO_RETRY and "A Peppol Reporting item can only be created AFTER sending" (Issue #58) [Image removed by sender.]phax left a comment (phax/phoss-ap#58)<#58 (comment)> @ajay2280<https://github.com/ajay2280> have you been able to resolve the issue? — Reply to this email directly, view it on GitHub<#58?email_source=notifications&email_token=AKACSZXEGBWJDRS7WG5D4C35FZKHLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBSGUZDINRXGY42M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5025246769>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKACSZXHU6QP3WYIDLDJ4QT5FZKHLAVCNFSNUABGKJSXA33TNF2G64TZHMYTCMZTGYYTIOJWGE5US43TOVSTWNBYHAYTAMBYGM4DLILWAI>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/AKACSZQBNQCMJD3M5G4WSZL5FZKHLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBSGUZDINRXGY42M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android<https://github.com/notifications/mobile/android/AKACSZS4IKCTBAIRAQJYQ6L5FZKHLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBSGUZDINRXGY42M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[phax]

I just released 0.10.4 - can you please retry and check the error message. I know that phoss-ap is usually a bit more strict than Oxalis...