AS2 connection parameters are the values two trading partners exchange to create matching AS2 profiles. They identify both parties, define where messages are sent, select certificates and algorithms, and specify how delivery receipts are returned.
A connection can fail when one character differs between profiles, even if the network and certificates are healthy. Use this guide as a field-by-field reference and keep one approved parameter sheet for each test and production relationship.
Core AS2 parameter sheet
| Field | Example | Supplied by | Used for |
|---|---|---|---|
| Company/legal name | Example Manufacturing Ltd | Each party | Administrative identification |
| Environment | Test | Each party | Preventing test/production mix-ups |
| AS2 ID | EXAMPLE_AS2_TEST | Owner of the ID | AS2-From and AS2-To headers |
| Endpoint URL | https://as2.example.com/inbound | Receiver | Destination of AS2 POST requests |
| Port | 443 | Receiver | Network route when not implied by URL |
| Public certificate | example-test-signing.cer | Certificate owner | Signature verification or encryption |
| Certificate fingerprint | SHA-256 value | Certificate owner | Independent identity verification |
| Signing algorithm | SHA-256 | Receiver policy | Message signature compatibility |
| Encryption algorithm | AES-256 | Receiver policy | Message confidentiality compatibility |
| Compression | Enabled/disabled | Bilateral agreement | Payload packaging |
| MDN mode | Synchronous | Receiver/partner agreement | Receipt delivery route |
| Signed MDN | Required | Sender requirement | Receipt evidence |
| MIC algorithm | SHA-256 | Sender requirement | Integrity comparison in receipt |
| Content type | application/edi-x12 | Bilateral agreement | Payload interpretation |
| Timeout/retry | 120 seconds / controlled retry | Bilateral agreement | Uncertain-delivery handling |
Each party supplies its own identity, receiving endpoint and public certificate. For outbound configuration, your system uses the partner’s receiving values. For inbound configuration, it validates the partner against the values you have approved.
AS2 ID
An AS2 ID is the logical identifier used in AS2-From and AS2-To headers. It is not necessarily a domain, username, legal company name or certificate subject.
If you send as EXAMPLE_AS2_TEST, your partner must configure that exact value as the expected remote identity. Confirm:
- capitalization;
- spaces and punctuation;
- whether the value is quoted in the platform UI or wire header;
- distinct test and production IDs;
- whether one ID is shared across several connections.
Do not “correct” a partner’s spelling or infer an ID from its brand. Copy the approved logical value exactly.
AS2 endpoint URL and port
The endpoint is the full URL that receives AS2 HTTP POST requests. It contains:
- scheme: normally
https; - hostname;
- optional non-default port;
- path;
- sometimes a route or tenant identifier.
For https://as2.example.com:8443/receive, the port is 8443 and /receive is part of the required route. For standard HTTPS, port 443 is normally implied and does not need to be written separately.
AS2 does not mandate a universal port. Most internet deployments use HTTPS on 443, but the receiver publishes the authoritative value. A firewall rule for 443 will not help if the agreed endpoint uses 8443.
Confirm whether the receiver restricts source IP addresses, requires mutual TLS, uses a proxy or expects a specific Host header. These are network/TLS controls around AS2, not substitutes for AS2 message security.
Public certificates and fingerprints
Record each certificate’s purpose:
- verify messages signed by the partner;
- encrypt messages sent to the partner;
- verify signed MDNs;
- protect a TLS or mutual-TLS session.
One certificate may fill more than one role, but do not assume it. The TLS certificate served by the HTTPS endpoint is usually distinct from the AS2 message certificate.
Use the SHA-256 fingerprint, serial number and validity dates to identify a certificate. Verify the fingerprint through a trusted channel before import. See AS2 certificates explained for formats, exchange and rotation.
Signing algorithm
The sender signs with its private key and the receiver verifies with the corresponding public certificate. Both platforms must support the selected digest and signature combination.
The receiving partner normally states what it accepts. Store the choice per connection and test the exact production policy. If a platform offers deprecated algorithms for compatibility, do not use them unless a documented legacy requirement and security review justify it.
Encryption algorithm
The sender encrypts with the receiver’s public certificate. The receiver decrypts with the matching private key. Algorithm names and support differ between products, so use the values exposed by both platforms rather than translating labels by guesswork.
A decryption failure often points to the wrong partner certificate rather than the symmetric algorithm itself. Compare fingerprints before changing multiple settings.
Compression
AS2 can compress the payload as part of its MIME packaging. Both sides must agree whether it is enabled and support the same processing sequence. Compression can matter for large EDI batches, but it also adds another transformation to inspect during MIC or MIME troubleshooting.
Test representative file sizes. Do not enable compression on one side after go-live without coordinating the partner profile.
MDN mode
The MDN can be:
- synchronous: returned in the HTTP response to the message;
- asynchronous: sent later to a separate callback endpoint.
Also record whether the MDN must be signed and which MIC algorithms are accepted. An asynchronous MDN requires additional receiving parameters for the original sender: callback URL, AS2 identity, certificate policy and network access.
The AS2 MDN guide explains both flows and receipt validation.
Content type and payload conventions
AS2 carries the file but the parties still need to agree what the file is. Record:
- MIME content type;
- EDI standard and version;
- character encoding;
- filename convention and whether filename is significant;
- line endings where legacy systems care;
- multiple-document or batching rules;
- maximum size;
- whether the payload is already compressed or archived.
An AS2 MDN may be positive even when the downstream translator rejects the payload format. Test transport and business validation separately.
HTTP authentication and mutual TLS
Some endpoints require HTTP Basic authentication, an API-style credential, mutual TLS or source-IP allowlisting in addition to AS2 headers. Record these in a protected operational section rather than emailing passwords in the public parameter sheet.
AS2 IDs are message identities, not secret passwords. TLS client certificates are also different from AS2 signing and encryption certificates unless the partner explicitly reuses them.
Timeouts, retries and duplicates
Agree how long the sender waits for a synchronous MDN and when an asynchronous receipt becomes overdue. Define maximum retries, backoff and escalation.
The critical question is what happens after an uncertain result: the partner may have processed the message even though the sender did not receive its MDN. Retain the original Message-ID according to the product’s retry design and ensure downstream business processing detects duplicates.
Test and production example
| Parameter | Test | Production |
|---|---|---|
| Local AS2 ID | EXAMPLE_TEST | EXAMPLE_PROD |
| Partner AS2 ID | BUYER_TEST | BUYER_PROD |
| Partner endpoint | https://test.example/receive | https://as2.example/receive |
| Partner certificate fingerprint | Test SHA-256 fingerprint | Production SHA-256 fingerprint |
| MDN | Synchronous, signed | Synchronous, signed |
| Payload | Approved test document | Live EDI transaction |
Keep environment values on separate records or clearly separated sections. Copying a test certificate into the production row is a common and avoidable outage cause.
Errors mapped to parameters
| Symptom | Parameters to verify first |
|---|---|
| Connection refused or timeout | URL, port, DNS, allowlist, firewall |
| HTTP 404/405 | URL path and method route |
| Unknown partner or AS2 ID | AS2-From, AS2-To, quoting |
| Signature validation failure | Sender signing certificate, algorithm |
| Decryption failure | Receiver encryption certificate/private key |
| MDN missing | Sync/async mode, callback URL, timeout |
| MDN signature invalid | Receipt certificate, trust, algorithm |
| MIC mismatch | MIC algorithm, MIME/compression processing |
| EDI rejected after positive MDN | Content type, standard, mapping and business rules |
Change one variable at a time and retain the raw error evidence. Randomly toggling several algorithms can hide the original cause and create a configuration that nobody can reproduce.
Parameter handoff checklist
- [ ] Legal and technical contacts identified
- [ ] Test and production values separated
- [ ] AS2 IDs copied exactly
- [ ] Complete URLs and ports confirmed
- [ ] Public certificate purposes labelled
- [ ] SHA-256 fingerprints verified independently
- [ ] Signing, encryption and MIC algorithms matched
- [ ] MDN mode and signature requirement matched
- [ ] Content type, EDI version and filename rules recorded
- [ ] Timeouts, retries and duplicates agreed
- [ ] Cutover time zone and rollback contacts recorded
Once the sheet is approved, follow how to set up an AS2 connection and execute the AS2 test plan before production.
Technical reference
The authoritative protocol reference is RFC 4130. It defines AS2 headers, HTTP transport, MIME/S/MIME packaging and MDN request behavior. A partner sheet selects the compatible options used for one bilateral implementation; it does not replace the standard.
