protocol operation icon

AS2 Protocol Operation

Version: latest

The AS2 Protocol operates between two B2B trading partners who has 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 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 of it within an `Identity [Key] Store'. Before initiating B2B trading, each trading partner sends its 'Public Key' as a X509 Certificate encoded in PEM or DER format, to its other trading partners.

Sending Messages

The Sending Partners’ Line of Business (LOB) applications which requires 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 etc. The sending AS2 station then computes a digital hash over the source payload files to be transmitted, creating a 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 the MIC code, and other header information. The EDI document file name(s) should be preserved during the transportation of MIME message between AS2Station and AS2Partner. This will be accomplished by the use of the Content-Disposition MIME header of EDI MIME message.

as2 operation

Receiving Messages

Once the message reaches the target recipient trading partners’ AS2 station, its decrypted using the partners 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, and the received MIC compared with the senders’ claimed MIC. The verified 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 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 file name 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 to reach your AS2 station for new messages

  • The publicly visible URL to reach your AS2 station for asynchronous MDN responses

  • Your preference on a 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. This would the URL 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, 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 as well.

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 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 with your Public Key/Certificate, and thus they could only be decrypted by your corresponding Private Key.

Unlike with SSL security, AS2 does not require a Certification Authority (CA) signed certificate to be trusted by your 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 certificate. You could generate self-signed certificates using various tools or utility software applications. The Java development kit 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

Trading Partner Configuration

An AS2 message exchange takes place between two trading partners, who first establishes 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 partner

  • Partners’ URL where AS2 messages should be sent

  • Partners’ URL where asynchronous MDN receipts should be sent

  • Partners’ digital certificate

  • Partners’ preference for Synchronous or Asynchronous MDN

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.

Partner URL

A trading partner will inform its AS2 URL to other partners it will trade over AS2. This is a normal HTTP/S URL (e.g. http://as2.partner1.com/as2/receiver) This URL maybe an HTTP URL or HTTPS URL, with optional HTTP authentication. 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 2-way SSL, authentication credentials for HTTP basic/digest authentication etc). Some trading partners will also request your outgoing IP address, 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.

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 sometimes 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 Base64 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) Base64 encoded DER certificate, enclosed between "—–BEGIN CERTIFICATE—–" and "—–END CERTIFICATE—–"

  • .cer, .crt, .der - usually in binary DER form, but Base64-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", and Linux/Unix systems has a tool "openssl" which could be used as follows:

  • keytool -printcert -v -file certificate.pem

  • keytool -printcert -v -file certificate.der

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

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

In this topic
In this topic