File Transfer, MFT and Beyond: The Story of AS2

Originally written for The AS2 Gateway Blog; Jun 17, 2020

This is a work of fiction. The incidents portrayed herein may have taken place under different settings, in a different order, or even not taken place at all; however, it will not refute the origin and evolution of Applicability Statement 2, more commonly known as AS2, the most popular secure B2B document/EDI exchange protocol in the known universe.

The Beginning: File Transfer, the Primordial Soup

Earliest files were paperbacked, and dispatched around via postal and courier services. They took days - or hours at best - to reach their destinations. Needless to say, a major bottleneck in rapidly growing B2B trade ecosystems.

Digital File Transfer

Then came computers and the internet, and things improved dramatically. (There were probably many more intermediates; fax, email, etc.; but we'll skip them for brevity.)

Now the transfers took just minutes - sometimes even seconds - instead of hours or days. Accuracy also improved greatly - no more deliveries to the wrong doorstep. Protocols like FTP and email soon became the de-factos for digital data exchange and file transfer.

But still, not everything was solid and foolproof:

Acknowledgement and Integrity

There was no receipt or acknowledgement/confirmation; you could send a PO, wait several days for the invoice, and finally phone them to find out they have somehow missed the file - still lying in a corner on their FTP server.

Also, the network did not guarantee integrity (delivery "as a whole"); you could have sent a 1000-row file, and the last 10 - or even 10 randoms from all over the place - could have gotten "lost". Even worse, a random flip of a few bytes could convert some five-digit price tag into a nine-digit one - I won't even start on the consequences.

Receipts and Hashes

So people and systems started to acknowledge these transfers with digital receipts; if you sent a file and received an acknowledgement (possibly another file) in return, you had a guarantee (non-repudiation) that the trading partner (or his system) has seen the file and taken it up for processing.

Now that there was two-way communication, there was also a way to verify that the receiver got exactly what the sender sent out (integrity); the receiver would calculate a hash (a finite-length summary; think of finding the "lucky number" from your birthday) of the received file, and send it back in the receipt. The sender could then do the same on the original file she sent, and verify that the two match - which would mean the content on both sides is practically identical (down to just a subatomic mergin of error).

Two problems solved; but still, there were more serious ones lurking around.

Eavesdropping, Tampering and Spoofing

File content was flowing through the (inherently unsecure) internet, in cleartext. This meant, any of your adversaries could eavesdrop on the files you are sending - and worse, even modify (tamper) the data being transmitted, to sabotage or manipulate your transactions.

True, you are already exchanging and validating the hash for the sent/received content; but a decent man-in-the-middle could easily pause the original data flow, do his modification and generate a new hash that would match the modified data.

(Or, if he had complete control over the data flow, he could simply intercept the partner's receipt as well, replace the hash with the old one, and relay it back to you, the unsuspecting victim - who would naturally assume everything went along just fine.)

On the other hand, when it comes to receiving files or receipts back from your partner, you had to somehow make sure that it was actually your partner sending those data in the first place - not something spoofed by a malicious third party.

Digital Signature: for Tamper-proof Integrity

What we needed here was simple: a way for you (sender) to place a "seal" on the file (very much like the wax seals from the old snail-mail days) and for your partner (recipient) to verify that the seal was not broken while things were in transit.

So the digital signature was born. Basically you take the hash of the file (as before), encrypt it with your private key, and send it alongside; and publish the corresponding public key (certificate) so that other people - usually your partners - can decrypt (verify) that blurb of data upon receipt.

This was a rather smart move! It achieved many goals:

• Since only you had the private key, the partner now had a strong guarantee that the file came from you - and you couldn't refute that either, even if you wanted to; authentication and non-repudiation.
• The "safely transmitted" hash guaranteed the file's intactness; integrity.
• Even if there was no anti-tamper encryption (next section) in place, if anyone managed to modify the file and generate a new matching hash, they would not be able to generate a verifiable signature out of it - without breaking into your private space and stealing your very own private key.

Good; now if we could just make the file unreadable to prying eyes, in transit...

Encryption: for Invisibility (Confidentiality)

As the title suggests, encrypting the file content makes it invisible (more correctly, incomprehensible) while it flows through the internet. Which means there is no room for the adversary to read or modify the file content.

Of course there had already been 'secure' protocols like SCP, SFTP and FTP/S that would transfer encrypted content (ciphertext) instead of cleartext; however, you still had to make sure that you were connecting and sending to the correct remote partner/system; jumping over traps like DNS spoofing.

But with AS2 encryption, even if you connected to a wrong server, your content was encrypted using a certificate (public key) that was pre-shared with you by the real partner - and not the certificate of the currently connected server. So, even if you did accidentally send the file to a hacker, they could not possibly decrypt it without access to the partner's own secret private key - which never comes out in the open, throughout the whole process.

AS2: there you are!

What we (or rather, many ingenious people over several decades) invented so far - adds up to the AS2 protocol - which happens to be the most popular secure file transfer protocol today. Especially after Walmart the Giant mandated it for all its trading partners since 2002.

You can learn more about the protocol from its official RFC 4130 document, which is very informative and fairly simple to understand.

Having said that, where are we now?

All set; file transfer is secure! But...

If you scroll up towards the "Digital file transfer" section you would realize that, while we have achieved a remarkable level of security, AS2 has also added a lot of overhead and complexity to our business flow:

AS2: secure, but complex!

Let's see what it takes:

To send one batch of files

1. share the connectivity data and encryption (and signature) certificates with your trading partner (thankfully, this is a one-time task - for each trading partner, that is)
2. combine the file(s) you wish to transfer, into one big MIME message
3. compress the MIME (to reduce its size and save transfer time/bandwidth; could be significant depending on the file data)
4. compute the hash of the data blurb at hand
5. sign the blurb with your private key (and keep it secure)
6. encrypt the whole thing with your partner's public key
7. transfer the encrypted data over to your partner's system
8. wait for the receipt (MDN) from the partner
9. check the signature of the MDN against the partner's public key (to make sure it wasn't forged by someone else - and hasn't been tampered with)
10. process the MDN to see if everything went fine - or whether there were any errors on the partner's end (opening up a whole new pathway for troubleshooting)
11. check the hash (message integrity code, MIC) sent in the MDN against what you calculated in the beginning, to make sure that the partner received the same data that you sent out - untampered
12. if the MDN was asynchronous, acknowledge it properly to close out the connection (and with it, the transaction)

And when receiving a batch of files:

The situation is as much complicated:

1. share the connectivity data and certificates (one-time per partner)
2. keep on listening or checking for incoming messages from your partner
3. when one is received, accept and load the incoming blurb of data
4. decrypt the data using your own private key
5. extract out and verify the signature part using your partner's public key - to ensure integrity
6. decompress the data part to get to the MIME of files
7. decompose the MIME into original files sent by your partner
8. compute the MIC over the actual data
9. compose an MDN with the MIC, and any errors you encountered during the process so far
10. sign the MDN with your private key - for authenticity
11. send the MDN back to your partner, and ensure they received it

Obviously, too much of a technical burden for an already-complicated business flow, and a team that is already overwhelmed with a thousand and one other business-critical tasks and needs.

There are tools like the openssl suite that can take good care of individual steps; but chaining them up to fulfill the overall flow is not very trivial or feasible, even for a tech-savvy team; and most business teams cannot afford such a subdivision of techies in the first place.

Managing the transfers: more overhead

While it solves the security aspect and provides an end-to-end guarantee of the file transfer, AS2 by itself does not fully solve the caveats of file transfer, especially being over the unreliable internet:

• If the transfer fails mid-way - or the partner system reports an error, confirming that it couldn't get hold of the files - you need to replay the transfer.
• If the transfer itself is successful but you don't receive a receipt (MDN) after a considerable wait, a replay may be required as well.

Furthermore:

• As your business grows, it should be able to automate the AS2 transfer aspect as well - rather than having to manually submit each file or manually inspect every MDN receipt.
• Going with the ever-growing trend of digital transformation, file transfer also needs to become a well-streamlined piece of the overall business data flow in your organization.
• Setting up and juggling with multiple trading partners, with dozens of certificates, endpoints and pieces of configuration, can soon become daunting and error-prone.
• Auditing and keeping track of transfer history and failures could be important for QoS/reliability assessments as well as business-level audits.

And that is why many new as well as well-established businesses are turning towards:

Managed AS2 and MFT Solutions

Managed File Transfer collectively refers to addressing the pain points we discussed so far:

• All the security and end-to-end delivery guarantees of AS2 (or another MFT protocol)
• Easy and simplified configuration management for multiple trading partners and local identities (stations)
• Enhanced delivery and visibility, such as automatic retries and notifications in case of permanent failures
• Enterprise-ready: ability to easily integrate with your existing business systems via popular mechanisms like APIs, queues, webhooks, secondary file transfer protocols, cloud services etc.

Such MFT systems can be:

• on-premise (deployed on your own local data center) or cloud hosted (on a public cloud platform like AWS EC2)
• dedicated or shared (multi-tenant)

The choice depends mainly on:

• your expected file exchange load a.k.a. volume (distribution and numbers per minute/hour/day, average size of one file, etc.)
• the quality of service (QoS) that you expect (for example, will a couple minutes' downtime - fairly common in shared, multi-tenant SaaS platforms - critically affect your business? If so, a dedicated deployment with a fail-over/high-availability (HA) server is the way to go.)
• how deeply you wish to integrate with or customize the platform; a regular SaaS would no longer make sense beyond a certain point - in contrast, a dedicated deployment would always offer the highest and fastest level of adaptability
• your organization policies, and security/compliance requirements (e.g. PCI, SOC2, GDPR)
• and, of course, your budget

Where to Go from Here

AS2 Gateway is a simple yet mature AS2-based MFT platform, nurtuted and trusted over a decade of production use by customers all over the globe.

In addition to an intuitive, email-like interface for exchanging files with your trading partners, it offers automation mechanisms like SFTP and a REST API that will closely integrate with your own order processing system and business workflow. More integration methods like webhooks and cloud storage like AWS S3 are already on the way.

Getting started with AS2 Gateway SaaS cloud hosted platform is pretty easy; there is comprehensive documentation, demo videos and troubleshooting references to guide you every step of the way. Besides, the friendly AS2 Gateway team is ready to help you at any hour of the day.

If your use case calls for a dedicated installation, with higher messaging capacity, cloud or on-premise hardware, and custom integrations with your own systems, it is just a quick call or form-fill away.

Why you NEED MFT - "Managed" File Transfer - in this 2020 Decade

(Or, what the "Managed" part of MFT is all about)

Originally written for The MFT Gateway Blog; Apr 24, 2020

Not to sound opportunistic, but the whole COVID-19 situation is leading online businesses to boom like never before (source: BBC). With this, inevitably, the value of computerized trading and automated, secure trade document exchange comes boldly into the picture; and this is also the part where we say, "you should have adopted a MFT solution last year... but it's not yet too late!"

But I already have "File Transfer" - why "Managed"?

Let's take the best path to learning - by example.

Assume you need to send a long list of order items to your vendor. You and your vendor have decided to use the world-famous File Transfer Protocol (FTP) to exchange these docs. It's all very simple:

ftp
open your.partners.host port
cd incoming-orders/your-orders-folder
put your-orders-file-yyyy-MM-dd-HH-mm-ss.csv
exit

Done. The file is transferred.

And now, it's time for the questions.

Burning Questions: for Your Brow

Ten files a day? Fine. Hundred? Thousand?

COVID is snarling, and ironically your business is literally exploding. Now, each day, you have to send dozens of these files, to different FTP servers across your vendors - yes, it recently became plural when you decided to expand your online storefront.

Running a hundred ftp command scripts each day by hand, is not exactly a pleasant experience. Plus, you learned the lesson when you mistakenly uploaded file order-A to partner B's server. So you set up a cool program, and script it to automagically send each file to the correct partner - as soon as you drop them into a monitored folder.

Did the whole file get through - unchanged?

Now the script is doing the job - like a boss. But is it doing the job right? Are you sure?

Say the file was in a CSV (spreadsheet-like) format. Do all the rows get transferred? What if the last hundred rows get dropped during the transfer (say, a network glitch) and nobody notices - not your script, not the ftp command, not your vendor?

Worse... what if a few bits got flipped, and a 10000-crate order got changed into a 90000 one?

Yes, we need to get a file "summary" from the vendor (trading partner) - and ensure it matches with the "summary" on our end. We need to compare the digest (hash; like MD5, SHA-1, SHA-256 etc.) of the final file on both ends, to make sure nothing got corrupted or tampered.

Did somebody else (secretly) tap the transferred file?

Phone taps are still fairly common, and computer network taps are no exception - especially when unprotected, plain-text protocols like FTP are in play.

You could encrypt the traffic by switching to FTP/S or SFTP so that the thief trying to tap your file would get just the encrypted (gibberish) blurb.

But... read along.

Who is at the other end? Your partner, or an imposter?

There are easy techniques (like DNS spoofing) even to trick your system into connecting directly to an attacker's system - especially if you're not careful and attentive enough. You would use end-to-end encryption and stuff, but would be sending the data right into the fox's den.

So we need a mechanism to ensure that only our vendor would be able to make sense of (decrypt) the data we send. Perhaps by encrypting it with a public key whose private key part is owned by him and him alone.

The most fundamental: Did your partner see the file?

Your script happily uploads hundreds of files each day; but does it guarantee that those vendors are even looking at those files? If you don't receive back a confirmation, how can you know if the file got to the wrong system - or got lost in the crowd - or some other nasty thing happened?

Yes, we need an acknowledgement (receipt) from the vendor that he got our file.

Burning Questions, Part 2: for Your Partner's Brow

Sadly, that's not the end of the story; your vendor-partner is even more skeptical - almost paranoid, to say the least.

Was it really that guy (or gal) who sent this file?

The imposter thing could work the other way too. Somebody impersonating you, could send a funny order to your vendor; and the next thing you know is, opening your door to a thousand crates of icky goo.

So your partner needs your unique signature at the bottom of that file - to ensure that it came from you.

Were those numbers in the file, corrupted or tampered while in transit?

Already covered this from your own perspective - digest. Moving on.

Did somebody else tap the file?

Also covered - public-key encryption.

How the heck am I supposed to do anything useful in my day - when I have to keep on decrypting, digesting, verifying and acknowledging dozens of files from that guy (or gal)?

Yes. Your partner needs to seriously think of automating the whole thing. Like you did.

Enter: "Managed" File Transfer!

Say you hired a whole development team, worked day and night, and implemented a solution that covers all of the above concerns:

• adds a signature alongside the file content - so your vendor can verify that it indeed came from you
• encrypts the file using your vendor's public key - so only your vendor can decrypt it, only using his private key
• sends a receipt back when a file is received, so you know for sure the file actually reached your vendor's system
• calculates a digital digest (hash) of the received file and sends it back with the receipt, so you can compare it with your own hash - and make sure the file is intact in your vendor's side
• and most importantly, automates all of these steps and actions and raises red flags if anything fishy goes on

Congratulations!

You just wrote your own "managed" file transfer solution!

But why did you?! MFT is already out there!

If you check out the features of AS2, for example, you would be surprised (or maybe not?) - it already covers all of those concerns you painfully scratched your brow over!

And it already implements everything that your hired dev team had to go through, day and night!

If you check any other protocol (AS4, OFTP, ??, and the like), the observation will be more or less the same. But AS2 is the most sought-after MFT protocol in the business world (heck, Wal-Mart enforces it!), and going with the trend always has its benefits.

So, that's the beauty of Managed File Transfer, MFT.

It covers the end-to-end delivery and acknowledgement/reporting of files; so once you hand over a file to your MFT system, rest assured that:

• either the file will be successfully delivered and acknowledged by your partner's system,
• or (if something goes wrong) your team will be duly notified.

No more staring at ftp folder listings or long dashboards, the whole flow is fully automated and streamlined.

Most MFT platforms also offer value added services (VAS) on top of the basic MFT protocol; such as document (usu. EDI) translation, validation, auto-generation of response documents, and various integrations with third-party systems like CRMs, warehousing and BPMSs.

Meanwhile others give further flexibility by offering intuitive low-level interfacing/integration options; like SFTP- or AWS S3-based triggering of file send-outs, REST APIs for fully automating the management and monitoring of the send/receive process, email-based instant notifications, and so forth.

Okay, back to work - your orders are waiting!

Now, before you go back to uploading those files via FTP, you have a choice to make:

• continue doing business as usual - upload, wait, call the vendor if nothing happens, rinse, and repeat for the next file?
• hire an exorbitant dev team and build your own "managed" file transfer solution?
• install, or more easily, sign up for one of those popular MFT services out there - and dedicate your valuable time to developing your booming business - rather than bothering with file exchanges?

I guess now you know the answer.

Good luck! And we're also waiting eagerly for your queries!

Hola, AS2! (a.k.a. Your First AS2 Message, with AS2Gateway)

AS2, despite being the most popular secure B2B communication protocol, is fairly complicated for a beginner, regardless of how mature he may be in the actual business domain. Not to mention the various operational caveats of maintaining an in-house AS2 server.

That is exactly why we built AS2Gateway, making it super-easy for even a five-year-old to send AS2 messages to any partner in the other corner of the world... or so we boast.

Hmm... wait... is it actually that easy?

(Are you kidding me? Partners, stations, certificates, encryption certificates, sign certificates, cert chains, async MDN, signed MDN,... sounds like ancient Greek to me! Where am I even supposed to start?)

Relax. Let's go one step at a time.

(Okay.)

Vocabulary first.

AS2 is all about sending and receiving messages (documents; POs, invoices, shipments, you name it) securely, between "partners" (yup, business partners). The format or content of the messages (EDI, X12, ebXML, ... heck, even plaintext, images or videos) doesn't matter; as long as it's a file, AS2 can deliver it, and produce a receipt (MDN) as well (so the sender can be sure that the recipient got it, securely and untampered).

(So there we have partners. But how about me? Am I a partner too?)

Yes you are, from the viewpoint of other partners. But we love you and want you to stand out from the crowd, so in AS2G, you are a station, not a plain old partner. You could have multiple stations (and hence, multiple identities) for trading with different partners. Messages received from partners to your different "identities" would appear under the corresponding stations. Just like having multiple mail accounts configured on the same browser.

(Alright, so I'm a station. Whatever. I don't care. How do I send a message to a partner?)

Well, you just

• click the New Message button (rocket) on any page,

  

• pick the intended partner,
• pick your station,
• key in a message subject,
• upload or drag-n-drop the files, and

  

• click Send.

Just like in mail, except that you don't have to type a message body, but do have to select your own identity (station); in case of mail, the latter you already did (kind of) when you picked your mail account.

That is, if you have already set up your partner.

(Aha, so that's the catch! How do I set up a partner?)

Well, for that, we gotta go back to the vocabulary lesson—or more precisely, dive a bit into the world of AS2.

As you may already know, AS2 is all about security and reliability in document transfer. To achieve this, AS2 softwares have to perform quite a bit on behalf of you:

• for outgoing messages: encrypting and signing, and compressing the content
• for received messages: decrypting, decompressing and signature verification, generating (and optionally signing) the receipt if one has been requested

While AS2G is already a champion in all this stuff, it still needs to know the expectations of your partner (the "partner configuration") in order to perform them. That is why you need to head over to the partners page (ensure you are logged in before clicking the URL!), click the New Partner button at the top, and carefully fill up the resulting form.

(Huh, you sound like it's a piece of cake! If I knew how to fill in that form, why the heck would I be reading your article right now?!)

Calm down folks, almost there. Let's go field-by-field. Except the partner name, type and description, everything else in the form should be provided by your partner, so it basically boils down to bothering your partner until he gives up all pieces of the puzzle to fill the blanks in the form.

• Name is, as you have guessed, the name you would like to call your partner (just for display and auditing purposes).
• Partner Type is usually Production, unless you specifically want to do kind of a "test bed" configuration; if you pick Test you would have to make further changes when you are ready to go for production (for actual business messages), so it's better to stick to Production.
• AS2 Identifier is an AS2 protocol-level magic word that uniquely identifies your partner. Your partner should provide this to you during the setting-up stages, just like you should send your AS2 ID to him/her; chill out, it's just a piece of text, and maybe digits (alphanumeric, in tech jargon)—you only have to ensure that no other partners of your partner are using the same token, because otherwise your partner may mix up the messages sent by you, with those from other partners.
• Description is, again, just a blurb of text for your convenience in picking your partners apart.

Okay, that was easy enough. Now the geeky stuff.

• URI is the HTTP/S address at which your partner is accepting incoming AS2 messages. (If this happens to be HTTPS (i.e. begins with https://), you have a bit more work coming up later, in the Advanced Options section!)
• Encryption Certificate is a file (containing a "key"—a public key, to be exact) provided by your partner, which you can use to "unlock" (decrypt) messages received from him. Before sending, your partner will "lock" his messages with his own private key, and they can only be "unlocked" by the above public key. Since the latter can only decrypt messages encrypted by the former, it ensures that the message did actually originate from your partner, and guarantees that no evil force would be able to make any sense of the message while it is in transit (since it is "locked" (encrypted)).
• Use different certificate as sign certificate is a bit of an advanced option which allows your partner to use a different "key" (file) to generate a "signature" of the message content (which is also sent to you, along with the message, for verification purposes). If your partner does not provide this, he would probably be using the same certificate (let's call it "cert", okay?) for encryption and signing; if he does provide one, just upload it here. Either way, not much to worry about!
• Sign/Encrypt Chain Certificates are for establishing trust; to indicate that the certs provided by your partner actually do belong to that partner. (Otherwise, a third party could impersonate your partner and send you their certs and details, and capture all your messages that you (believe you) are sending to your partner!) If you don't get it, not to worry; if your partner provides these files, just upload them here!
• Message Subject, again, is a down-to-earth field that specifies a default subject for messages you send out to this partner (so you don't have to tire your fingers typing it every time).

In some cases you may be able to get away with the above lot; however, if your partner mentions anything about:

• encryption algorithm,
• signing or digest algorithm,
• sign or digest encryption,
• compression,
• async MDN or signed MDN,

it may be time to open up that Advanced Options section as well :(

Here we see four main "categories" of options (although there is no visual demarcation), the first being encryption:

• Encrypt Messages indicates whether your partner expects you to "lock" (encrypt) messages that you are sending out to him; just like the ones he is sending to you. This time, you will have to send your own "key" (public cert) to your partner so that he can "unlock" your messages; more on that later!
• Encryption Algorithm is the locking "mechanism" that you (AS2G, to be exact) will be using for messages being sent out to your partner—as requested by your partner, of course.

Next comes signing:

• Sign Messages, similarly, indicates whether your partner expects a "signature" (a verifiable, summarized blurb representing the payload) along with each of your messages.
• Sign Digest Algorithm should be set to your partner's preferred mechanism for producing the abovementioned "signature blurb".
• Sign Encrypt Algorithm is the locking mechanism that your partner expects you to use upon the abovementioned signature (as opposed to the payload that was mentioned previously). With this, both your message and its signature would be in encrypted form during transit.

And compression:

• Compress the messages before signing should be enabled only if your partner likes to see the incoming message in compressed form (primarily to save network overhead and speed up the transfer).
• Compress the messages after signing is similar to above, but applies to both the message (which may already have been compressed!) and its signature combined.

And, finally (phew!), MDN:

• Request MDN decides if you should demand your partner to send back a "receipt" (disposition notification) for every message that you send. The MDN mechanism in AS2 is cleverly crafted such that being able to receive and process an MDN guarantees that the message exchange was successful.
• Request Asynchronous MDN, if you have enabled the above option, indicates that your partner should send back the MDN in a separate channel (i.e. you send your message in one path (HTTP request), to which the partner simply acknowledges; later on, your partner generates and sends the MDN back to you in a newly initiated path (new HTTP request; to which you send another acknowledgement).
• Request Digitally Signed MDN demands your partner to send a signature along with the MDN, just like you (might have) signed the message itself when sending it to him.

Okay, take a deep breath. Count from one to twenty-five. Whatever. Just keep calm.

To clarify things a bit, let's have a look at an example configuration of a trading partner:

• called My Awesome Partner
• with AS2 ID AWSMPTNR,
• who accepts messages at the URL http://as2.acme.com/as2/inbound

where the messages need to be:

• compressed, right at the beginning (before signing/encryption),
• encrypted with AES-256-CBC using the AWSMPTNR-encrypt.pem cert,
• signed with SHA-256 using the same cert,
• and the signature itself encrypted again, using RSA, and
• compressed again (after signing and encryption),

and you wish the partner to:

• send back a receipt (MDN), which is
• asynchronous and
• signed

Applying the above barricade of rules, our partner would appear as follows:

Here we have requested our awesome partner to reply with a signed, async MDN (receipt) for every message that we send him.

If you assume, for a moment, that AWSMPTNR later happens to need to use a HTTPS URL for receiving messages:

• https://as2.acme.com/as2/inbound
• protected by a AWSMPTNR-https.pem HTTPS certificate
• which has been verified by a third-party certification authority (CA) whose chain certificate has also been sent to you,

the top (HTTPS-related) portion of your Advanced Options section may look like:

You don't trust this third-party guy who signed your partner's HTTPS cert, but the third party has its own cert signed (verified) by another CA that you do trust—which forms a trust chain wherein you trust the third party's cert because it is signed by a known CA, and in turn you trust your partner's cert because it has been signed by someone that you do trust now.

Trust chains. Now, how sick is that?!

Going a bit further, what would you see if your partner starts using a different sign certificate AWSMPTNR-sign.pem, verified by a third party verified by another third (fourth!) party verified by another (fifth!) party; where you (luckily) trust the last one?

In case you lost it entirely, those two certs uploaded under Sign/Encrypt Chain Certificates are the "third" and "fourth" parties, which helps AS2G build the trust chain from the top-level trusted CA all the way down to your partner's sign cert.

If the above stuff seems totally Greek (or Chinese, gibberish, whatever) to you (and rightly so!), feel free to consult AdroitLogic for getting things in order; or, if you feel adventurous, go ahead and mess around with the switches and drop-downs your own :) It's highly unlikely that you're going to break anything!

Phew, finally we have our partner in all his glory, ready to roll.

With me so far? :)

If not, just take a deep breath and read through the stuff again, slowly and carefully (maybe skipping the techy innards, if you feel better that way); it would eventually make sense.

Though we have our partner, we don't have a station yet. So let's go ahead and create one.

Head over to the station page and click the New Station button.

You'll end up in another form; just like the partner configuration thing, but much simpler.

(I knew it... Another form. How many more of those until I get to actually send a message?)

Just this one, I promise.

Here you can define how your partners should send messages to you. This includes:

• Name: again, just a name for your convenience.
• AS2 Identifier: a unique identifier for yourself, just like in the case of a partner, kind of like your own NIC or Social Security Number.
• Email: the email address you would like to associate with this station; just for email notifications of incoming messages.
• Enable Email Notifications: by default AS2G will notify you via email as soon as your station receives a new message from one of your partners; you can disable this feature using this switch if it becomes too annoying.
• Description: again, just a blurb of text for your convenience

Now begins the (thankfully, much shorter) list of geeky stuff, primarily for defining your station's keystore (where AS2G would be storing all the keys and certificates that allow you to communicate securely with your partners; similar to what you saw in the partner configurations):

• Key Store: here, AS2G allows you to either

1. generate a new keystore, on the house! (whose fragments you can later share with your partner)—obviously the easiest option!
2. upload an existing keystore from your computer—handy if you are migrating stuff from a different station (or an entirely different AS2 platform) but don't want to bother your partner; i.e. your partner will see you in exactly the same way as he did before, although you are now using a new station! (Note, however, that this won't work if your new station's name differs from that of the old station :()
3. select one that has already been uploaded, and is available in your certificate store right now.

The last two options are straightforward (upload a file, or pick one from a list), so let's have a closer look at the first one (which you would be picking anyways). You would have to fill in some details of the newly generated keypair for your brand new keystore, which are standard to the X.509 format (now, now, no need to google it!).

• Common Name: This is the only mandatory field; put in either your own name, or maybe your station's name?
• Organization Unit and Organization: kinda like your department, and the parent organization name
• City, State, Country: address (you get it)

Now the geeky stuff (again!):

• Key Length: the size of the key; generally the bigger the key, the more secure your encrypted message is—and the slower the encryption/decryption process would be. Generally 1024 or 2048 would suffice.
• Keystore Password: a password for the new keystore, so you can inspect it later on if required
• Certificate Password: a password for your key itself (private keys need to be stored with great care!)

Now you have configured your side of the bargain. But your partner also needs to configure a "partner" on his own system, that corresponds to you (since you, after all, are his business partner). Hence you need to somehow pass your details through to him, so that his partner configuration is compatible with your station configuration.

Now, how do you do that?

Lucky for you, AS2G can do it for you!

(Really? Finally, something cool.)

Once you open your brand new station from the Stations page, enter the email address of your partner in the Share this configuration text field, and click Send. Your partner will receive your station configuration via email, and can configure your partner profile on his side accordingly.

Now follows another wait (hopefully not too long!) until your partner confirms that he has added your info to his AS2 system; just like we did for him. Yup, patience is a virtue.

Now, for the first time in history, you are ready to send your first message!

Go ahead, click that rocket icon, pick your partner, select your files and click Send!

From this point onwards, AS2G is as simple as that!

For a brief time, you may see your message in a "queued" (pending) state:

Usually, however, AS2G will pick it up and sends it out within seconds:

In the unlikely (Or likely, maybe? After all, this is your first message!) event that your message decides to play a trick on you and fails to be sent out, you will see under the "Failed" tab of the message view, along with the failure cause:

In that case, you can open up the failed message and use the various controls to navigate through its metadata and failure details.

Oh, and did I mention that you can contact the AS2G Team anytime to learn more details, and more importantly, about how to avoid the failure in the future?

Now that you know the basics, things are going to get easier, way more useful, and way much fun!

Got a new partner? Add a new one on the Partners page, share your station details with him, and pick the new partner from the Partner drop-down when sending your messages!

Partner not happy with your station config? Just create a new station with different, more partner-friendly configs, share it with your partner, and select the new station from the Station drop-down when sending to that partner!

See all your inbound and outbound messages in your message view, along with corresponding acknowledgements (MDNs): just like your mailbox!

Whenever you need to analyze a message in depth, or troubleshoot a failure, just contact the AS2G Team—or, if you feel adventurous, dive down into the details yourself, with the abovementioned detailed message view including transport-level headers, error metadata and retry information.

AS2G has a lot more in store for you; so, my dear folks, it's time to get going!