How to Test an AS2 Connection (With or Without a Trading Partner)

Why AS2 testing is harder than it should be

An AS2 connection only works when at least eight things line up at the same time: network reachability, TLS negotiation, certificate validity on both sides, agreed encryption and signing algorithms, matching AS2 identifiers, a correctly framed message, and a valid MDN receipt. When any one of them is wrong, most AS2 software reports a generic failure. The usual result is days of email ping-pong with your trading partner's IT team, because traditional testing requires both sides to be online and cooperating at once.

Step 1: Verify network reachability and TLS

Before anything AS2-specific, confirm the endpoint accepts connections and negotiates a modern TLS version:

openssl s_client -connect partner.example.com:443 -tls1_2

• A timeout means a firewall or routing problem, not an AS2 problem.
• A handshake failure usually means the server requires TLS 1.2 or 1.3 and your client offered something older, or vice versa.
• Note the certificate chain the server presents. An incomplete chain breaks many AS2 clients even when browsers accept it.

Step 2: Validate the certificates

AS2 typically involves up to three certificates: the TLS certificate, the partner's signing certificate, and the encryption certificate. Check each for expiry, chain integrity, and key usage. Expired or soon-to-expire certificates are the single most common cause of AS2 connections that worked yesterday and fail today. You can inspect a certificate with:

openssl x509 -in partner-cert.pem -noout -dates -subject -issuer

Or upload it to our free AS2 certificate checker for a structured report on validity, key size, and usage flags.

Step 3: Confirm encryption and signing algorithms

Both sides must agree on the payload encryption algorithm and the signature hash. Modern deployments should use AES-256 for encryption and SHA-256 for signing. A mismatch here produces some of the most misleading errors in AS2: the message arrives, decryption or signature verification fails, and the sender sees only a vague MDN error or no MDN at all. If your partner's spec sheet says SHA-1 or 3DES, treat that as a flag to confirm before testing, not after.

Step 4: Exchange a test message

With the plumbing verified, send a real AS2 message: signed, encrypted, and addressed with the exact AS2 IDs both sides configured. AS2 identifiers are case sensitive, and an ID mismatch is a classic silent failure: the HTTP request succeeds, but the receiver rejects or misroutes the message. Keep the first payload trivial (a small text file) so any failure is attributable to the connection, not the document.

Step 5: Validate the MDN receipt

The Message Disposition Notification is your proof of delivery. Verify that an MDN comes back at all (synchronous or asynchronous, whichever was agreed), that it is signed if you requested a signed MDN, and that the Message Integrity Check (MIC) in the MDN matches the payload you sent. A missing or unsigned MDN undermines non-repudiation, which is the main reason regulated industries use AS2 in the first place.

Testing without a trading partner

Everything above assumes someone is on the other end. In practice, the biggest source of delay in AS2 onboarding is waiting for the partner: their IT team is in another time zone, mid-migration, or simply booked. You have three options:

• Loopback testing: point your AS2 server at itself with a second partner profile. This validates your own configuration but cannot catch interoperability problems with a different stack.
• Public test servers: some vendors run free test endpoints you can send to. These confirm outbound flow but give you little diagnostic detail when something fails, and they cannot test your inbound direction.
• A partner simulator: a service that acts as a fully instrumented trading partner, receives your messages, sends you messages, and reports exactly which of the checks above passed or failed. This is what AS2 Certify does: it runs all eight checks against your endpoint and returns a graded diagnostic report in about 60 seconds, with no coordination required.

Common failures and what they mean

• Connection refused or timeout: firewall rule, wrong port, or the partner allowlists source IPs and yours is not on it.
• TLS handshake failure: protocol version mismatch or an incomplete certificate chain on the server.
• Message rejected with HTTP 403 or 500: AS2 ID mismatch (check case), unknown certificate, or the partner has not finished configuring your profile.
• MDN not received: asynchronous MDN URL unreachable from the partner side, MDN signing mismatch, or the message failed processing after receipt.
• MIC mismatch: payload was altered in transit or the two sides computed the MIC over different content (often a canonicalization or content-type disagreement).