Every failed AS2 connection eventually produces the same email: "We've checked everything on our side — the problem must be on yours." You will receive this email, and you will send a version of it too. I know because I spent a 2–3 month consulting engagement onboarding a single trading partner for a pharmaceutical wholesaler, and most of that calendar time was exactly this exchange, cycling.

The problem isn't that anyone is lying. It's that neither side can see the other's configuration, both sides are partially wrong more often than either expects (I was — more on that below), and the protocol gives you no neutral referee. This is the method I wish I'd had: how to establish what you can prove unilaterally, what genuinely requires the partner, and how to make every email you send carry evidence instead of assertions.

Why does AS2 debugging turn into finger-pointing?

Because an AS2 exchange only works when roughly a dozen settings match on both ends — AS2 IDs, certificates, encryption algorithm, signing algorithm, MDN mode — and each side can only inspect its own half. When a message fails, the error message one side sees rarely identifies which half is wrong. Absent evidence, each side reasons "I checked my settings, they look right to me," and the blame flows outward by default.

Each round-trip of that email exchange costs real time. Your partner's EDI team has a queue; you are not their only integration. A question asked today gets answered Thursday. If the answer is "can you re-send your cert?", the follow-up lands next Monday. That's how a mismatch that takes minutes to fix consumes weeks of calendar. In my engagement, several of these cycles stalled completely and had to be restarted from scratch.

What can you verify without your partner's help?

More than you think. Before sending a single accusatory email, you can unilaterally establish about two-thirds of the failure surface. Work through these in order:

1. Their endpoint is reachable and the TLS layer is sound

You can independently confirm: the URL resolves, the port accepts connections, the TLS certificate on their HTTPS endpoint is valid and unexpired, and the TLS versions/ciphers offered overlap with what your software supports. If the TLS handshake itself fails, no AS2 configuration on either side matters yet — and you can prove where the handshake broke.

2. The certificate they sent you is what it claims to be

Inspect the partner certificate you were given: is it expired? Is it a complete chain or a bare leaf certificate? Is it the signing cert or the encryption cert (partners often use separate ones, and swapping them produces maddeningly vague errors)? Run it through a certificate checker before assuming it's fine — "the cert they emailed us was not the cert their server uses" is a classic, and you can catch half of that class on your side alone.

3. Your own outbound message is well-formed

This is the humbling one. In my onboarding-from-hell engagement, some of the blocking problems were mine — server setup mistakes I could not detect because I had no way to test my configuration except by sending to the partner and interpreting silence. If you can send a test message to a known-good AS2 endpoint that decrypts it, verifies your signature, and returns a signed MDN, you have proof your outbound half works. That single capability would have saved me weeks.

4. Your inbound endpoint accepts a valid message

The mirror test: can a known-good sender deliver to you, and does your server decrypt, verify, and respond with a correct MDN? If yes, your inbound half is provably fine, and you can say so with a straight face — and a report.

What genuinely requires the partner's participation?

Only the settings that are agreements rather than facts: the exact AS2 IDs on each side (case-sensitive, whitespace-sensitive), which certificate each side should be using for which purpose, the chosen encryption and signing algorithms, and whether MDNs are synchronous or asynchronous (and if async, the return URL). These live in both systems simultaneously and can only be reconciled by comparing them — which is exactly why your emails about them need to be precise.

How do you write the email that ends the ping-pong?

Send evidence and a single yes/no question, not a summary of your feelings about your configuration. The difference:

Assertion (starts another cycle): "We've verified our configuration and everything looks correct. Please check your side."

Evidence (ends a cycle): "TLS handshake to your endpoint succeeds. Your encryption cert (serial ending 4F2A, expires 2027-03-01) validates with a full chain. Our test message to a neutral endpoint decrypts and returns a signed MDN, so our outbound signing and encryption are confirmed working. The remaining variables are the AS2 ID pair and your MDN mode. Can you confirm your inbound AS2 ID is exactly ACME-PROD (not ACMEPROD) and that you're returning synchronous MDNs?"

The second email does two things the first cannot: it removes every already-proven component from the discussion, and it hands the partner a question they can answer in one reply. You've also quietly established that when the fix turns out to be on their side, there's a written record of what was eliminated and when — which changes the politics entirely. Nobody argues with a dated test result.

Why does a third-party report change the conversation?

Because it's not you saying it. "Our team believes our setup is correct" is an opinion from an interested party. A graded report from a neutral system that tested TLS, certificates, encryption, signing, and MDN round-trip — with pass/fail per check — is a referee's scorecard. In a stalled onboarding, forwarding a report that shows seven green checks and the exact failing one moves the conversation from whose fault is it to here's the one thing left to fix. This is precisely the 8-check diagnostic that AS2 Certify's connection tester automates: it plays the role of the known-good counterparty I never had, and produces the evidence artifact you attach to that email.

The elimination sequence, summarized

Prove reachability and TLS yourself. No partner needed.
Validate their certificate yourself. Expiry, chain, purpose. No partner needed.
Prove your outbound half against a neutral endpoint. No partner needed — this is the step that catches your own mistakes before they cost you credibility.
Prove your inbound half from a neutral sender. No partner needed.
Only then, reconcile the agreements: AS2 IDs, cert assignments, algorithms, MDN mode — one precise yes/no question per email.

Run in this order, the two or three genuinely two-sided settings are all that's left by the time you involve the partner — and every claim you make arrives with proof attached. My three-month onboarding would have been a two-week onboarding with this sequence. That's not a hypothetical; that's the arithmetic of removing four or five useless email cycles at three days each.

Run the free 8-check diagnostic against your endpoint, or create an account to get the graded report you can forward to your partner.