Your Boss Just Said "We Need AS2"

A new trading partner requires AS2 for EDI exchange. You've never set one up before. The partner sent over a PDF with their AS2 ID, endpoint URL, and a certificate file. Now what?

This guide walks through every step of standing up an AS2 server, from choosing software to sending your first successful test message. No theory. No fluff. Just the decisions you need to make and the commands to run.

Step 1: Choose Your AS2 Software

You have three categories to pick from. The right choice depends on your budget, team size, and how many trading partners you'll manage.

Open Source Options

OpenAS2 is the most widely used open-source AS2 implementation. It's Java-based, runs on any OS, and handles the core AS2 protocol well. Configuration lives in XML files. No GUI out of the box, but there's a web dashboard project you can bolt on. It's production-ready for small to mid-size deployments (under 50 partners).

Pros: Free, well-documented, active community, supports sync and async MDN, handles S/MIME encryption and signing.

Cons: XML configuration gets unwieldy with many partners, no built-in monitoring or alerting, Java dependency.

mendelson AS2 is another open-source option with a Java Swing GUI. It's easier to configure visually, but the open-source version lacks features like HA clustering and HTTPS server mode. The commercial version adds those.

Pros: GUI for configuration, built-in message log viewer, active development.

Cons: Open-source version is limited, GUI requires a desktop environment (not ideal for headless servers), commercial license required for production features.

Commercial Options

IBM Sterling B2B Integrator is the enterprise standard. If you're onboarding 100+ partners or need SLA guarantees, this is what large pharma and retail companies run. Expect six-figure licensing.

Cleo Harmony / VLTrader offers a middle ground. Good GUI, solid AS2 support, managed file transfer capabilities. Licensing is more accessible than IBM Sterling.

Drummond Certified products carry weight with partners who require interoperability certification. Both commercial and some open-source products hold Drummond certification. Check if your partner requires it.

Cloud/Managed Options

AWS Transfer Family now supports AS2 natively. If you're already on AWS, this eliminates server management entirely. You configure partners through the AWS console or Terraform, and AWS handles the AS2 protocol, TLS termination, and certificate management. Pricing is per-connector plus data transfer.

Azure Logic Apps has an AS2 connector for B2B scenarios. Good if you're in the Microsoft ecosystem.

Which One Should You Pick?

For a first AS2 setup with fewer than 10 partners: OpenAS2. It's free, you'll learn the protocol internals, and you can migrate to a commercial product later if needed. The rest of this guide uses OpenAS2 as the reference, but the concepts apply to any AS2 implementation.

Step 2: Install and Run OpenAS2

Prerequisites: Java 11 or higher installed on your server.

Download the latest release from the OpenAS2 GitHub repository:

wget https://github.com/OpenAS2/OpenAs2App/releases/download/v4.8.0/OpenAS2Server-4.8.0.zip
unzip OpenAS2Server-4.8.0.zip -d /opt/openas2
cd /opt/openas2

Start the server to verify it runs:

./bin/start-openas2.sh

You should see log output indicating the server started successfully. By default, OpenAS2 listens on port 10080 (HTTP) and 10443 (HTTPS). We'll change these later.

If you're using Docker, OpenAS2 publishes official images:

docker run -d --name openas2 \
  -p 10080:10080 \
  -p 10443:10443 \
  -v $(pwd)/config:/opt/openas2/config \
  -v $(pwd)/data:/opt/openas2/data \
  openas2/openas2:latest

Step 3: Generate Your Certificates

AS2 uses X.509 certificates for two purposes: encrypting message payloads (so only the recipient can read them) and signing messages (so the recipient can verify the sender). You need a key pair: a private key you keep secret and a public certificate you share with partners.

Option A: Self-Signed Certificate

Acceptable for many AS2 connections. Your partner will explicitly trust your specific certificate rather than relying on a CA chain.

# Generate a 4096-bit RSA private key
openssl genrsa -out my_as2_key.pem 4096

# Create a self-signed certificate valid for 2 years
openssl req -new -x509 -key my_as2_key.pem -out my_as2_cert.pem -days 730 \
  -subj "/CN=as2.yourcompany.com/O=Your Company/C=US"

Use 4096-bit RSA. Some partners still accept 2048-bit, but 4096 is the direction the industry is moving. Don't use 1024-bit under any circumstances.

Option B: CA-Signed Certificate

Required by some partners, especially in regulated industries like pharma (DSCSA) or automotive. Generate a Certificate Signing Request (CSR) and submit it to a CA like DigiCert, Sectigo, or Let's Encrypt:

# Generate key and CSR
openssl genrsa -out my_as2_key.pem 4096
openssl req -new -key my_as2_key.pem -out my_as2_csr.pem \
  -subj "/CN=as2.yourcompany.com/O=Your Company/C=US"

Submit the CSR to your CA. They'll return a signed certificate, usually within minutes for DV certificates or days for OV/EV.

Import Into OpenAS2's Keystore

OpenAS2 uses a Java keystore (PKCS12 format). Convert and import your key pair:

