AS2 B2B File Transfer — Xferity Secure Managed File Transfer

AS2

AS2 (Applicability Statement 2) is a message-based B2B exchange protocol that uses certificate-backed digital signatures, encryption, and receipt acknowledgements (MDNs). It is the standard protocol for EDI and regulated B2B data exchange.

This page describes how AS2 works in Xferity, its trust model, certificate role requirements, MDN handling, and configuration.

What AS2 is in Xferity

AS2 in Xferity is not a directory-polling transport. It is a message-oriented exchange model where:

each message is a signed and/or encrypted payload delivered via HTTPS
the receiving party returns an MDN (Message Disposition Notification) to confirm receipt
certificate roles determine who signs, who encrypts, and whose certificates are used for verification

This distinguishes AS2 clearly from SFTP and FTPS, which are directory-based file transfer transports.

When to use AS2

Use AS2 when:

a trading partner explicitly requires AS2
your exchange contract includes signed and encrypted messages
MDN-based receipt confirmation is required
you are operating in an EDI supply chain context (retail, healthcare, finance, logistics)

Do not use AS2 just because you need file exchange. For simpler cases, SFTP or FTPS is usually the right choice.

Trust model and certificate roles

AS2 trust is certificate-based and role-specific.

Different certificates are used for different functions in a single exchange:

Role	Function
Signing certificate (ours)	We sign outbound messages so the partner can verify them
Encryption certificate (partner’s)	Partner’s public cert used to encrypt messages only they can decrypt
Verification certificate (partner’s)	Partner’s public cert used to verify their signed MDN
HTTPS TLS trust	TLS trust for the HTTPS transport layer to the partner endpoint

These roles are managed through Xferity’s Certificate inventory and bound to partners through the Partner Crypto Policy. They are not configured directly in the partner YAML.

Partner definition example

id: retail-edi
display_name: Retail Trading Partner EDI
protocol: as2
as2:
  as2_id: "RETAIL-PARTNER-EDI"
  url: "https://edi.retailpartner.example/as2/receive"
  receipt_mode: sync
  signing_algorithm: sha256
  encryption_algorithm: aes256
  expect_signed_mdn: true
  https_tls:
    ca_cert: file:/etc/xferity/certs/retail-partner-ca.pem

Configuration fields

Field	Required	Default	Description
`as2_id`	yes	—	The partner’s AS2 identifier. Must match what the partner expects in the `AS2-To` header.
`url`	yes	—	HTTPS URL where AS2 messages are delivered.
`mdn_url`	no	—	URL for async MDN delivery. Leave empty for synchronous MDN.
`receipt_mode`	no	`sync`	`sync` (MDN returned in the same HTTP response) or `async` (MDN sent to `mdn_url` later).
`signing_algorithm`	no	`sha256`	Hash algorithm for message signing: `sha256`, `sha384`, `sha512`.
`encryption_algorithm`	no	`aes256`	Payload encryption algorithm: `aes128`, `aes192`, `aes256`, `3des`.
`compression_enabled`	no	`false`	Compress the message payload before encryption.
`expect_signed_mdn`	no	`false`	Require the MDN to be digitally signed by the partner.

HTTPS TLS configuration

Field	Description
`https_tls.ca_cert`	CA certificate PEM for HTTPS server validation
`https_tls.client_cert`	Client certificate for mutual TLS
`https_tls.client_private_key`	Client private key for mutual TLS
`https_tls.client_key_passphrase`	Passphrase for the client private key
`https_tls.insecure_skip_verify`	Skip HTTPS TLS verification. Rejected by hardened mode.

MDN modes

Synchronous MDN (default)

The partner returns the MDN receipt in the same HTTP response. This is simpler and sufficient for most B2B AS2 exchanges.

receipt_mode: sync

Asynchronous MDN

The partner sends the MDN to a callback URL asynchronously. Use this when the partner’s system requires it.

receipt_mode: async
mdn_url: "https://xferity.yourcompany.example/as2/mdn"

Async MDN requires your Xferity instance to be reachable by the partner for the MDN callback.

Certificate bindings

AS2 certificate roles are managed through the Certificate inventory — not in the partner YAML directly.

After adding certificates to the inventory, you bind them to the partner using the UI or API:

bind your signing certificate to the partner’s signing role
bind the partner’s encryption certificate (their public cert) to the partner’s encryption role
bind the partner’s verification certificate (their public cert) to the MDN verification role

The Partner Crypto Policy view shows the current state of all certificate bindings for a partner, including whether each role is satisfied.

Inbound AS2

Xferity also handles inbound AS2 messages when the Web UI and API are enabled. This is the receiving side of AS2 exchange.

Inbound AS2 message records are stored in Postgres-backed mode and accessible through the UI and API.

Hardened mode behavior

In hardened mode, AS2 partners enforce:

all https_tls credential fields must use secret references
https_tls.insecure_skip_verify=true is rejected

Common failures

Symptom	Likely cause
MDN shows disposition `failed`	Signing algorithm mismatch or cert not trusted by partner
No MDN received	Wrong `mdn_url`, async MDN not configured, or partner firewall blocking
Message decryption failed on partner side	Wrong encryption certificate bound or cert expired
HTTPS connection refused	Partner firewall or wrong URL
Cert not found	Certificate not bound to partner in the Certificate inventory

Operational checklist for AS2 partners

add the trading partner’s certificates to the Certificate inventory
bind certificates to the correct roles in the Partner Crypto Policy
confirm signing and encryption algorithm with the partner
determine whether the partner uses sync or async MDN
run xferity diag <flow> to validate connectivity and cert bindings
run a test message before enabling production schedules