Our journey toward AS2 EDI certification

We introduced AS2 support in September 2020 with SFTPPlus version 4.5.0. Since then, we have expanded the supported features and tested with other vendors as part of our development work. SFTPPlus 5.7 completed the Drummond Group AS2 interoperability testing event for the fourth quarter of 2024.

AS2 is used to exchange business files, including Electronic Data Interchange (EDI) documents such as orders and invoices. Implementing the same standard is a starting point, but successful exchanges also depend on matching partner settings and handling the details of certificates, HTTP, and receipts correctly.

If you are choosing a product, see our AS2 software, pricing, and supported trial. The lessons below can help you prepare a partner test or investigate an exchange that fails.

AS2 testing partners and profiles ​

Fifteen products achieved certification at the AS2-4Q24 event. Participants included Amazon Web Services, Axway, Boomi, CData Software, Cleo, DXC Technology, E2open, Fortra, IBM, and OpenText. The AS2-4Q24 final report lists SFTPPlus 5.7 and the results for the tested profiles. These results describe that product version and test event, rather than guaranteeing compatibility with every future release or partner configuration.

The legacy profile covers HTTP without TLS and 3DES encryption. The Advanced Transport tests cover TLS, SHA-2 signatures, and AES encryption. Legacy algorithms remain relevant when testing older systems, but the presence of an algorithm in a compatibility profile is not a recommendation to use it for a new deployment.

Outside the event, we also test with open source products such as Django AS2 (pyAS2) and Mendelson AS2. Our goal is to make SFTPPlus MFT work with the AS2 systems our customers' partners use.

Agree on algorithm names and identifiers ​

A partner configuration screen and a message header may use different names for related cryptographic operations. For example, sha1 and sha-1 refer to the SHA-1 digest, while RSA-SHA1 describes RSA signing with that digest. They are not interchangeable strings in every field. When troubleshooting, compare the actual header value and its required syntax with the partner's settings, rather than copying a label from a user interface.

AS2 identifiers need equally careful handling. An identifier containing spaces must be enclosed in double quotes in the HTTP header, for example AS2-To: "Example Partner". Single quotes are not a substitute. Agree on the exact identifier, including capitalization and spaces, before testing. See RFC 4130, section 6.2 for the identifier syntax.

Check the certificates before sending files ​

A certificate that imports into one product may be rejected by another product's stricter validation. Check validity dates, the intended signing or encryption use, and whether both partners have the correct public certificate. Also check the certificate's contents:

• Use a valid two-letter country code, such as US for the United States or GB for the United Kingdom, rather than USA or UK.
• Mark an extension as critical only when its specification permits that use. A recipient must reject a certificate if it cannot process a critical extension; clearing every critical flag is not a valid repair.
• Use serial numbers that are unique for certificates issued by the same issuer. Reusing a serial number can make certificate selection ambiguous.

The X.509 certificate profile describes certificate structure and extension handling. Correct malformed certificates at their source and exchange the replacements with the partner.

Encrypted messages can also contain more than one recipient entry in their Cryptographic Message Syntax (CMS) envelope. For example, a sender may include an entry for itself as well as the intended recipient. A receiver must find the entry matching its certificate and private key, rather than assuming that the first or only entry belongs to it. See CMS recipient information.

Keep HTTP headers on one line ​

Send each HTTP header on a single line. Older email libraries may fold long headers across several lines, but this format is unsuitable for current HTTP requests and can be rejected by a server or proxy. HTTP/1.1 field line folding is obsolete. This concerns the HTTP transport headers; MIME headers inside the message have their own rules.

HTTP header names are case insensitive, so Content-Type and content-type identify the same field. Do not apply that rule to every header value: an AS2 identifier still needs to match the agreed partner identifier.

Check the receipt as carefully as the file ​

An MDN is the receipt for an AS2 message. A successful HTTP response alone does not establish that the recipient decrypted the file or accepted its signature. When a transfer appears to succeed but the sender reports a failure, inspect the receipt and the original message together.

Message integrity checks. For signed messages, calculate the Message Integrity Check (MIC) over the signed MIME content, including its MIME headers. Hashing only the extracted business file produces a different result. Preserve the signed bytes when investigating a mismatch; changing line endings can change the digest.

Message identifiers. An MDN's own Message-ID is recommended, rather than mandatory. Its Original-Message-ID must identify the original request, so a receiver can match the receipt to the transfer. Do not confuse these two fields.

Report structure. The report needs its type parameter, for example:

Content-Type: multipart/report; report-type=disposition-notification; boundary="receipt-boundary"

For a signed MDN, this report sits inside a multipart/signed envelope. The required Final-Recipient field belongs in the machine-readable report section. For compatibility with partners that enforce the tested profile, also include Final-Recipient in the human-readable section; adding it there does not replace the required structured field.

These details are covered by RFC 4130, section 7.

Test asynchronous receipts separately ​

A synchronous MDN returns on the original HTTP connection. An asynchronous MDN arrives through a separate connection to the agreed callback URL. The receiver must send the initial HTTP response before processing and sending the asynchronous receipt. Sending the receipt too early can cause a timing problem while the sender is still completing the original request.

An initial 204 No Content response can be acceptable when an asynchronous receipt was requested. It acknowledges the HTTP request without carrying an MDN; the sender still needs to wait for the separate receipt. It cannot replace a requested synchronous MDN, which needs a response body.

Test callback reachability, authentication, and timeout handling as part of onboarding. A working outbound connection does not establish that the partner can connect back to the receipt URL.

Use valid business documents in partner tests ​

Some products validate an EDI or XML document after unpacking the AS2 message. A file containing arbitrary test text may therefore fail even when the transport, signature, and encryption are correct. Use a valid sample that matches your partner's document format and content type.

Keep transport acceptance and business acceptance separate in your test results. SFTPPlus MFT handles AS2 delivery and receipts, while the connected EDI or ERP application interprets and maps the business content.

Prepare a repeatable partner test ​

Record both AS2 identifiers, endpoint URLs, public certificates, signing and encryption settings, MDN mode, and a valid sample document before starting. Keep private keys private. For each test, retain the message identifier, transfer log, and receipt result so both teams can investigate the same exchange.

After a successful transfer, test a failed delivery, retry behaviour, and receipt timeout. This gives you evidence about the complete workflow before production use.

See the AS2 evaluation steps and licence options, or contact our team for help with a partner connection.