# Create a PKCS12 bundle
openssl pkcs12 -export -in my_as2_cert.pem -inkey my_as2_key.pem \
  -out my_as2.p12 -name mycompany

# Import into OpenAS2's keystore
keytool -importkeystore -srckeystore my_as2.p12 -srcstoretype PKCS12 \
  -destkeystore /opt/openas2/config/as2_certs.p12 -deststoretype PKCS12 \
  -srcalias mycompany -destalias mycompany

Do the same for your partner's public certificate (you don't need their private key, obviously):

keytool -importcert -file partner_cert.pem \
  -keystore /opt/openas2/config/as2_certs.p12 -storetype PKCS12 \
  -alias partnercompany

Step 4: Configure Your Partnership

OpenAS2 partnerships are defined in config/partnerships.xml. Each partnership defines the relationship between you and one trading partner: AS2 IDs, certificates, endpoints, encryption, and MDN preferences.

Here's a working partnership configuration:

<partnership name="mycompany-to-partner"
  sender="mycompany" receiver="partnercompany"
  as2_url="https://partner-as2.example.com/as2"
  subject="AS2 Message"
  content_type="application/edi-x12"
  encrypt="3des" sign="sha256"
  as2_mdn_to="https://your-as2-server.com:10443/as2"
  as2_mdn_options="signed-receipt-protocol=optional, pkcs7-signature; signed-receipt-micalg=optional, sha-256" />

Key settings to get right:

as2_url: Your partner's AS2 endpoint URL. Get this from their onboarding document. Don't guess.
sender/receiver: These map to AS2 ID definitions in config/partnerships.xml. The AS2 IDs are case-sensitive.
encrypt: AES-256 is preferred. 3DES is widely supported but being phased out. Ask your partner what they support.
sign: SHA-256 minimum. SHA-1 is deprecated. SHA-512 if your partner supports it.
content_type: Must match your payload. application/edi-x12 for X12 EDI, application/edifact for EDIFACT, application/xml for XML payloads.

Also define your local AS2 identity in the partnerships file:

<partner name="mycompany"
  as2_id="MYCOMPANY_AS2"
  x509_alias="mycompany"
  email="edi@yourcompany.com" />

<partner name="partnercompany"
  as2_id="PARTNER_AS2_ID"
  x509_alias="partnercompany"
  email="edi@partner.example.com" />

Triple-check the AS2 IDs. Copy them directly from your partner's documentation. A trailing space or wrong capitalization will cause message rejection with an unhelpful error.

Step 5: Configure Firewall and Network Rules

AS2 runs over HTTP/HTTPS, so the port requirements are straightforward, but getting them wrong accounts for roughly 20% of first-test failures.

Inbound Rules (Your Firewall)

Port 443 (HTTPS): Your partner sends AS2 messages to you on this port. This is also where async MDN responses arrive. Open this to your partner's IP range, or to the internet if you don't know their egress IPs.
Port 80 (HTTP): Only if your partner doesn't support HTTPS. Strongly discouraged in 2026. AS2 message-level encryption protects the payload, but TLS protects the headers and metadata.

Outbound Rules (Your Firewall)

Port 443 (HTTPS): You send AS2 messages and sync MDN responses to your partner on this port. Most corporate firewalls allow outbound 443 by default, but verify.
Port 8443 or custom: Some partners run AS2 on non-standard ports. Check their endpoint URL.

Reverse Proxy / Load Balancer

In production, you'll typically put a reverse proxy (Nginx, HAProxy, or an AWS ALB) in front of your AS2 server. This handles TLS termination, so your AS2 software doesn't need to manage certificates for the HTTPS layer separately from the AS2 S/MIME certificates.

Example Nginx config for proxying AS2 traffic:

