Secure EDI with Certificates

The AS2 communications standard provides a very high level of security through the use of transport and message encryption and signing. For those unfamiliar with AS2, please read the introduction on the AS2 standard.

Transport Encryption

Transport encryption is handled in the same way as nearly all web pages on the internet today, that is SSL (Secure Sockets Layer, more commonly refereed known in the form of HTTPS). This encryption relies on Public Key Infrastructure (PKI), and allows for secure data transfer between 2 parties, without the need for any special certificate setup.

All inbound traffic to QBridge is via a HTTPS web address, and is thus encrypted. Outbound connections to a trading partner can be via HTTPS (encrypted), or HTTP (un-encrypted). EIS always recommends using a HTTPS address for calling an EDI partner, but this choice is up to you (and what the EDI partner offers).


Message Encryption and Signing

In addition to transport encryption, AS2 messages can be encrypted and signed (signing provides a way for EDI partners to verify the user who sent the AS2 message is who they say they are). Message signing and encryption requires you to provide a set of certificates to EIS.

Step 1 – Creating a an encryption certificate:

There are 2 ways of obtaining the required certificate pair, these are:

Self Signed Certificate

A self signed set of certificates can be useful in test environments, or where security is less important (self signed certs miss out on a number of features in PKI, and are generally considered insecure by web browsers etc.).

  • Download OpenSSL (A quick google search may be quickest way to get that latest version)
  • Generate the public and private keys for your certificate:
openssl req -newkey rsa:2048 -sha256 -nodes -keyout private.key -x509 -days 365 -out public.crt
  • Open SSL will ask for some details of your organisation (don’t worry, if you make an error here, it won’t affect the validity of a self-signed cert):
Generating a 2048 bit RSA private key
 …………………….+++
 ……………………………….+++
 writing new private key to 'private.key'
 You are about to be asked to enter information that will be incorporated
 into your certificate request.
 What you are about to enter is what is called a Distinguished Name or a DN.
 There are quite a few fields but you can leave some blank
 For some fields there will be a default value,
 If you enter '.', the field will be left blank.
 Country Name (2 letter code) [AU]:UK
 State or Province Name (full name) [Some-State]:
 Locality Name (eg, city) []:
 Organization Name (eg, company) [Internet Widgits Pty Ltd]:EIS-Demo
 Organizational Unit Name (eg, section) []:IT
 Common Name (e.g. server FQDN or YOUR name) []:as2.enterpriseintegrationsolutions.com
 Email Address []:
  • Create a PFX file for uploading to EIS (it will prompt for a password, please choose something secure, and do not loose this password, you will need it when uploading the certificate to the EIS portal:
 openssl pkcs12 -export -in public.crt -inkey private.key -out private.pfx 

You know have 2 files of importance, public.crt and private.pfx.

Trusted Certificate

It’s recommended that for production environment, a trusted certificate is used for both encryption and signing. A trusted certificate is one purchased from a reputable certificate authority, such as:

When purchasing a certificate, you will eventually end up with either a separate public and private certificate file (as per our self-signed scenario), or you will end up with a single pfx (or p12) certificate file. If you only have the single file, you can use OpenSSL (or the Windows certificate store) to extract just the public certificate key from your pfx file:

openssl pkcs12 -in yourCertificate.p12 -nokeys -out public.crt

Step 2 – Create a signing certificate

A certificate used for signing is virtually no different to the encryption certificate just created (or purchased). In fact, some organisations will use the same certificate for both.

To create a separate certificate, follow the guide in Step 1.

Step 3 – Upload the certificate to your EIS console:

The hard bit is done. You can now browse to your EIS console, and select ‘AS2 Configuration’ > ‘Local Host’ and then click on the ellipse next to ‘Inbound Decryption’ and select ‘Upload’:

Upload the certificate (p12 or pfx) file created (or purchased) in step 1. You will be prompted for the certificate password when uploading. Once uploaded, the private key contained in this certificate will be used for decrypting all incoming as2 messages. The public key for this certificate (this will most likely be a crt, cer, or p7b file) should be given to your trading partner. They will use this public key for encrypting messages.

The outbound signing certificate is uploaded in exactly the same way. Again, the public key for this certificate would be provided to your trading partner. They can use this certificate to verify that messages received are actually from you, and not a 3rd party pretending to be you (as your organisation is the only one with the private key).


After completing the above steps you are now ready to receive encrypted messages, and sign outgoing messages. To send encrypted messages you will need to upload the certificates to provided to you by your trading partner. This is covered in the getting started guide: https://enterpriseintegrationsolutions.com/as2-cloud-relay-getting-started-guide/