# Wie funktioniert das AS2 Protokoll? Das AS2 Protokoll (Applicability Statement 2) ist ein Verfahren, mit dem zwei Firmen EDI-Dateien direkt über das Internet austauschen, signiert, verschlüsselt und mit Empfangsquittung. Es ist in RFC 4130 der IETF beschrieben und nutzt HTTP als Transport. AS2 ist an keine Branche gebunden; in der Automobilindustrie ist dagegen meist [OFTP2](https://edi-service.eu/wissen/oftp2/) gefragt. Für die Anbindung brauchen Sie eine AS2-Software, eine AS2-ID, ein Zertifikat und eine aus dem Internet erreichbare Adresse. ## Wie das AS2 Protokoll arbeitet RFC 4130 erschien im Juli 2005 als „Proposed Standard“. Der Vorgänger AS1 (RFC 3335) übertrug Dateien per E-Mail; AS2 legt dasselbe Prinzip auf HTTP um. Eine Übertragung läuft so: 1. Ihre Software verpackt die EDI-Datei, etwa eine EDIFACT-Rechnung, in eine MIME-Nachricht. 2. Sie signiert die Nachricht mit Ihrem privaten Schlüssel und verschlüsselt sie mit dem öffentlichen Zertifikat des Partners (S/MIME, dasselbe Verfahren wie bei sicherer E-Mail). 3. Sie schickt die Nachricht per HTTP POST an eine vorher vereinbarte Adresse des Partners, zum Beispiel `https://as2.partner.example/as2`. 4. Die Software des Partners entschlüsselt, prüft die Signatur und schickt eine Quittung zurück, die MDN. Ob die Verbindung zusätzlich per TLS gesichert ist (also HTTPS statt HTTP), legen die Partner fest. Die Datei selbst ist durch Signatur und Verschlüsselung geschützt, auch wenn die Verbindung kein TLS nutzt. Ob Ihr Partner zusätzlich HTTPS verlangt, steht in seinem Leitfaden. AS2 ist ein Punkt-zu-Punkt-Verfahren. Es gibt keinen Vermittler wie bei einem VAN (Value Added Network), die Dateien gehen direkt von Server zu Server. Einen Vergleich mit anderen Wegen finden Sie unter [EDI-Übertragungswege](https://edi-service.eu/wissen/edi-uebertragungswege/). ## AS2-ID und Partnerprofil Jede Seite hat eine AS2-ID. Sie steht in den HTTP-Kopfzeilen `AS2-From` und `AS2-To` und sagt, von wem die Nachricht kommt und an wen sie geht. Laut RFC 4130 ist die AS2-ID 1 bis 128 druckbare ASCII-Zeichen lang, und Groß- und Kleinschreibung zählt. Als Wert eignet sich eine bestehende Nummer; RFC 4130 nennt als Beispiel die DUNS-Nummer, möglich ist auch die GLN. Mehr dazu unter [GLN und andere Kennungen](https://edi-service.eu/wissen/gln-kennungen/). Ein vollständiges Partnerprofil für AS2 enthält: | Angabe | Beispiel (fiktiv) | |---|---| | eigene AS2-ID und die des Partners | `9520000000011` und `PARTNERAS2` | | Adresse (URL) des Partners | `https://as2.partner.example/as2` | | Zertifikat des Partners für Verschlüsselung und Signaturprüfung | Datei `partner.cer` | | Algorithmen für Signatur und Verschlüsselung | etwa SHA-256 und AES | | MDN: signiert oder nicht, synchron oder asynchron | signiert, synchron | | Testadresse und Produktivadresse | oft zwei getrennte URLs | Die Werte stehen im EDI-Leitfaden Ihres Kunden oder in seinem Anmeldeformular. Fehlt eine Angabe, fragen Sie nach, statt sie zu raten. ## Zertifikate austauschen AS2 nutzt X.509-Zertifikate. Laut RFC 4130 dürfen die Partner selbst ausgestellte Zertifikate verwenden; eine Zertifizierungsstelle ist nicht vorgeschrieben. In der Praxis erzeugt jede Seite ein Schlüsselpaar und schickt der anderen das öffentliche Zertifikat, meist per E-Mail oder über ein Portal. Der private Schlüssel bleibt immer bei Ihnen. Zertifikate laufen ab. Neue Zertifikate müssen rechtzeitig vor dem Ablaufdatum ausgetauscht werden, sonst scheitern Signaturprüfung oder Entschlüsselung. Planen Sie dafür einen festen Termin und eine Überwachung ein. ## Die MDN als Quittung, synchron oder asynchron Die MDN (Message Disposition Notification) ist die Empfangsbestätigung. Ist sie signiert, enthält sie einen Prüfwert über die empfangene Nachricht (MIC, Message Integrity Check). Damit können Sie belegen, dass genau diese Datei unverändert angekommen ist. Bei der synchronen Variante kommt die MDN als Antwort auf denselben HTTP-Aufruf zurück. Das ist einfach, weil keine zweite Verbindung nötig ist. Bei sehr großen Dateien kann die Verbindung aber in eine Zeitüberschreitung laufen, bevor der Empfänger fertig ist. Bei der asynchronen Variante bestätigt der Empfänger den HTTP-Aufruf sofort und schickt die MDN später über eine eigene Verbindung an eine Adresse, die der Absender in der Kopfzeile `Receipt-Delivery-Option` angibt. Dafür muss auch der Absender aus dem Internet erreichbar sein. ## Typische Fehler bei AS2-Anbindungen - AS2-ID falsch geschrieben: Weil Groß- und Kleinschreibung zählt, ist `Partneras2` eine andere ID als `PARTNERAS2`. - Falsches oder abgelaufenes Zertifikat: Der Partner hat ein neues Zertifikat, Ihre Software nutzt noch das alte. - Firewall: Die Adresse ist aus dem Internet nicht erreichbar, oder der Port des Partners ist ausgehend gesperrt. - MIC passt nicht: Die Algorithmen auf beiden Seiten stimmen nicht überein, die MDN wird als ungültig verworfen. - Asynchrone MDN kommt nicht an, weil die Rückadresse intern ist oder geblockt wird. - Test und Produktion vertauscht: Testdateien landen im Echtsystem des Partners oder umgekehrt. Die meisten dieser Fehler fallen beim ersten Verbindungstest auf. Deshalb steht vor jedem Echtbetrieb ein Test mit Testdateien, bis Datei und MDN in beide Richtungen sauber laufen. ## Was AS4 von AS2 unterscheidet AS4 ist ein jüngeres Verfahren der Normungsorganisation OASIS, seit dem 23. Januar 2013 OASIS-Standard. Laut Standard entstand es, um den Erfolg von AS2 aufzugreifen. Gegenüber AS2 nennt OASIS drei Neuerungen: AS4 passt zu den Web-Service-Standards (ebMS 3.0 auf Basis von SOAP), Nachrichten lassen sich abholen („Pull“), und Quittungen sind fest eingebaut. Ein wichtiges Einsatzfeld ist Peppol, ein Netz unter anderem für elektronische Rechnungen: Laut Peppol-Spezifikation läuft der Austausch zwischen den Zugangspunkten (Access Points) über AS4. Was das für E-Rechnungen bedeutet, erklärt [EDI, Web-EDI und E-Rechnung](https://edi-service.eu/wissen/edi-web-edi-e-rechnung/). ## AS2 bei edi-service.eu AS2 gehört bei edi-service.eu zu den Übertragungswegen, neben OFTP2, SFTP, HTTPS und E-Mail, eingehend und ausgehend mit MDN. Die Software läuft auf Ihrem eigenen Server; dafür braucht er eine feste Adresse und einen eingehenden HTTPS-Port. Einen eigenen Peppol-Zugang (AS4) bieten wir nicht an. Was im Preis enthalten ist, steht in den [häufigen Fragen](https://edi-service.eu/faq/). ## Häufige Fragen ### Was ist der Unterschied zwischen AS2 und SFTP? AS2 signiert und verschlüsselt jede Datei und liefert mit der MDN eine Empfangsquittung. SFTP überträgt Dateien über eine verschlüsselte SSH-Verbindung, eine fachliche Quittung gibt es dabei nicht. Welchen Weg Sie nutzen, legt meist Ihr Kunde fest. ### Brauche ich für AS2 ein gekauftes Zertifikat? Nicht unbedingt. RFC 4130 erlaubt selbst ausgestellte Zertifikate. Manche Partner verlangen aber ein Zertifikat einer bestimmten Zertifizierungsstelle; das steht dann in ihrem Leitfaden. ### Ist eine synchrone oder eine asynchrone MDN besser? Synchron ist einfacher und reicht bei üblichen Dateigrößen. Asynchron lohnt sich bei großen Dateien oder langer Verarbeitung, setzt aber voraus, dass auch Ihr System von außen erreichbar ist. Meist gibt der Partner die Variante vor. ### Ist AS2 veraltet, weil es AS4 gibt? Nein. RFC 4130 gilt unverändert, und AS2 bleibt für direkte Verbindungen zwischen Handelspartnern im Einsatz. AS4 begegnet Ihnen vor allem in Netzen wie Peppol. Welches Verfahren Sie brauchen, sagt Ihnen der Leitfaden Ihres Partners. Sie haben einen AS2-Leitfaden Ihres Kunden und wollen wissen, ob die Anbindung zu edi-service.eu passt? [Anfrage stellen](https://edi-service.eu/anfrage/) ## Quellen - RFC Editor: „RFC 4130: MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)“, (abgerufen 16.10.2026) - RFC Editor: „RFC 3335: MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet“, (abgerufen 16.10.2026) - OASIS: „AS4 Profile of ebMS 3.0 Version 1.0“, OASIS Standard vom 23.01.2013, (abgerufen 16.10.2026) - OpenPeppol: „Peppol AS4 Profile“, (abgerufen 16.10.2026)