AS2: Part 3 – Certificates

This last year the EDI community has shown an increasing interest in AS2. But what exactly is AS2? This is the third in a multipart series to examine AS2 and what it means going forward to the EDI industry. If you want all the historical and technical information on AS2, then I suggest you Google AS2. This series is about the practical uses and not to bore you with (too many) details.

In AS2 communications certificates are used for both encrypting and signing messages. This thing that makes AS2 great and also makes AS2 miserable. In this article I will explore what that means, how they work (and don’t work) and what we can all do better. This is not a great technical discussion, but a practical AS2 user’s guide to certificates.

Certificate Basics

The terms “certificates” and “keys” are commonly confused and are often used interchangeably. The quick differentiation is this:

1. Keys are the actual bytes that are used by the encryption/signing process. Keys come in pairs, one private and one public. Private keys are to be held securely and never shared. Public keys are shared. It takes a unique private/public pair to encrypt/decrypt and sign/verify.
2. Certificates are containers that hold keys (X.509 is a common certificate format), this includes information about what the key can be used for (e.g. encryption, signing, both, etc.) and what the valid dates are for the keys (e.g. expiration). Public keys are always sent out in a certificate.

To use certificates a private/public key pair is generated. The user keeps a copy of the private key encrypted and password protected, and never shares it with any one; while the public key is freely disseminated to trading partners. By using this pair of certificates/keys one can encrypt data that can only be opened by the intended recipient. Additionally, one can sign data so that the recipient can verify the sender and that the data has not be changed.

The ability to encrypt and sign is the cornerstone of what makes AS2 so great. Nearly every AS2 package allows data to be sent without encryption or signature, but for the life of me I cannot figure out why. Also, it is possible to use different public/private pairs for encryption and signing. Thankfully, I have not come across anyone who does this, it would add unnecessary complexity and double the work needed to maintain certificates.

Encryption

Assume we have two users, Aaron and Bob. Aaron wants to encrypt data and send it to Bob. Before this happens, user Bob must send Aaron a copy of his public certificate. Aaron then takes the data it intends to send to Bob and encrypts it with Bob’s public certificate. When Bob receives the data, it is decrypted with his own private key.

Aaron: Original Document + Bob’s Public Certificate = Encrypted Document

Bob: Encrypted Document + Bob’s Private Key = Original Document

AS2 manages this by keeping a “store” of all your trading partners’ public certificates. When you send to your Trading Partner (TP), the AS2 software pulls up the TP’s public certificate and runs an encryption routine on the data. This blob of data can only be decrypted with the TP’s private key. If the data ends up in the wrong hands, it would be very difficult to decrypt. Encryption is not perfect, but it can only be cracked with a tremendous amount of computing power; certainly good enough for our needs.

Signing

Using our same two users Aaron and Bob, now Aaron wants to sign the data so that Bob can confirm that it was Aaron who actually sent it, and the data has not changed. This process uses the keys in the reverse order. First, Bob must have a copy of Aaron’s public certificate. Aaron takes the data and runs it through an algorithm with his own private key. This then generates a unique digital signature (set of characters also known as a hash) based on the data and the private key. This signature is now sent along with the data to Bob. Bob then runs the data and the digital signature through an algorithm with Aaron’s public key. If everything matches up, then it is verified that Aaron sent the data and it was unchanged.

Aaron: Original Document + Aaron’s Private Key = Digital Signature

Bob: Original Document + Digital Signature + Aaron’s Public Key = Verified

Again, AS2 manages this for you by creating a digital signature for your data with your own private key and sends it along with the encrypted data. The signature is different for every set of data, but can be verified by anyone who has your public key. That is why it is a signature, not encryption.

Putting together Signing and Encryption it looks like this:

Aaron: Original Document + Aaron’s Private Key = Digital Signature
Aaron: Original Document + Bob’s Public Key = Encrypted Document

Bob: Encrypted Document + Bob’s Private Key = Original Document
Bob: Original Document + Digital Signature + Aaron’s Public Key = Verified

Certificate Authorities

We all know something about certificate authorities (CA) from visiting going to secure web sites (especially ones where there is a problem with the certificate). The certificates on these sites provide two functions:

