You Already Know How This Goes

Certificates exchanged. AS2 IDs configured. Endpoint URL triple-checked. You hit send.

Dead silence. Or a cryptic error that tells you nothing.

Across hundreds of AS2 connections, we see first-attempt success about 15% of the time. The other 85%? Debugging. Usually the same six problems, over and over.

Every one of them is fixable in minutes — if you know where to look. Most teams burn 40+ hours on back-and-forth emails because they don't.

1. Certificate Format Mismatch

This kills more first attempts than everything else combined.

Your partner sends a PEM certificate. Your system wants DER. Or they hand you a PKCS12 bundle and you need the public key pulled out separately. The real problem: most AS2 implementations won't tell you the format is wrong. They'll throw a generic decryption error or a signature verification failure and leave you guessing.

Fix it now. Verify the certificate format before you do anything else:

openssl x509 -in partner_cert.pem -text -noout

If that errors, try DER:

openssl x509 -in partner_cert.der -inform DER -text -noout

Convert between formats with OpenSSL. Thirty seconds.

While you're at it, check the key size. 1024-bit RSA? Most modern AS2 systems will reject it. 2048-bit minimum. 4096-bit is increasingly standard.

Get the certificate right first. Everything else depends on it.

2. MDN Configuration Disagreements

MDN — Message Disposition Notification — is how AS2 confirms receipt. Both sides must agree on three things: sync or async delivery, signing algorithm, and the async receipt URL.

The classic failure: you expect a synchronous MDN. Your partner configured async. Your message sends fine. The MDN ships off to an endpoint you never stood up. Your system reports "no MDN received." You spend three hours wondering if the message even arrived. It did.

Lock down these three settings before your first test:

Sync or async? Start with sync. Fewer moving parts to debug.
Signing algorithm? SHA-256 is the safe default. SHA-1 is deprecated, but some legacy systems still require it.
Async MDN URL? If async, confirm the receipt URL — and confirm it's reachable from their network.

Write these down. Compare side by side. Both teams will swear they agreed on sync. One side will be configured for async. Every time.

3. TLS Version Conflicts

Your endpoint requires TLS 1.2. Your partner's system tops out at TLS 1.0. Or their load balancer terminates TLS and re-encrypts at a different version. The connection dies before any AS2 protocol exchange even starts.

The error message will say "connection refused" or "handshake failure." Zero useful context.

Test TLS independently of AS2:

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

Fails? Try -tls1_3 or -tls1 to find what they actually support. Then check your own server.

TLS 1.2 is the floor in 2026. If your partner can't do TLS 1.2, that's a security conversation, not a configuration problem.

4. AS2 ID Mismatch

AS2-From and AS2-To headers route messages to the right configuration. These IDs are case-sensitive. "ACME_Corp" and "acme_corp" are two different partners as far as AS2 is concerned.

We've seen production outages from a single trailing space in an AS2 ID. The message arrives. The system has no matching configuration. Dead.

Copy and paste AS2 IDs directly from your partner's configuration document. Don't retype them. Check for leading and trailing whitespace. Some GUIs silently trim whitespace. Some don't. Don't find out the hard way.

5. Firewall and Network Blocks

Your AS2 system needs to reach your partner on their configured port — usually 443 or 8443. Their system needs to reach yours for async MDNs. If either firewall blocks the traffic, you get connection timeouts.

Obvious? Sure. Still accounts for about 20% of first-test failures. In large enterprises, the EDI team doesn't control the firewall. The network team doesn't know what AS2 is. Nobody talks to each other until something breaks.

Verify connectivity in both directions before your first test:

curl -I https://partner-endpoint:443

Ask your partner to do the same for your endpoint. Timeout? Get your network team the specific IPs and ports. Don't open a vague ticket — give them exact addresses.

6. Content-Type and Encoding Errors

AS2 messages have specific MIME requirements. The Content-Type header must match the actual payload. Send an EDIFACT interchange with Content-Type: application/edi-x12 and some receiving systems reject it outright. Others accept it and silently misprocess the content. Both outcomes are bad.

Match your Content-Type to your payload:

X12 EDI: application/edi-x12
EDIFACT: application/edifact
Generic EDI: application/edi-consent (catch-all that most systems accept)

Confirm the expected Content-Type with your partner. Don't assume.

The $6,000 Email Chain

Without automated testing, every AS2 onboarding follows the same script:

Configure your system. 30 minutes.
Send a test message. It fails. 5 minutes.
Read the error log. Something unhelpful. 10 minutes.
Email your partner asking if they received anything. Wait 4 hours.
They say no. Or yes, but the MDN failed. Or they forward a different error.
Tweak a setting. Send again. Wait again.
Repeat for 3 to 5 business days.

The actual configuration work totals maybe two hours. The waiting and email ping-pong stretches it to a week. At $150/hour for an integration engineer, that's easily $6,000 in labor per trading partner onboarding — most of it spent waiting.

Test Before You Call Your Partner

Eliminate your side of the equation first. Send a message to a known-good AS2 endpoint. Check the TLS handshake. Verify certificate exchange. Confirm MDN receipt. Validate message structure. All testable independently, all testable right now.

When you do connect with your partner, you've already ruled out your own configuration. If something fails, you know it's a mismatch between systems — not a bug on your end. That conversation goes a lot faster.

AS2 Certify acts as a compliant AS2 endpoint that tests every layer of your connection: TLS, certificates, encryption, signing, MDN exchange, and message structure. You get a graded report — A through F — telling you exactly what passed and what broke. Minutes, not days.

Pre-Test Checklist

Run through this before your first AS2 test message. Ten minutes now saves you a week later.

Certificate format matches your system's expectation (PEM, DER, or PKCS12)
Certificate key size is 2048-bit or higher
Certificate is not expired (check the notAfter date)
AS2 IDs match exactly — case-sensitive, no extra whitespace
MDN type agreed upon: sync vs. async
MDN signing algorithm agreed upon (SHA-256 recommended)
TLS version compatible (1.2 minimum)
Firewall rules allow traffic in both directions
Content-Type header matches the payload format
Endpoint URLs are correct and reachable

Print it. Tape it to your monitor. Use it every time. The problems don't change — only the partner names do.