AS2 Troubleshooting Guide: Common AS2 EDI Errors

TL;DR

Most AS2 EDI errors fall into four buckets: certificate problems (failed decryption or signature verification), network and HTTP errors on transmission, MDN configuration mismatches, and MIC mismatches. AS2 troubleshooting is mostly a matter of identifying which layer failed, inbound or outbound, then applying the standard fix for that category. This guide walks each one with its symptoms and remedies.

How an AS2 EDI Transaction Actually Works

AS2 EDI transfers are transactional. The sender needs confirmation that the recipient could actually interpret the content, not just receive it. A complete EDI transaction requires two things:

1. A successful AS2 transmission confirmed by a positive MDN (Message Disposition Notification) receipt.
2. A successful EDI acknowledgment is typically a functional acknowledgment (997, in X12) confirming the business document itself was accepted.

Each EDI file is sent as its own AS2 message. That means a complete EDI transaction involves at least two separate AS2 transmissions: one for the original file and one for the returned acknowledgment. For a deeper primer on this relationship, see our must-know facts on AS2.

Inbound AS2 Failures

Inbound failures occur on the receiving side when the recipient cannot decode, verify, or process an incoming AS2 message.

Identification or Partner Mismatch

If the receiving AS2 server cannot match the AS2-From or AS2-To headers to a known trading party, it will reject the message often with an HTTP 422 error or a negative MDN citing an “unknown AS2 association.”

Fix: Compare AS2 identifiers on both ends and correct any mismatches.

Decryption Failed

The sender encrypts each message using the recipient’s public certificate. Decryption fails most often because:

• The sender used the wrong certificate to encrypt the message.
• The recipient’s certificate was recently renewed or rotated, and the sender is using an outdated copy.
• The payload was corrupted or truncated during transmission.

Fix: Compare the certificate serial number and issuer on both ends. For payload corruption, check the Content-Length header against the actual received size, and retry using AS2 restart for large files.

AS2 encryption/decryption flow

Signature Verification Failed

The sender signs each message so the recipient can verify authenticity. This step fails when:

• The recipient does not trust the sender’s certificate chain.
• The recipient has the wrong certificate assigned for verifying the sender’s signatures.
• The message digest (calculated and embedded by the sender) doesn’t match the locally calculated value, which may indicate tampering or a content-encoding mismatch.

Fix: Import the missing certificate chain into the recipient’s trust store, confirm the correct verification certificate is assigned, and check Content-Transfer-Encoding settings if digests consistently mismatch without evidence of tampering.

Unmatched MIC

The receiver calculates a message integrity check (MIC) and returns it in the MDN. If the sender’s own MIC calculation doesn’t match, an “unmatched MIC” error appears even though the MDN itself may show as successful.

Common causes include a mismatched MIC algorithm between sender and receiver or differences in MIC string formatting (e.g. sha-256 vs sha256). Persistent mismatches after previously successful exchanges can also signal payload corruption or interference.

Fix: Align the MIC algorithm and string format on both ends. If exchanges were previously clean, review certificates for signs of compromise.

Outbound AS2 Failures

Outbound failures happen on the sending side, when a message fails to reach the receiver or the receiver’s response can’t be interpreted.

Transmission and Network Errors

Since AS2 connectivity runs over HTTP, network issues can interrupt any transmission. Common variants include:

• Connection timeout, reset, or broken pipe - the connection dropped mid-transfer; confirm with the receiver whether the message was actually processed before resending.
• Connect timeout/connection refused - the sender could not reach the receiver’s URL at all, often due to an incorrect hostname, port, or firewall rule. Safe to retry once resolved.
• Unknown host - DNS resolution failed; double-check the receiver’s URL. Safe to retry once resolved.
• TLS/SSL handshake errors - certificate trust issues, hostname mismatches, or unsupported TLS versions between sender and receiver. Safe to retry once resolved.

Fix: Diagnose with tools like nslookup or openssl s_client (based on the symptom), and retry the transmission as appropriate.

Flowchart of AS2 network error diagnosis steps

HTTP Error Responses

A successful network transfer can still return an HTTP-level error:

Fix: Match the error code against the table above, and confirm partner-side configuration where the cause isn’t included in the response body.

MDN Pending or Not Received

If an expected MDN never arrives, check whether synchronous or asynchronous MDN mode was requested:

• In sync mode, a missing MDN usually points to a Disposition-Notification-Options header mismatch between sender and receiver.
• In async mode, the MDN may simply be delayed — give it a reasonable window (minutes, occasionally up to an hour) before treating it as a true MDN troubleshooting case.

This is one of the most common categories covered under general AS2 debugging, since both connectivity and configuration issues can produce the same symptom.

Comparison of sync vs async MDN delivery

MDN Signature Verification Failure

If the receiver signs the returned MDN and the sender cannot verify it, the sender has no guarantee the receipt is authentic. As with unmatched MIC errors, the MDN may still show as otherwise successful.

Fix: Confirm the receiver’s verification certificate is correctly configured on the sender’s side.

A Quick Reference for AS2 Errors

For a broader checklist before going live with a new AS2 and EDI connection, see our AS2 compliance checklist. And if you’re setting up a new trading partner connection from scratch, our guide on Tractor Supply AS2 EDI connectivity walks through a real-world example end to end.

For the formal specification behind these behaviors, the AS2 RFC 4130 standard remains the authoritative reference.

Frequently Asked Questions

Why is my AS2 MDN not being received?

Check whether you requested a synchronous or asynchronous MDN. In sync mode, a missing MDN usually points to a Disposition-Notification-Options mismatch between you and your partner. In async mode, the MDN can simply be delayed, so allow a reasonable window, sometimes up to an hour, before treating it as a genuine failure.

What causes an AS2 decryption failed error?

Decryption fails when the sender encrypted with the wrong certificate, when your certificate was recently renewed and the sender still holds an old copy, or when the payload was corrupted in transit. Compare the certificate serial number and issuer on both ends, and check the received size against the Content-Length header.

What is an unmatched MIC in AS2?

The receiver returns a message integrity check in the MDN. If your own MIC calculation does not match, you get an unmatched MIC error even when the MDN itself looks successful. It is usually a MIC algorithm or string-format mismatch, for example sha-256 versus sha256. Align both.

Is an HTTP 200 the same as a successful AS2 transfer?

No. A 200 confirms the transmission was received, not that the content was decrypted, verified, and accepted at the EDI level. A complete X12 transaction also needs a positive MDN and a 997 functional acknowledgment.

How do I know if a failure is inbound or outbound?

HTTP 4xx/5xx responses and connection errors are outbound problems on your side or the partner’s endpoint. Negative MDNs citing certificate or association errors are inbound problems the receiver hit while decoding your message. Identifying the layer first is the whole game.

Troubleshoot AS2 Issues Faster with the Right Tools

Most AS2 errors fall into a handful of predictable categories — certificate mismatches, network issues, MDN configuration, or MIC mismatches. Once you know which category you’re dealing with, the fix is usually quick.

A good AS2 server will isolate failed messages, support automatic retries, and alert administrators the moment a transmission fails — saving hours of manual AS2 debugging.

Start your free AS2 Gateway trial →

Still stuck on a specific error? Reach out to our support team — we’re happy to help you pinpoint it.