1. Certificates allow the data to/from the server to be encrypted (SSL) and
2. The CA vouches for the authenticity of the owner of the site (I will not go into how weak this assumption is…that is for someone else’s blog…).

This is a different model than with AS2. When visiting secure web sites you do not possess the public key from the site’s owner; instead, the CA provides the trust as your computer already has the CA’s public key in its repository. Your trust for the web site is derived from the fact that you trust the CA (a “chain” of trust).

With AS2 we do not need a CA to trust the authenticity of the other party, because we have already secured its public certificate through another channel. This means it is a waste of time and money to get your AS2 public certificate signed by a CA.

If your trading partner does send you a signed certificate, and the whole chain of CA certificates to go with it, you should be able to not bother with any of the CA certificates and simply install the provided public certificate as if it were “self-signed.”

Self-Signed Certificates

Instead of using a CA, most every AS2 package allows you to generate and sign your own certificate. The process will generate both a private and public key for a length of time selected by you. (More about how long to make the certificate valid below.) The private key it will automatically be securely stored where the AS2 software can access it, and the public certificate will be placed in a location where you can send copies to your trading partners.

One note about self-signed certificates, you need to make sure that you use a unique serial number each time you generate a new one. Some AS2 packages handle this automatically, others expect you to enter a unique number each time. If you need to enter a unique number, make it easy on yourself and just use the current date (e.g. 20130803).

Exchanging Certificates

Public Certificates are generally stored files that end in .cer, .crt or .der. In any case they can be in binary or PEM format. I personally prefer PEM as it has been BASE64 encoded and can even be copied in the text of an e-mail message. Here is our own public certificate in PEM format:

-----BEGIN CERTIFICATE-----
MIIBtjCCAR+gAwIBAgIBAzANBgkqhkiG9w0BAQUFADAhMR8wHQYDVQQDExZFQ0dyaWQgQVMyIENl
cnRpZmljYXRlMB4XDTA3MTAwMTIxMTcxNloXDTE3MTAwMTIxMTcxNlowITEfMB0GA1UEAxMWRUNH
cmlkIEFTMiBDZXJ0aWZpY2F0ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAziLTH4urrO8s
LBCIz6vKWunuIeEpRuVQz6B+7UYzmhckB18VDjYBI5Bp4IFIRJxwsqJx8hoLNJivX26T9zDtcmO+
X58FeyIyea1ecp/cwi3ebdWpiLaxQPCV3nLQx/3mas8LHWSDlg5NT3VgPzFJHQoY1ukdPDVgnApn
n877ygMCAwEAATANBgkqhkiG9w0BAQUFAAOBgQDOGQc4UfQj0p7AEUAd+8Ue+/hRomyI4/RvaRv9
fjw2a1BhZfmzrUXTReIKzuhIKfXoX22YyTP5MVTWzKeIh2qIc/488rAh5yOsoHsHRVGoTDibLWvN
/wiMRYhw6TY6Vnz+3IyXyNtktspAg7wprno1pkmAw63sONAR+996og43UQ==
-----END CERTIFICATE-----

You can actually cut & past this using a program such as Notepad. Save the file with a .cer extension and then open it up to see all the internal values.

Regardless of the format, many e-mail programs will block .cer, .crt and .der files as attachments (very dangerous files…). One can simply add .txt to the end of the file (e.g. ecgrid.cer.txt) in order to send it as an attachment. You can also compress it into a ZIP file. Personally, I prefer zipping up all our AS2 information along with our certificate into a file (including all contact information) so our trading partners have it all in one place.

File naming…please do not name your file as2.cer or myas2certificate.der anything like that (yes, I see it all the time). Make it a meaningful file name. Your trading partners are likely going to be handling many certificates and yours should be unique and useful. When you send a replacement certificate, do not send the same file name. I suggest the following format:

<as2id>.<begin date>-<expiration date>.cer
ECGRID.20071001-20171001.cer

Expiring Certificates

So far, so good, but here is where we get to the bad and the ugly of certificates and AS2. How long should one make their certificate good for and how does this affect my trading partners?

