Most of the client issues we encounter on AS2 Gateway, the online AS2/EDI exchange, are due to bad partner/station configurations - either on AS2 Gateway itself, or on the remote partner’s system.
Trust me on this; getting the end-to-end configurations right, the first time itself, would save you and your trading partner a lot of time.
To get things working, you just need three simple steps:
When exchanging any form of messages, you need an identity to, well, identify yourself among all people. In emailing, this is your email address; in AS2, it is your AS2 identifier - a name that you choose to identify yourself or your organization. The more unique, the better.
Like your email account, this AS2 identifier is bound to a trading station - the representation of yourself in the AS2 world. Every trading entity is a station from their own perspective, and a partner from all others’ point of view - more on that later.
In addition to AS2 ID, a station also has a key pair used for cryptographic operations. The private key decrypts incoming traffic and signs outgoing traffic; the public key is shared with your trading partners, to encrypt messages that would be sent to you (so that no one else can read them), and to verify signatures of messages sent out by you (so that anyone can confirm that it is really you who sent that message out).
Keeping this in mind, you only need these three pieces of information, to create your trading station:
AS2 Gateway can even generate the key pair on your behalf, so it boils down to just an AS2 ID and email address.
When generating a key pair, AS2 Gateway will obtain a few details from you (name, organization, address, etc.) to include in the generated public certificate - so that anyone holding a copy can know that it is yours. Since the private key needs to be protected, it will also ask for a password to use when storing the key.
Alternatively, if you have your own keypair (perhaps a S/MIME keypair issued by a trusted CA, or one that is already in use by a system that is being decommissioned), you can add them in the form of a key store; a Java keystore (JKS) or PKCS7 (P12) file.
There are other advanced settings that relate to email notifications and SFTP file paths; their default values are good enough for most cases.
This is easy - just open the partner configuration view of the station you just created, enter your partner’s email under Share this Configuration, and click Send.
For the curious bunch, the partner configuration includes details for your trading partner to send message to you, and to interpret signatures made by you - mainly your AS2 ID, message receiving endpoint/URL, and public certificate.
AS2 Gateway can handle most encryption and signing algorithms; if your partner requests more details on these, you can mention a desired algorithm that is displayed on the Advanced section of the partner creation view.
Similar to what you shared, your partner would send you details of their trading identity; once you receive them, you can proceed to the next - and last - step.
In AS2, both ends of the communication channel need to know some security-related details of the other end. In AS2 Gateway you do this by adding a trading partner that corresponds to the remote trading partner system.
The trading partner configuration includes details used for sending as well as receiving EDI/AS2 messages to/from the remote system. So it is a bit complex, but not too difficult to handle - once you correctly understand each element.
As mentioned before, a trading partner is actually the remote perspective of someone’s trading station. So, a trading partner has the following fundamental settings:
These are, in fact, the mandatory settings that you find on the partner creation page of AS2 Gateway.
When sending a message to your partner, you need to decide which algorithms to use in order to encrypt and sign it. AS2 Gateway supports most of the modern strong encryption and signing algorithms, and you can pick a desired combination.
AS2 Gateway is capable of receiving AS2 messages of different configurations: encryped/unencrypted, signed/unsigned, compressed/uncompressed and so forth. However, it needs to know a precise configuration when sending messages out. Besides, many AS2/EDI systems are configured to receive only messages of a very specific configuration: pre-compressed, SHA-256 signed and AES-256 encryped, for example.
If your partner has provided a detailed AS2 profile (expected configuration for sent/received messages, as mentioned above), you would most certainly have to adjust these settings. However, if not, the default settings auto-selected by AS2 Gateway would work fine in most cases.
AS2 protocol supports compressing the transmitted payload/file, to speed up delivery and save bandwidth. Compression can happen either on the original content (“before”), or on the final (signed and encrypted) content (“after”); if your files are highly compressible (e.g. XML), compress-before will usually be more effective.
In most cases, partners use the same keypair for decrypting incoming traffic and signing outgoing traffic; similar to what we saw with trading stations on AS2 Gateway itself. However some have a secondary keypair for signing outgoing traffic.
In such cases, your partner would have also sent you a “signature” or “verification” certificate. On AS2 Gateway, you can add it under Use Different Certificate as Sign Certificate option to comply with this mode.
If your partner hasn’t mentioned about such a certificate, you should not worry about this setting at all.
If your partner’s AS2 URL is HTTPS (starts with “https://”), and the partner’s endpoint (server) does not have a trusted TLS/HTTPS certificate, you may have to import their HTTPS (TLS/SSL) certificate, or one of its issuer certificates, before you can connect to their endpoint successfully.
Often, the easiest way to ensure connectivity is to test the URL - using the Test button against the URL input box. If you get a SSL handshake exception with a “trust anchor for certification path not found” error, the problem is most probably with an untrusted certificate; in that case, try adding the issuer’s certificate for their URL (endpoint), under the HTTPS section.
The Test button can additionally give you other helpful info regarding connectivity issues; invalid or unreachable hostnames/ports, possible firewall restrictions, and so forth.
Just like how you ask for a receipt when buying groceries (“submitting” your money), you can request your partner to send back a receipt (message disposition notification, a.k.a. MDN) for the messages you submit to them. (Remember “request delivery report” option of dear old SMS?)
This MDN, in addition to acting as proof of delivery, contains a message integrity code (MIC) that helps AS2 Gateway to verify that your partner received the full message content, intact and untampered.
The MDN has several associated settings: requesting a signed MDN (to ensure integrity of the MDN itself), allowing asynchronous MDN delivery (giving your partner more time to process the message), requesting the async MDN over HTTPS (for systems that do not allow plain-HTTP outgoing traffic), and so forth. In most cases, you would not need to fine-tune these settings as well.
This is very rarely used; only for very specific systems, that need you to include additional HTTP request headers in your messages (e.g. for authentication or routing purposes).
For example, if your partner’s endpoint requires HTTP basic (username-password) auth,
you can generate the auth value using a suitable utility,
and include it as a (Authorization, Basic {encoded value}) key-value pair under Custom Headers.
The trading partner settings were a bit overwhelming, but that was just for completeness; you can often get away with the mandatory few, and default values for the rest.
With that, you just completed setting up a very secure and versatile file transmission channel with your business partner!
Now all you need to do, is to send a few test files back and forth - and switch your production transfers over to enjoy the numerous benefits of the AS2 protocol.
Janaka is a Software Architect at Aayu Technologies. He is experienced in diverse areas including enterprise integration, B2B communication, and cloud and serverless technologies; and has been involved in the design and implementation of almost every Aayu product. Any interesting bug will keep him up overnight, as will tea, movies, and music.
We are a US based company with Sri Lankan ingenuity majored in Cloud and Serverless technology based product engineering.
Our solutions power small businesses using our hosted SaaS solutions , to enterprises that run our software on-cloud and on-premise.
