# Jak działa protokół AS2? Protokół AS2 (Applicability Statement 2) to sposób, w jaki dwie firmy wymieniają pliki EDI bezpośrednio przez internet, z podpisem, szyfrowaniem i potwierdzeniem odbioru. Opisuje go RFC 4130 organizacji IETF, a jako transport służy HTTP. AS2 nie jest związany z żadną branżą; w motoryzacji wymagany jest natomiast zwykle [OFTP2](https://edi-service.eu/pl/baza-wiedzy/oftp2/). Do integracji potrzebne są oprogramowanie AS2, AS2 ID, certyfikat i adres osiągalny z internetu. ## Jak pracuje protokół AS2 RFC 4130 ukazał się w lipcu 2005 roku jako „Proposed Standard”. Poprzednik AS1 (RFC 3335) przesyłał pliki e-mailem; AS2 przenosi tę samą zasadę na HTTP. Transmisja przebiega tak: 1. Oprogramowanie pakuje plik EDI, na przykład fakturę EDIFACT, w komunikat MIME. 2. Podpisuje komunikat Państwa kluczem prywatnym i szyfruje go publicznym certyfikatem partnera (S/MIME, ta sama metoda co w bezpiecznej poczcie e-mail). 3. Wysyła komunikat metodą HTTP POST na wcześniej uzgodniony adres partnera, na przykład `https://as2.partner.example/as2`. 4. Oprogramowanie partnera odszyfrowuje komunikat, sprawdza podpis i odsyła potwierdzenie, czyli MDN. Czy połączenie jest dodatkowo zabezpieczone przez TLS (czyli HTTPS zamiast HTTP), ustalają partnerzy. Sam plik jest chroniony podpisem i szyfrowaniem, nawet jeśli połączenie nie używa TLS. Czy partner dodatkowo wymaga HTTPS, podaje jego specyfikacja. AS2 to metoda punkt-punkt. Nie ma pośrednika jak w sieci VAN (Value Added Network), pliki idą bezpośrednio z serwera na serwer. Porównanie z innymi kanałami znajdą Państwo na stronie [Kanały transmisji EDI](https://edi-service.eu/pl/baza-wiedzy/kanaly-transmisji-edi/). ## AS2 ID i profil partnera Każda strona ma AS2 ID. Znajduje się on w nagłówkach HTTP `AS2-From` i `AS2-To` i mówi, od kogo pochodzi komunikat i do kogo jest skierowany. Według RFC 4130 AS2 ID ma od 1 do 128 drukowalnych znaków ASCII, a wielkość liter ma znaczenie. Jako wartość nadaje się istniejący numer; RFC 4130 podaje jako przykład numer DUNS, możliwy jest też GLN. Więcej na stronie [GLN i inne identyfikatory](https://edi-service.eu/pl/baza-wiedzy/numer-gln-identyfikatory/). Pełny profil partnera AS2 zawiera: | Dane | Przykład (fikcyjny) | |---|---| | własny AS2 ID i AS2 ID partnera | `9520000000011` i `PARTNERAS2` | | adres (URL) partnera | `https://as2.partner.example/as2` | | certyfikat partnera do szyfrowania i weryfikacji podpisu | plik `partner.cer` | | algorytmy podpisu i szyfrowania | na przykład SHA-256 i AES | | MDN: podpisane lub nie, synchroniczne lub asynchroniczne | podpisane, synchroniczne | | adres testowy i produkcyjny | często dwa osobne adresy URL | Wartości są podane w specyfikacji EDI klienta lub w jego formularzu rejestracyjnym. Jeśli czegoś brakuje, lepiej zapytać, niż zgadywać. ## Wymiana certyfikatów AS2 używa certyfikatów X.509. Według RFC 4130 partnerzy mogą używać certyfikatów wystawionych samodzielnie; urząd certyfikacji nie jest wymagany. W praktyce każda strona generuje parę kluczy i wysyła drugiej certyfikat publiczny, zwykle e-mailem lub przez portal. Klucz prywatny zawsze zostaje u Państwa. Certyfikaty wygasają. Nowe certyfikaty trzeba wymienić odpowiednio wcześnie przed datą wygaśnięcia, w przeciwnym razie weryfikacja podpisu lub odszyfrowanie się nie powiodą. Warto zaplanować na to stały termin i monitorowanie. ## MDN jako potwierdzenie, synchroniczne lub asynchroniczne MDN (Message Disposition Notification) to potwierdzenie odbioru. Jeśli jest podpisane, zawiera sumę kontrolną odebranego komunikatu (MIC, Message Integrity Check). Pozwala to wykazać, że dokładnie ten plik dotarł bez zmian. W wariancie synchronicznym MDN wraca jako odpowiedź na to samo wywołanie HTTP. To proste, bo nie jest potrzebne drugie połączenie. Przy bardzo dużych plikach połączenie może jednak przekroczyć limit czasu, zanim odbiorca skończy. W wariancie asynchronicznym odbiorca od razu potwierdza wywołanie HTTP, a MDN wysyła później osobnym połączeniem na adres, który nadawca podaje w nagłówku `Receipt-Delivery-Option`. Wymaga to, by także nadawca był osiągalny z internetu. ## Typowe błędy w integracjach AS2 - Błędnie zapisany AS2 ID: ponieważ wielkość liter ma znaczenie, `Partneras2` to inny identyfikator niż `PARTNERAS2`. - Niewłaściwy lub wygasły certyfikat: partner ma nowy certyfikat, a oprogramowanie używa jeszcze starego. - Zapora: adres nie jest osiągalny z internetu albo port partnera jest zablokowany dla ruchu wychodzącego. - Niezgodny MIC: algorytmy po obu stronach się nie zgadzają, MDN zostaje odrzucone jako nieważne. - Asynchroniczne MDN nie dociera, bo adres zwrotny jest wewnętrzny lub blokowany. - Pomylone środowiska testowe i produkcyjne: pliki testowe trafiają do systemu produkcyjnego partnera lub odwrotnie. Większość tych błędów wychodzi przy pierwszym teście połączenia. Dlatego przed każdym uruchomieniem produkcyjnym odbywa się test z plikami testowymi, aż plik i MDN będą poprawnie przechodzić w obu kierunkach. ## Czym AS4 różni się od AS2 AS4 to młodsza metoda organizacji normalizacyjnej OASIS, od 23 stycznia 2013 roku standard OASIS. Według standardu powstała, by kontynuować sukces AS2. W porównaniu z AS2 OASIS wymienia trzy nowości: AS4 pasuje do standardów usług sieciowych (ebMS 3.0 na bazie SOAP), komunikaty można pobierać („pull”), a potwierdzenia są wbudowane na stałe. Ważnym obszarem zastosowania jest Peppol, sieć służąca między innymi do faktur elektronicznych: według specyfikacji Peppol wymiana między punktami dostępowymi (Access Points) odbywa się przez AS4. Co to oznacza dla e-faktur, wyjaśnia strona [EDI, Web-EDI i e-faktura](https://edi-service.eu/pl/baza-wiedzy/edi-web-edi-e-faktura/). ## AS2 w edi-service.eu AS2 należy w edi-service.eu do kanałów transmisji, obok OFTP2, SFTP, HTTPS i e-maila, w obu kierunkach z MDN. Oprogramowanie działa na Państwa własnym serwerze; serwer potrzebuje do tego stałego adresu i przychodzącego portu HTTPS. Własnego dostępu do Peppol (AS4) nie oferujemy. Co obejmuje cena, wyjaśniają [najczęstsze pytania](https://edi-service.eu/pl/faq/). ## Najczęstsze pytania ### Czym różni się AS2 od SFTP? AS2 podpisuje i szyfruje każdy plik i w postaci MDN dostarcza potwierdzenie odbioru. SFTP przesyła pliki przez szyfrowane połączenie SSH, ale nie daje potwierdzenia na poziomie biznesowym. Który kanał Państwo stosują, ustala zwykle klient. ### Czy do AS2 potrzebny jest kupiony certyfikat? Niekoniecznie. RFC 4130 dopuszcza certyfikaty wystawione samodzielnie. Niektórzy partnerzy wymagają jednak certyfikatu od określonego urzędu certyfikacji; podają to wtedy w swojej specyfikacji. ### Lepsze jest MDN synchroniczne czy asynchroniczne? Synchroniczne jest prostsze i wystarcza przy typowych rozmiarach plików. Asynchroniczne opłaca się przy dużych plikach lub długim przetwarzaniu, ale wymaga, by także Państwa system był osiągalny z zewnątrz. Zwykle wariant określa partner. ### Czy AS2 jest przestarzały, skoro istnieje AS4? Nie. RFC 4130 obowiązuje bez zmian, a AS2 pozostaje w użyciu przy bezpośrednich połączeniach między partnerami handlowymi. AS4 spotkają Państwo głównie w sieciach takich jak Peppol. Której metody potrzebują Państwo, mówi specyfikacja partnera. Mają Państwo specyfikację AS2 od klienta i chcą wiedzieć, czy integracja pasuje do edi-service.eu? [Wyślij zapytanie](https://edi-service.eu/pl/zapytanie/) ## Źródła - RFC Editor: „RFC 4130: MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)”, (dostęp 16.10.2026) - RFC Editor: „RFC 3335: MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet”, (dostęp 16.10.2026) - OASIS: „AS4 Profile of ebMS 3.0 Version 1.0”, standard OASIS z 23.01.2013, (dostęp 16.10.2026) - OpenPeppol: „Peppol AS4 Profile”, (dostęp 16.10.2026)