This is one of the worst thought out areas of AS2 software packages. Since every communication needs to have the properly matched private and public keys, when one AS2 user changes its private key, all the trading partners need to simultaneously change their public certificates. We all know this one, flash updates at name your time and day of week. Ugh. This need not be, but it is how all nearly all the AS2 software is set up.

Just imagine how many people Wal-Mart has updating trading partner certificates in their system every single day! It is interesting to note that Wal-Mart got around the flash changing of its own certificate by setting up a unique private key on its end for every single trading partner. It staggers the changing, preventing massive update failures, but drastically increases the amount of work. A brute force method to a brutal problem.

I’ve thought long and hard about how long to make a certificate valid for. There are some that say not to make it valid for too long a time because it could become compromised. But the more often you change, the bigger a problem it is for yourself and your trading partners. I’ve come to the conclusion that you should make your certificate good for a very long time, ten years or more. If it were every compromised, you can then simply stop using that certificate and start using a new one.

I have to confess, we set up our first certificate for one year. Live and learn. We set the valid period for our next (and current) certificate for ten years. I am certain that the thousands of companies that have traffic flow through our own AS2 hub are quite happy to not have to change our certificate on a regular basis. Wal-Mart specifically will not allow a certificate to be good for more than five years, so we have special certificates just for them.

When it is time to change your certificate, give your trading partner a good month’s notification and make the change two to four weeks before your certificate expires. Please don’t do it on a Saturday at 3am. Also, when sending out notices for your certificate update, be extremely specific about the time zone. I have received many requests for a particular “standard” time zone when it in fact was “daylight” time. My suggestion is to always include the equivalent UTC time, that way there is no ambiguity.

There is one thing that can’t be avoided, adding a new trading partner just before you are going to update your certificate. Do let them know right then and there that you plan to update shortly. It’s just courteous.

Personally, I think the exchange and update of certificates is the biggest shortcoming of AS2. At Loren Data, we have been focusing on this specific issue as key to wider AS2 acceptance. AS2 packages should know how to exchange public certificates automatically, in a secure and reliable way.

If properly implemented and automated, one could change certificates weekly or daily without any impact on their trading partners! However, as it is now, every certificate change is a PITA, so be very considerate of your trading partners when it comes time to replace your existing certificate.

NOTE: Save your expired private keys and public certificates from your trading partners. If for some reason you ever need to revalidate or decrypt and old message, you will need these.

SSL and HTTP Client-Side Certificates

As AS2 uses the HTTP protocol it is possible to use HTTPS (SSL) instead of plain old HTTP. This encrypts the entire conversation between AS2 systems. Frankly, it is redundant and a waste of resources. The data is already encrypted and signed. No one sniffing the communications channel can do anything about it. Adding SSL to you AS2 communications only makes your system work harder to encrypt already encrypted data. Sure, it will encrypt the headers, but so what?

Additionally, using SSL over AS2 also adds the maintenance of yet another certificate. And, if for some reason you absolutely have to use an SSL certificate, then in this case DO use a very common Certificate Authority! If you don’t, your trading partners will likely have to import your certificate in all sorts of hard to reach places in their system in order to use your SSL connection.

Another unnecessary and fortunately rarely used AS2 option is to use HTTP Client-Side Certificates. That allows the AS2 client process to authenticate to the AS2 server at the HTTP level. Again, completely unnecessary as all the verification you could ever need is in the AS2 protocol itself.

To summarize all this:

1. Create your own self-signed certificates good for five, ten or more years.
2. Save the public certificate in PEM format with a meaningful file name. E-mail as a zipped attachment with all your AS2 information and contact information included.
3. Plan your certificate replacement day with at least two weeks to spare, during normal business hours at a time of low traffic, include UTC time, and give at least four weeks’ notice.
4. Save all your old private keys and public certificates (yours and your trading partners’).
5. Don’t waste time or money with Certificate Authorities
6. Don’t use SSL or Client-Side Certificates
7. Do enjoy low cost, secure, authenticated EDI communications!

Next, time now that we have explored the basics of AS2, I’m going to share with you what we have been working on behind the scenes to take AS2 to a whole new level…