Working with specific products

Everything below was measured against the live product in as2d’s interop rig — not inferred from documentation. Version numbers are the ones tested; newer versions usually behave the same but verify when in doubt.

Java / BouncyCastle family (phase2 · as2-lib · OpenAS2 · mendelson)

The largest AS2 population. Shared traits, handled automatically:

• AES-GCM: they encode GCM non-conformantly (EnvelopedData with the auth tag appended, instead of RFC 5084 AuthEnvelopedData). as2d receives their form transparently. To send GCM to them, set interop.bc_style_gcm = true on the partnership — the default conformant encoding is unreadable to them.
• CAST5 / IDEA are unusable with this family in either direction (incompatible parameter encodings between BouncyCastle and OpenSSL). as2d warns at startup if a partnership configures them; use 3DES or AES-CBC instead. These two ciphers are excluded from product support.
• Signed messages digest receipts over the signed content; unsigned messages over the decompressed payload — as2d follows the same split, so MICs reconcile.

OpenAS2 (tested: 4.10.0)

• On unsigned + compressed messages OpenAS2 digests the receipt without MIME headers (following the RFC 4130 unsigned rule) while RFC 5402-followers (as2d, phase2) include them. The exchange works; the receipt MIC cannot reconcile. Avoid unsigned+compressed with OpenAS2 — signing fixes it (and is what you want anyway).
• OpenAS2 signs receipts without embedding its certificate — fine for as2d, which authenticates receipts against your pinned copy of their certificate.
• Everything else is clean both directions, including RSASSA-PSS, RC2, SHA-512, and compression before/after signing.

mendelson AS2 (tested: Community Edition 1.1b69)

• Enforces its configured partner security as an inbound floor, exactly like as2d — make sure both sides’ sign/encrypt settings mirror.
• Sends AES-GCM in the BouncyCastle form; as2d receives it fine.
• Accepts as2d’s signed receipts in all tested combinations.

pyas2lib / django-pyas2 (tested: pyas2lib 1.4.4)

• Interops cleanly both directions including compression and MIC reconciliation.
• Spells digest names without hyphens (sha256); as2d accepts these automatically.
• Normalizes line endings of text payloads to CRLF before signing — if byte-exactness of text documents matters downstream, be aware the delivered payload is CRLF-normalized. (Binary payloads are unaffected.)

Waarp AS2 (Go; tested at a 2025 development snapshot)

• Signed, encrypted (AES-CBC/3DES), and compressed exchanges are clean both directions with receipt reconciliation.
• Rejects both AES-GCM encodings at the tested snapshot — use AES-CBC with this partner.

Ruby as2 gem (tested: 0.12.0)

• Requires inbound messages to be signed and encrypted; supports synchronous signed receipts only; no compression, no async.
• Expects the raw (binary) S/MIME body — as2d’s default outer content-transfer-encoding, so it just works.
• Ignores the requested receipt digest and always uses SHA-256: request signed_micalg = "sha-256" so reconciliation is exact.

node-libas2 (tested: 0.8.2)

• Cannot parse a binary S/MIME body: set content_transfer_encoding = "base64" on the partnership.
• Its generated signed receipts have an upstream signature bug — configure it to send unsigned receipts (it verifies as2d’s signed receipts correctly).
• Ignores the requested receipt digest and digests with the actual signature algorithm (the RFC 4130 §7.4.3 rule): request a signed_micalg matching your signing digest.
• CBC/3DES only; no compression; no async delivery.

IBM Sterling B2B Integrator

• Some deployments require quoted header values: set interop.quote_header_values = true.
• If a specific Sterling deployment rejects otherwise-valid exchanges, contact support with the negative MDN text — Sterling installations vary widely in their strictness settings.

Peppol networks

• Peppol requires the signer certificate embedded in signatures — as2d’s default (include_cert_in_signature = true).