protocol operation icon

AS2 Protocol Operation

Version: latest

The AS2 Protocol operates between two B2B trading partners who have already configured security aspects (i.e. certificates) of each other. Although AS2 could be used to transmit any payload, the most common payloads included EDI (EDIFACT/X12 etc), XML, CSV, Fixed-Width, Text and other proprietary or custom file formats, and binary.

Certificate Management

Each trading partner typically exchanges public keys corresponding to their private keys. At each trading partner, the Trust (Certificate) Store contains the certificates of the other trusted trading partners, and optionally any Certification Authority (CA) root certificates. Many trading partners use self-signed certificates instead of CA signed certificates - unlike with SSL.

Each trading partner also maintains its private key and the corresponding public certificate within an Identity (Key) Store.

Before initiating B2B trading, each trading partner sends its public key as a X.509 Certificate encoded in PEM or DER format, to its other trading partners.

Sending Messages

The Sending Partners’ Line of Business (LOB) applications which require the exchange of EDI documents, will forward those documents to the AS2 infrastructure, also known as an AS2 Station. The AS2 station then determines the target trading partner and picks up corresponding information such as:

  • security level required when sending files to this partner,

  • MDN request type (sync/async), and

  • AS2 identifiers.

The sending AS2 station then computes a digital hash over the source payload files to be transmitted, creating an MD5 or SHA-1 digest, called the Message Integrity Check or MIC.

The original files are then merged into a multi-part message and then digitally signed using the Private Key of the sending station, whose public key (and certificate) will be available with the target recipient.

The multi-part message is then encrypted with the Public Key of the recipient trading partner, so that only that specific recipient who has the corresponding Private Key could decrypt the message.

The encrypted message is now transferred over the firewall-friendly HTTP/S protocol, through the Public Internet or private VPN link, along with other header information.

The EDI document file name(s) should be preserved during the transportation of the MIME message between the AS2 Station and the AS2 Partner. This will be accomplished by the use of the Content-Disposition MIME headers in the EDI MIME message.

as2 operation

Receiving Messages

Once the message reaches the target recipient trading partners’ AS2 station, it is decrypted using the partner’s Private Key.

The digital signature of the decrypted message is then verified against the list of trusted partner certificates, to ensure that:

  • the message has been signed by the claimed sending partner, and that

  • the message has not been altered in any way during the transmission.

Next, the MIC is computed again on the application level payload using the same algorithm as the sending partner. The calculated MIC is typically digitally signed by the receiving trading partner using its Private Key, and this acknowledgement sent back to the original sender as the Message Disposition Notice or MDN.

The original sending trading partner will compare the MIC value inside the received MDN with the already stored MIC value of the original message. The original sending trading partner will store the received MDN as a digital guarantee of a successful sending of the AS2 message to the receiving trading partner.

The recipient partner’s trading station should be able to enforce the filename preservation capability by the use of the Content-Disposition MIME header.

Local Station Configuration

The AS2 software used at your end is referred to as your Local AS2 Station. Setting up a local station will require the following information to be configured within your selected AS2 software system:

  • The local AS2 System Identifier

  • The publicly visible URL where your station is listening for new messages

  • The publicly visible URL where your station is listening for asynchronous MDN responses

  • Your preference on receiving an MDN

  • Your Private Key and Certificate

AS2 System Identifiers

AS2 System Identifiers are used to aid the receiving system in identifying the sending system. An AS2 system identifier, usually referred to as the AS2 ID, may be company-specific - such as Data Universal Numbering System (DUNS) numbers - or they may be simply identification strings agreed upon between the trading partners.

An AS2 ID is between 1-128 printable ASCII characters (except double quote or backslash), and is case sensitive. If a space is used, the AS2 identifier must be quoted.

Public URL

You must properly configure your publicly visible URL of the AS2 system, and send this URL to your partners. The URL must be visible through the Internet, and may differ from your local hostname of the machine where the AS2 software is configured.

If your organization has a firewall that only allows remote trading partners to connect to your system using an IP address communicated to you (a.k.a. whitelisted), you should ensure the network level configuration is performed, for your partners to be able to reach you.

Public URL for Asynchronous MDNs

If you wish to receive your MDNs asynchronously, you should configure your AS2 station to support it, and then communicate this URL to your partners via a Receipt-Delivery-Options header added to each AS2 message.

Private Key and Certificate

