Setting up AS2 with a trading partner in Boomi

The retailer’s EDI team sends you a form: “Please provide your AS2 ID, AS2 URL, public certificate and MDN preferences.” If AS2 is new to you, half of those terms are unclear and the other half sound like they could go wrong in subtle ways. They can. This article explains what AS2 actually does, what you exchange with a partner and why, and then walks through the setup in Boomi, from certificates to the first successful MDN.

Why not just email or SFTP?

Email is unreliable and insecure for business documents. SFTP is secure in transit and widely used, but it doesn’t by itself tell the sender that the receiver got the file intact, and it doesn’t give either side legal proof of what was sent. For large retailers that exchange thousands of orders and invoices a day, that proof matters: disputes about “the order we never received” are expensive.

How AS2 works

AS2 (Applicability Statement 2) sends a document over HTTP or HTTPS and adds three things:

Signing. The sender signs the message with its private key. The receiver verifies the signature with the sender’s public certificate, so it knows who sent it and that nothing was changed.
Encryption. The sender encrypts the message with the receiver’s public certificate. Only the receiver, with its private key, can decrypt it.
MDN (Message Disposition Notification). The receiver returns a receipt, usually signed, that includes a hash of what it received. This proves delivery and gives both sides non-repudiation.

MDNs can be synchronous (returned in the same HTTP connection) or asynchronous (sent later to a URL the sender provides). Synchronous is simpler and common for normal file sizes; asynchronous helps with large files or slow processing.

You ──[signed with your key, encrypted with partner's cert]──► Partner
You ◄──────────[signed MDN: "received, hash = ..."]────────── Partner

What you exchange with the partner

Item	You give the partner	The partner gives you
AS2 ID	Your AS2 identifier	Their AS2 identifier
URL	The URL where you receive AS2	The URL where they receive AS2
Certificate	Your public certificate only	Their public certificate
Algorithms	Agreed signing and encryption algorithms (for example SHA-256, AES)
MDN	Sync or async, signed or not	Their requirements
Network	Your public IP addresses (for their allowlist)	Their IP addresses

Never send your private key to anyone. If a partner asks for a “.pfx” or “.p12” file, they are asking for the wrong thing.

Setting it up in Boomi

In Boomi, AS2 is configured in three places: the runtime that receives AS2 messages, Certificate components for the keys, and the Trading Partner components that hold the AS2 settings for each side. Exact labels differ between releases and between the classic trading partner screens and the newer B2B/EDI Management experience, so use the steps below as a guide to the order of work.

Step 1: Prepare the runtime for inbound AS2

To receive messages, the partner must be able to reach an AS2 endpoint on your Boomi runtime.

Decide where you receive: a local Atom or Molecule in your network, or a Boomi-hosted runtime cloud. Check that the runtime type you choose supports inbound AS2, and how its public URL is formed.
For a local runtime, configure the runtime’s AS2 shared server settings (port, base URL, TLS certificate), and make the endpoint reachable from the internet, typically through a reverse proxy or firewall rule, restricted to the partner’s IP addresses.
Use HTTPS with a certificate from a public certificate authority for the transport. This TLS certificate is separate from the AS2 signing and encryption certificates.

Step 2: Create or obtain your AS2 certificate

Generate a key pair for AS2. Many companies use a certificate from a CA; others use a self-signed certificate, which most partners accept for AS2 signing and encryption. Ask the partner which they require.
Import your private key (a .p12/.pfx file with its password) into Boomi as a Certificate component. It will be used to sign outgoing messages and decrypt incoming ones.
Export the public part as a .cer file and send it to the partner.
Import the partner’s public certificate as another Certificate component.

Write down both certificates’ expiry dates. More on that below. For handling keys and passwords safely in general, see Managing secrets and certificates in Boomi.

Step 3: Configure your company’s AS2 settings

In your company’s Trading Partner component (the one with the “my company” classification), on the communication settings for AS2:

Set your AS2 ID (agree it with the partner; many companies use their company name or GLN).
Select your private-key certificate for signing and decryption.
Set how you send MDNs for messages you receive.

Step 4: Configure the partner’s AS2 settings

In the partner’s Trading Partner component, on the AS2 communication settings:

Enter the partner’s AS2 URL and AS2 ID.
Select the partner’s public certificate for encryption and signature verification.
Choose the agreed signing and encryption algorithms.
Set the MDN options: request an MDN, request it signed, and choose synchronous or asynchronous as agreed.

Step 5: Test connectivity

Test in small steps, so that when something fails you know which layer it is:

Network. Can the partner reach your URL, and can you reach theirs? A simple HTTPS request (expecting an error response, not a timeout) is enough.
Outbound test file. Send a small test document from a process ending in a Trading Partner shape (or a connector shape with the AS2 client, depending on how you send). Check that you receive a valid MDN and that process reporting shows it.
Inbound test file. Ask the partner to send a test file to you. Check that it is decrypted, the signature is verified, an MDN goes back, and the document reaches your process.

Typical first-time errors and their usual causes:

Symptom	Usual cause
Timeout	Firewall, IP allowlist or wrong port
“Unknown AS2 ID” / rejected	AS2 IDs swapped or mistyped (they are case-sensitive)
Decryption failed	Partner encrypted with the wrong (old) certificate
Signature verification failed	Wrong partner certificate imported, or algorithm mismatch
MDN not received	Async MDN URL unreachable, or MDN not requested

Step 6: Connect to the real documents

Once the connection works, link it to the business flow: inbound purchase orders into the ERP, as described in Receiving purchase orders via EDI and creating sales orders with Boomi, and outbound order responses, despatch advices and invoices.

Go-live checklist

AS2 IDs, URLs and certificates confirmed in writing by both sides
Production and test connections kept separate (different URLs and, ideally, different AS2 IDs)
Inbound endpoint restricted to the partner’s IP addresses
Signed MDNs requested and stored for non-repudiation
Alerts for failed transmissions and missing MDNs
Certificate expiry dates in a shared calendar, with a reminder at least a month before
Contact details of the partner’s EDI support team
A test file exchanged on the production connection before the first real document

Renewing certificates without an outage

Certificates expire, usually after one to three years, and an expired certificate stops AS2 traffic instantly. Plan the renewal: generate the new key pair well in advance, send the new public certificate to the partner, agree a switch-over date, and if the partner supports it, accept both old and new certificates for a short overlap. Test with a file right after the switch.

Summary

AS2 combines signing, encryption and signed receipts into a transport that both sides can trust and prove. Most of the work is in the exchange: the right IDs, the right certificates and agreed MDN settings. In Boomi, those settings live in certificate and trading partner components, and the runtime receives the messages. For how AS2 fits next to SFTP, VANs and the EDI standards, see our guide B2B integration and EDI: what it is and when you need it.