To set up an AS2 connection, two trading partners must exchange configuration values, create matching partner profiles, test signed and encrypted messages, validate MDNs and agree when production traffic can begin. The software configuration is only one part of the job; ownership, evidence and a controlled cutover are equally important.
This tutorial follows the implementation sequence from the first partner request to a monitored production connection.
1. Confirm the business scope
Before configuring AS2, record what the connection is for:
- legal entities and trading-partner names;
- document standards and versions, such as X12 4010 or EDIFACT D96A;
- transaction types, such as purchase orders, invoices or ASNs;
- expected daily and peak volume;
- maximum file size and latency requirement;
- test scenarios and business acceptance criteria;
- planned production date and support contacts.
This prevents the transport test from being mistaken for project completion. AS2 can deliver a package successfully even when its EDI content does not meet the partner’s implementation guide.
2. Separate test and production
Create distinct environments or clearly separated profiles. Test and production may use different endpoint URLs, AS2 IDs and certificates. Never assume the production value is the test value with a different hostname.
Use explicit names such as PARTNER_TEST and PARTNER_PROD, restrict production private-key access and prevent test workflows from routing real business documents. Record who can approve a production change.
3. Exchange AS2 connection parameters
Both parties normally provide:
| Parameter | Your value | Partner value |
|---|---|---|
| AS2 ID | Sent as your AS2-From | Sent as your AS2-To |
| Endpoint URL | Where you receive | Where you send |
| Public certificate | Used by partner to verify/encrypt | Used by you to verify/encrypt |
| Signing algorithm | What you send and accept | What partner sends and accepts |
| Encryption algorithm | What you accept | What partner accepts |
| MDN mode | Sync or async | Sync or async |
| Signed MDN | Required or optional | Required or optional |
| MIC algorithm | Accepted value | Accepted value |
Also agree compression, content type, filename convention, timeout, retry and duplicate handling. The AS2 connection parameters reference explains every field and includes a reusable handoff template.
4. Verify certificates before importing them
Exchange public certificates only. Compare the SHA-256 fingerprint through an independent trusted channel, especially when the file arrived by email. Check:
- subject and issuing organization;
- serial number and fingerprint;
- validity start and expiry dates;
- key usage and supported algorithm;
- whether the file is PEM, DER, PKCS#7 or PKCS#12;
- whether a PKCS#12 file contains a private key and therefore needs stricter handling.
Associate each certificate with the correct purpose and environment. A certificate called partner_new.cer is not enough evidence; the fingerprint should be the authoritative identifier. For lifecycle practices, see AS2 certificates explained.
5. Configure the local and remote identities
Create your local AS2 station with its AS2 ID, private key and receiving endpoint. Then create a partner profile with the remote AS2 ID, endpoint and public certificates.
Enter AS2 IDs exactly, including spaces, punctuation and case expected by the partner. Some applications quote identifiers in headers; reproduce the agreed logical value rather than guessing from the company name.
Assign the outbound signing key and the partner encryption certificate in the correct direction. For inbound traffic, configure the partner certificate used to verify its signature and your private key used to decrypt.
6. Configure security algorithms
Choose only algorithms supported and approved by both platforms. Do not enable a setting because it sounds stronger without confirming interoperability. Record the agreed values for:
- signature digest;
- content encryption;
- MIC calculation for signed MDNs;
- payload compression;
- TLS versions and any mutual TLS requirement.
Treat a later algorithm change as a coordinated partner change. If one side changes first, production traffic can stop immediately.
7. Configure the MDN
Decide whether the receipt is synchronous or asynchronous and whether it must be signed. For a signed MDN, configure the certificate used to validate the receipt and the allowed MIC algorithm.
For asynchronous MDNs, your return endpoint must be reachable by the partner and mapped to the correct profile. Test this inbound route separately; a successful outbound POST does not prove that the callback path works.
An MDN reports AS2 processing, not final EDI acceptance. Define how your monitoring will correlate the message with a later 997, 999, CONTRL or application response. Read synchronous versus asynchronous MDNs for the receipt workflow.
8. Connect AS2 to the internal workflow
Decide how files move between AS2 and your ERP, translator or integration platform. Common patterns include:
- watched inbound and outbound folders;
- SFTP used internally while AS2 is used externally;
- REST API upload and download;
- webhooks that trigger downstream processing;
- direct integration with an EDI translator or integration platform.
Preserve a stable correlation ID between the internal job, AS2 Message-ID, MDN and business acknowledgment. Without that chain, support teams can see that something failed but cannot determine which invoice or order is affected.
9. Run connectivity and protocol tests
Start with the lowest layer and move upward:
- Resolve DNS and reach the partner host and port.
- Complete the TLS handshake and validate the HTTPS route.
- Send a small AS2 message with the agreed IDs.
- Validate decryption and signature verification.
- Receive the expected signed or unsigned MDN.
- Match the MDN Message-ID and MIC to the original message.
- Reverse the direction and test inbound processing.
Do not stop after a “successful connection” message in the UI. Export or capture the evidence specified in the AS2 pre-go-live test plan.
10. Test representative EDI documents
Use documents that exercise the actual business workflow. A useful test set includes:
- one valid outbound document;
- one valid inbound document;
- multiple interchanges or transactions if supported;
- the maximum realistic size;
- special characters and line endings used in production;
- a duplicate Message-ID;
- an invalid signature or wrong certificate in a controlled test;
- an EDI syntax or business-rule failure.
Confirm which failures produce an AS2 error MDN and which produce a later EDI rejection. This becomes the foundation of the operating runbook.
11. Agree production cutover
Before switching traffic, both partners should confirm in writing:
- production AS2 IDs, URLs and certificate fingerprints;
- activation date and time zone;
- first production document and expected response;
- whether old and new routes overlap;
- rollback decision and contact path;
- monitoring owners on both sides.
Freeze unrelated configuration changes during the cutover window. Send a controlled first transaction, verify the MDN and downstream result, and obtain partner confirmation before increasing volume.
12. Monitor after go-live
At minimum, alert on:
- missing MDNs beyond the agreed threshold;
- negative MDN dispositions;
- signature or decryption failures;
- repeated retries or duplicate messages;
- downstream EDI rejection;
- queue growth or delivery latency;
- certificate expiry well before the activation deadline.
Keep raw message metadata and audit events for the retention period required by the business. Use AS2 transaction monitoring to define states, alerts and escalation ownership.
Common setup mistakes
Reversing certificate direction
Encrypt outbound messages with the partner’s public certificate and sign them with your private key. A common error is selecting the correct certificate file for the wrong operation.
Copying production settings into test
This can send test data to a live endpoint or produce confusing identity errors. Keep environments explicit.
Testing only the happy path
Retries, negative receipts, duplicate handling and certificate failures are operationally important. Test them safely before production.
Treating HTTP 200 as delivery
Check the MDN disposition, signature and MIC. Then check the business acknowledgment separately.
Leaving ownership in an email thread
Store the final agreed profile, contacts and activation evidence in a controlled record available to operations.
Go-live checklist
- [ ] Business documents and formats approved
- [ ] Test and production profiles separated
- [ ] AS2 IDs and endpoint URLs verified
- [ ] Certificate fingerprints independently confirmed
- [ ] Signing, encryption, compression and MIC algorithms matched
- [ ] MDN mode and signature behavior tested
- [ ] Inbound and outbound representative documents accepted
- [ ] Negative, retry and duplicate scenarios tested
- [ ] Monitoring and certificate alerts active
- [ ] Cutover, rollback and escalation owners confirmed
AS2Connection can provide the managed AS2 server and partner-facing endpoint while your team keeps the ERP or EDI workflow that already fits the business.