You must create a Public/Private Key pair to use AS2 security. Your Private Key is never revealed to any trading partners, but is used to digitally sign AS2 request messages or MDN responses, so that your trading partners can verify that:

  • they originated from you, and

  • they have not been altered during transit.

Your Public Key is shared with your trading partners as a X.509 certificate, so that your digital signatures can be verified. Your trading partners also may encrypt messages being sent to you using your Public Key/Certificate, so that they could only be decrypted by your corresponding Private Key - and hence cannot be read by third parties.

Unlike with SSL security, AS2 does not require a Certification Authority (CA) signed certificate to be trusted by trading partners. Hence, Key Pairs and Certificates are usually generated locally and self-signed, and then the certificate is distributed as a DER or PEM encoded file.

You could generate self-signed certificates using various tools or utility software applications. The Java Development Kit (JDK) includes a utility keytool which could be used as follows:

keytool -genkey -alias mycompany -keypass password -keyalg RSA -keysize 1024 \
    -dname "CN=My Company AS2,O=My Company,C=US" \
    -keystore mycompany.jks -storepass password -validity 3650

You can also use the openssl tool found on most Linux systems:

openssl req -x509 -nodes -newkey rsa:1024 -sha256 \
    -subj '/CN=My Company AS2/O=My Company/C=US' \
    -days 3650 -keyout selfsigned.key -out selfsigned.pem

Trading Partner Configuration

An AS2 message exchange takes place between two trading partners, who first establish an agreement to trade electronically. To communicate with each other, both organizations will require the following AS2 information properly configured on their AS2 Stations, about each other:

  • The AS2 system identifier of the other partner (counterparty)

  • Partners’ URL where AS2 messages should be sent

  • Partners’ digital certificate

  • Partners’ preference for synchronous vs asynchronous MDN

AS2 System Identifiers

These are simply another (the partner’s) perspective of the station AS2 identifiers described before.

Partner URL

A trading partner will inform its AS2 URL to other partners with whom it will trade over AS2. This is a normal HTTP or HTTPS URL (e.g. with optional HTTP authentication such as basic auth. Where such additional security is being used by the remote partner, necessary information will be communicated to you before trading begins. (e.g. Client certificates for two-way SSL, authentication credentials for HTTP basic/digest authentication, etc).

Some trading partners will also request your outgoing IP address for whitelisting on their firewall, as they may only allow known and authorized connections to their AS2 infrastructure which is otherwise open to the public Internet.

Partner URL for Asynchronous MDNs

A Partner may request that MDNs sent to it asynchronously, be sent to a different URL than its AS2 URL. The existence of an Async MDN URL depends on the trading partner, and sometimes may not be present if the trading partner requests only for synchronously issued MDNs.

Unlike the partner URL, this URL does not usually need to be pre-configured; instead it is required - by definition in the AS2 protocol - to be included in each individual AS2 message as a Receipt-Delivery-Options HTTP header.

Partners Digital Certificate

As Digital Signatures and Public Key Cryptography forms the secure basis of AS2 messaging, partners must exchange necessary certificates before trading begins. Unlike web site certificates used for SSL, digital certificates used for AS2 trading are often self-signed certificates. This means that the certificate is generated and signed by the same trading partner organization - unlike a certificate generated by an organization and signed by a publicly trusted Certificate Authority (CA) such as VeriSign, Thawte, GoDaddy, Comodo, etc.

Digital Certificates are also referred to as X.509 certificates based on the ITU-T standard for Public Key Infrastructure governing them. Certificates would be provided by a trading partner in a file, or as a blurb of base-64 encoded text (PEM). Certificate files will have one of the following extensions - with the binary DER encoded format, and the textual PEM encoded format, being widely used:

  • .pem (Privacy Enhanced Mail): Base-64 encoded DER certificate, enclosed between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- markers

  • .cer, .crt, .der - usually in binary DER form, but base-64 encoded certificates are common too (see .pem above)

  • .p12 - PKCS#12, may contain certificate(s) (public) and private keys (password protected)

  • .pfx - PFX, predecessor of PKCS#12 (usually contains data in PKCS#12 format, e.g., with PFX files generated in IIS)

You could list the contents of a certificate file using various tools and utility software applications. The Java development kit includes a utility keytool:

  • keytool -printcert -v -file certificate.pem

  • keytool -printcert -v -file certificate.der

Linux/Unix systems have a tool openssl which could be used as follows:

  • openssl x509 -in certificate.der -inform der -text -noout

  • openssl x509 -in certificate.pem -inform pem -text -noout

In this topic
In this topic