Can You Test an AS2 Connection Without a Trading Partner?

Not with AS2 alone: the protocol has no loopback or self-test mode, so every meaningful validation requires a second, independently configured endpoint. What you can do is stand in a counterparty, either a simulator you run yourself or a hosted known-good endpoint, and test against that before a real partner ever sees your traffic.

This post is about why that dependency exists and what a real substitute counterparty must do. If you're looking for the step-by-step process, that's a separate piece: how to test an AS2 connection is the how; this is the why.

I care about this problem because I lived it. On a pharmaceutical EDI consulting engagement, onboarding one trading partner took nearly three months, and the single structural cause underneath every delay was that I had no way to test my setup without verifying it with someone else. Every mistake, theirs and mine, cost a multi-day email round-trip to discover.

Why AS2 Has No Loopback

AS2's security model is the reason you can't self-test. Every property worth validating is defined between two parties, not within one.

Encryption is partner-specific. You encrypt with the recipient's public certificate. Only they can decrypt it. Sending a message to yourself proves your server can talk to itself with its own keys, which is precisely the configuration that never runs in production.
Signing only matters at the verifier. Your signature is valid if the other side can verify it with the certificate they hold for you. Your own server verifying its own signature exercises none of the failure modes: stale certs on the far end, signing vs. encryption cert confusion, algorithm mismatches.
The MDN is a two-party artifact. The signed receipt that proves delivery is generated by the receiver, using the receiver's configuration, signed with the receiver's key, per the sender's requested MIC algorithm. There is no MDN without a second party.
Identity is bilateral. AS2 IDs are only "correct" relative to what the counterparty has configured for you. Alone, any string is valid.

Compare that to almost anything else you deploy. An HTTPS API can be curl-ed. A database accepts a test query. AS2's core transaction, encrypt-for-them, sign-as-you, transmit, receive-their-signed-receipt, simply does not exist in single-player mode. Reading your own configuration is the only "test" available, and reading config is how mistakes survive: you see what you intended, not what a counterparty will experience.

The industry's default workaround is grim: use your trading partner's onboarding process as your test environment. Each failed test costs days of "our side is fine" email, because both sides are asserting correctness that neither can check.

What "Testing Without a Partner" Actually Requires

Since the protocol demands a counterparty, testing without a partner means substituting a counterparty you control or trust. To be a real substitute rather than a smoke test, it has to exercise the full stack a partner would:

TLS handshake and certificate chain. It must connect to your endpoint like a stranger would: no locally trusted CAs, so incomplete chains and expired intermediates actually fail, the way they will for a partner.
Certificate exchange and usage. It holds your public certs, you hold its, and it uses them in the correct roles, so encryption-cert-in-the-signing-slot mistakes surface.
Encryption round-trip. It sends messages encrypted to your certificate and confirms your server decrypts them; it decrypts what you send and tells you if it can't, and why.
Signature verification both directions. Including algorithm agreement, the class of mismatch where everything "works" but verification fails.
The full MDN exchange. Sync or async, signed, with MIC computation, because MDN misconfiguration is where delivered messages get reported as failures.

Anything short of that list, a port scan, a TLS checker, a plain HTTPS POST, validates transport, not AS2. Useful as step one, not as an answer.

One more requirement that's easy to overlook: diagnostics you can act on. A counterparty that only reports pass or fail hasn't saved you much, real AS2 servers fail with messages like "decryption failed" that don't distinguish a wrong certificate from a wrong algorithm from a mangled MIME body. The substitute counterparty is only as useful as its ability to tell you which layer broke and what to change. Keep that bar in mind as you weigh the options below, because it's where they differ most.

Your Options, With Honest Trade-offs

Option 1: The mendelson Test Server

mendelson runs a free public AS2 test server, and it deserves credit as the community's longtime answer to this problem. You configure it as a partner, exchange its published certificates, and send messages.

Trade-offs: It's a shared best-effort service, availability and turnaround are not guaranteed, and it's most natural to use from mendelson's own software. Diagnostics are the bigger limit: when a message fails, you get server-log-grade errors, and translating "decryption failed" into "you loaded the wrong cert into the encryption slot" is still on you. It confirms that something is wrong more reliably than what.

Option 2: A Second OpenAS2 Instance

Run OpenAS2 (or a second instance of whatever you run) on separate infrastructure, configure it as a fake partner with its own keys, and trade messages with yourself.

Trade-offs: Maximum control, and genuinely worthwhile for teams doing continuous AS2 development. But you are now standing up and maintaining a second AS2 server, Java, keystores, partner config, its own certs, which is a real project. The subtler problem is epistemic: you configure both ends. If you misunderstand a setting, you'll plausibly misconfigure it identically on both sides, and the test passes while the misunderstanding survives. A test partner you built shares your blind spots. And the diagnostics are whatever OpenAS2 logs, which is to say: terse.

Option 3: A Hosted Known-Good Counterparty

This is the gap I built AS2 Certify's connection test to fill: an always-on AS2 endpoint whose configuration is not in question, that runs the full round-trip against your server, TLS, chain, certs, encryption, signing, MDN, and returns a graded, plain-language report instead of a log line. The point isn't just that it's less setup than option 2; it's that the counterparty is independent of you, so your misunderstandings can't leak into both sides of the test.

Trade-offs: it validates your endpoint against a known-good peer, not against your specific partner's quirks, a partner running a 15-year-old iSeries translator can still surprise you. What it removes is the possibility that the surprise is on your side.

Wherever you land, check the cheap layer first: an expired or mischained certificate fails every option above identically, and the free AS2 certificate checker catches that in seconds.

The Payoff: Change the Sequence, Not Just the Tool

The value of a partner-free test isn't the test itself, it's what it does to onboarding order. Today, most teams validate their setup during partner onboarding, so both sides debug two unproven systems at once, by email. With a counterparty simulator, you validate before onboarding: your side arrives proven, and every remaining failure is, by elimination, on the other side or in the settings between you. That converts "our side is fine" from a claim into a fact, and it's the difference between onboarding measured in months and onboarding measured in days.

When you're ready to actually run this process, the walkthrough lives in the guide: how to test an AS2 connection. Do it before your next partner asks you to. To choose between the free counterparty options, mendelson's public server, your own OpenAS2 instance, or a hosted sandbox, see the comparison of free AS2 testing options.