EN

Home / Knowledge / AS2

How does the AS2 protocol work?

The AS2 protocol (Applicability Statement 2) is a method that lets two companies exchange EDI files directly over the internet, signed, encrypted and with an acknowledgement of receipt. It is described in the IETF's RFC 4130 and uses HTTP as transport. AS2 is not tied to any industry; the automotive industry, by contrast, usually asks for OFTP2. To connect, you need AS2 software, an AS2 ID, a certificate and an address that can be reached from the internet.

Last updated 18 October 2026 · fokus it solutions, Jens Musleh

How the AS2 protocol works

RFC 4130 was published in July 2005 as a “Proposed Standard”. Its predecessor AS1 (RFC 3335) transferred files by email; AS2 applies the same principle to HTTP. A transfer works like this:

  1. Your software packages the EDI file, such as an EDIFACT invoice, into a MIME message.
  2. It signs the message with your private key and encrypts it with the partner's public certificate (S/MIME, the same method as for secure email).
  3. It sends the message by HTTP POST to an address agreed with the partner in advance, for example https://as2.partner.example/as2.
  4. The partner's software decrypts it, checks the signature and sends back a receipt, the MDN.

Whether the connection is additionally secured with TLS (that is, HTTPS instead of HTTP) is decided by the partners. The file itself is protected by signature and encryption even if the connection does not use TLS. Whether your partner also requires HTTPS is stated in its implementation guide.

AS2 is a point-to-point method. There is no intermediary as with a VAN (value-added network); the files go directly from server to server. You will find a comparison with other methods under EDI transmission methods.

AS2 ID and partner profile

Each side has an AS2 ID. It appears in the HTTP headers AS2-From and AS2-To and states who the message comes from and who it is going to. According to RFC 4130, the AS2 ID is 1 to 128 printable ASCII characters long, and it is case-sensitive. An existing number makes a good value; RFC 4130 gives the DUNS number as an example, and the GLN is also possible. More on this under GLN and other identifiers.

A complete AS2 partner profile contains:

Item Example (fictitious)
your own AS2 ID and the partner's 9520000000011 and PARTNERAS2
the partner's address (URL) https://as2.partner.example/as2
the partner's certificate for encryption and signature verification file partner.cer
algorithms for signing and encryption for example SHA-256 and AES
MDN: signed or not, synchronous or asynchronous signed, synchronous
test address and production address often two separate URLs

The values are in your customer's EDI implementation guide or its registration form. If any information is missing, ask rather than guess.

Exchanging certificates

AS2 uses X.509 certificates. According to RFC 4130, the partners may use self-signed certificates; a certification authority is not mandatory. In practice, each side generates a key pair and sends the other its public certificate, usually by email or via a portal. The private key always stays with you.

Certificates expire. New certificates must be exchanged in good time before the expiry date; otherwise signature verification or decryption fails. Plan a fixed date and monitoring for this.

The MDN as a receipt, synchronous or asynchronous

The MDN (Message Disposition Notification) is the acknowledgement of receipt. If it is signed, it contains a check value for the message received (MIC, Message Integrity Check). This lets you prove that exactly this file arrived unchanged.

With the synchronous variant, the MDN comes back as the response to the same HTTP request. This is simple, because no second connection is needed. With very large files, however, the connection can time out before the recipient has finished.

With the asynchronous variant, the recipient confirms the HTTP request immediately and sends the MDN later over a separate connection to an address the sender gives in the Receipt-Delivery-Option header. For this, the sender must also be reachable from the internet.

Typical errors in AS2 connections

  • AS2 ID misspelt: because it is case-sensitive, Partneras2 is a different ID from PARTNERAS2.
  • Wrong or expired certificate: the partner has a new certificate, but your software is still using the old one.
  • Firewall: the address cannot be reached from the internet, or the partner's port is blocked for outbound traffic.
  • MIC does not match: the algorithms on the two sides do not match, and the MDN is rejected as invalid.
  • The asynchronous MDN does not arrive because the return address is internal or blocked.
  • Test and production mixed up: test files end up in the partner's live system or the other way round.

Most of these errors show up in the first connection test. That is why every go-live is preceded by a test with test files until the file and MDN run cleanly in both directions.

How AS4 differs from AS2

AS4 is a newer method from the standards organisation OASIS and has been an OASIS Standard since 23 January 2013. According to the standard, it was created to build on the success of AS2. Compared with AS2, OASIS names three new features: AS4 fits the web services standards (ebMS 3.0 based on SOAP), messages can be collected (“pull”), and receipts are built in. One important area of use is Peppol, a network for electronic invoices among other things: according to the Peppol specification, exchange between access points runs over AS4. What this means for e-invoices is explained in EDI, web EDI and e-invoicing.

AS2 with edi-service.eu

With edi-service.eu, AS2 is one of the transmission methods, alongside OFTP2, SFTP, HTTPS and email, inbound and outbound with MDN. The software runs on your own server, which therefore needs a fixed address and an inbound HTTPS port. We do not offer our own Peppol access (AS4). What is included in the price is set out in the FAQ.

Frequently asked questions

What is the difference between AS2 and SFTP?

AS2 signs and encrypts every file and provides an acknowledgement of receipt with the MDN. SFTP transfers files over an encrypted SSH connection, with no business-level receipt. Which method you use is usually set by your customer.

Do I need a purchased certificate for AS2?

Not necessarily. RFC 4130 allows self-signed certificates. Some partners, however, require a certificate from a particular certification authority; this is then stated in their implementation guide.

Is a synchronous or an asynchronous MDN better?

Synchronous is simpler and is enough for normal file sizes. Asynchronous is worthwhile for large files or long processing times, but requires your system to be reachable from outside as well. Usually the partner specifies the variant.

Is AS2 outdated now that AS4 exists?

No. RFC 4130 still applies unchanged, and AS2 remains in use for direct connections between trading partners. You will mainly come across AS4 in networks such as Peppol. Your partner's implementation guide tells you which method you need.

Do you have an AS2 implementation guide from your customer and want to know whether the connection is a good fit for edi-service.eu? Send an enquiry

Sources

Send an enquiry · FAQ · All knowledge pages