# 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](https://edi-service.eu/en/knowledge/oftp2/). To connect, you need AS2 software, an AS2 ID, a certificate and an address that can be reached from the internet. ## 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](https://edi-service.eu/en/knowledge/edi-communication-protocols/). ## 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](https://edi-service.eu/en/knowledge/gln-edi-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](https://edi-service.eu/en/knowledge/edi-web-edi-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](https://edi-service.eu/en/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](https://edi-service.eu/en/enquiry/) ## Sources - RFC Editor: “RFC 4130: MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)”, (retrieved 16 October 2026) - RFC Editor: “RFC 3335: MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet”, (retrieved 16 October 2026) - OASIS: “AS4 Profile of ebMS 3.0 Version 1.0”, OASIS Standard of 23 January 2013, (retrieved 16 October 2026) - OpenPeppol: “Peppol AS4 Profile”, (retrieved 16 October 2026)