server {
    listen 443 ssl;
    server_name as2.yourcompany.com;

    ssl_certificate /etc/ssl/certs/as2_tls.pem;
    ssl_certificate_key /etc/ssl/private/as2_tls_key.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location /as2 {
        proxy_pass http://127.0.0.1:10080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Important: TLS certificates (for HTTPS) and AS2 certificates (for S/MIME encryption/signing) are separate. You need both. They can be different certificates from different CAs. Don't confuse them.

DNS

Create a DNS record for your AS2 endpoint: as2.yourcompany.com pointing to your server's public IP. Give your partner this URL: https://as2.yourcompany.com/as2. Use a dedicated subdomain so you can move the AS2 server independently of your main website.

Step 6: Configure MDN Settings

The Message Disposition Notification (MDN) is AS2's receipt mechanism. When you send a message, the receiver sends back an MDN confirming they got it (or reporting an error). You need to decide: synchronous or asynchronous?

Synchronous MDN

The receiver sends the MDN back on the same HTTP connection as the original message. Your system sends the AS2 message, holds the connection open, and receives the MDN in the HTTP response. Simple. One connection. One round trip.

Use sync MDN when:

Messages are small (under 50MB)
You want simpler debugging (one connection to trace)
Your partner supports it
You're just getting started and want fewer moving parts

Asynchronous MDN

The receiver closes the original HTTP connection immediately (HTTP 200, no body) and sends the MDN later as a separate HTTP POST to your MDN receipt URL. This requires your server to have an accessible endpoint for receiving inbound MDNs.

Use async MDN when:

Messages are large (50MB+) and you don't want to hold connections open
Your partner's system takes time to process before confirming receipt
Your partner requires it

Critical detail for async MDN: Your MDN receipt URL must be reachable from your partner's network. If your AS2 server is behind a firewall with no inbound access, async MDN won't work. You'll send the message successfully, never receive the MDN, and waste hours thinking the message failed when it actually arrived fine.

MDN Signing

Always request a signed MDN. An unsigned MDN proves nothing. A signed MDN provides non-repudiation: cryptographic proof that the specific partner received your specific message. Configure the signing algorithm to SHA-256. SHA-1 is deprecated.

In your partnership config:

as2_mdn_options="signed-receipt-protocol=optional, pkcs7-signature; signed-receipt-micalg=optional, sha-256"

The "optional" keyword means you're requesting a signed MDN but will accept unsigned if the partner can't sign. Change to "required" if you need guaranteed signed receipts (common in pharma/DSCSA).

Step 7: Test the Connection End-to-End

Before contacting your partner, validate your own setup independently. This saves enormous amounts of time.

Self-Test: Loopback

Configure a partnership where you are both sender and receiver. Send a message to yourself. This validates that your certificates are correctly installed, your AS2 software processes messages properly, and MDN generation works.

Connectivity Test

Verify you can reach your partner's endpoint:

# Test HTTPS connectivity
curl -v https://partner-as2.example.com/as2

# Test TLS version support
openssl s_client -connect partner-as2.example.com:443 -tls1_2

# Verify DNS resolution
nslookup partner-as2.example.com

If any of these fail, fix the network issue before attempting an AS2 exchange. No amount of AS2 configuration fixes a firewall block.

Certificate Verification

Confirm you have the right partner certificate:

# Check the certificate details
openssl x509 -in partner_cert.pem -text -noout

# Verify it hasn't expired
openssl x509 -in partner_cert.pem -noout -enddate

# Check key size (2048-bit minimum)
openssl x509 -in partner_cert.pem -noout -text | grep "Public-Key"

Send a Test Message

Place a small test file in OpenAS2's outbox directory for the partner:

echo "Test AS2 message from MYCOMPANY" > /opt/openas2/data/toPartner/test.txt

Watch the logs:

tail -f /opt/openas2/logs/openas2.log

A successful exchange shows: message sent, HTTP 200 received, MDN received and verified. If anything fails, the log will indicate which step broke.

Common Setup Mistakes

After helping teams configure hundreds of AS2 connections, these are the mistakes that come up repeatedly:

Confusing TLS certificates with AS2 certificates. TLS secures the HTTP transport. AS2 certificates handle message-level encryption and signing. They're independent. You need both.
Using the same certificate for signing and encryption. This works, but best practice is separate key pairs for each purpose. If a signing key is compromised, your encryption is still safe.
Forgetting to open inbound firewall ports. You can send messages all day. If your partner can't reach your endpoint for async MDNs (or for sending their messages to you), the connection is half-broken.
Not testing with your actual payload type. A test with a plain text file succeeds. Your real X12 EDI file fails because the Content-Type doesn't match, or the payload exceeds a size limit you didn't know about.
Assuming AS2 IDs are case-insensitive. They're not. "MyCompany" and "mycompany" are different identities. Copy-paste from documentation. Never retype.

Validate Your Setup Before Going Live

You've installed the software, generated certificates, configured partnerships, opened firewall ports, and set MDN preferences. Before you email your trading partner to schedule a test, make sure your side is solid.

AS2 Certify acts as a compliant AS2 endpoint that tests every layer of your configuration: TLS handshake, certificate validity, encryption, signing, MDN exchange, and message structure. It runs an 8-step diagnostic and produces a graded report (A through F) showing exactly what passed and what needs attention.

The difference between showing up to a partner test with a validated configuration versus an untested one is the difference between a 15-minute call and a two-week email chain. Test your setup first. Fix what's broken on your end. Then connect with your partner knowing your side works.

Quick Reference Checklist

Keep this list handy during setup:

AS2 software installed and running (OpenAS2, mendelson, or commercial)
Private key generated (4096-bit RSA recommended)
Public certificate created (self-signed or CA-signed per partner requirements)
Partner's public certificate imported into your keystore
Partnership configured with correct AS2 IDs (case-sensitive, no whitespace errors)
Encryption algorithm agreed upon (AES-256 preferred)
Signing algorithm agreed upon (SHA-256 minimum)
MDN type agreed upon (sync or async)
If async MDN: receipt URL configured and reachable from partner's network
MDN signing requested (SHA-256)
Firewall: inbound 443 open for receiving messages and async MDNs
Firewall: outbound 443 open for sending messages
DNS record created for your AS2 endpoint
TLS certificate installed on reverse proxy (separate from AS2 certificates)
TLS 1.2 or 1.3 enforced
Loopback self-test passed
Connectivity to partner endpoint verified
Test message sent and MDN received