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 include EDI (EDIFACT/X12 etc), XML, CSV, Fixed-Width, Text and other proprietary or custom formats and binary.
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 an X.509 Certificate encoded in PEM or DER format, to its other trading partners.
The Sending Partner’s 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:
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 MIME messages 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.
Once the message reaches the target recipient trading partner’s 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:
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 received MDN will be stored 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.
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:
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, should 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.
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.
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.
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
Your Public Key is shared with your trading partners as an 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 (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
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:
These are the same as described before.
A trading partner will inform its AS2 URL to other partners it will trade over AS2.
This may be an HTTP URL (e.g.
http://as2.partner1.com/as2/receiver) or an 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 or tokens for HTTP
authentication, and so forth).
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.
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.
As Digital Signatures and Public Key Cryptography form 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 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
.der- usually in binary DER form, but base-64 encoded certificates are common too (see
.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 (JDK) includes
keytool, and Linux/Unix systems have
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