|If you are simply following along the quick-start guide, you could skip these options. However if your partner has provided a detailed AS2 profile (configuration of expected format for sent/received messages), consider adjusting these settings as well.|
If your partner URL is HTTPS/SSL/TLS (starts with
https://), and the partner’s endpoint (server) does not have a
trusted TLS/HTTPS certificate,
you may want to import that certificate, or one of its issuer certificates, under this option.
Turn on the Upload New switch to upload the TLS certificate received from your partner.
If you wish to assign an already uploaded TLS certificate, turn off the Upload New switch and select the certificate from the drop-down.
Enable this when you wish to send encrypted messages to your partner (or your partner requests you to do so).
|In most cases, encryption must be enabled - even if your partner did not request it explicitly.|
AS2 Gateway will use the Encryption Certificate that you provided, earlier in the partner configuration, to encrypt outgoing files/payloads before sending them to your partner’s URL.
|Encryption Certificate usually contains the public key of your partner. Once you encrypt your message with it and send it to them, they will use their corresponding private key to decrypt the received data. The secrecy of the private key ensures that only your partner can decrypt and make sense of your transmission. This covers the confidentiality aspect of AS2 security.|
Enable this when you wish to include a digital signature when sending messages to your partner (or your partner requests you to do so).
|In most cases, signing must be enabled - even if your partner did not request it explicitly.|
AS2 Gateway will use the private key of your trading station to sign outgoing payloads before sending them to your partner.
When you shared your station’s partner configuration with your partner, they would have received the public certificate of your station. Using this, they can verify the signature generated during sending of the message, and ensure that:
This covers the authenticity, integrity and non-repudiation aspects of AS2 security.
Choose the hashing algorithm that would calculate a hash (digest) over the message content, when signing an outgoing an AS2 message or response MDN/receipt.
It is recommended to choose a "strong" algorithm that generates a longer hash (e.g.
|Although this is a relatively advanced option, it currently appears under the encryption/sign certificates section itself.|
If your partner has provided a "signature" or "verification" certificate, you can configure it here. This certificate will be used to verify the digital signatures of messages or MDNs (receipts) that your partner will send to you. Hence, unlike the encryption certificate that is used for outgoing messages, this will be used on incoming messages.
In most cases, partners use the same keypair for decrypting incoming traffic and signing outgoing traffic; hence, unless your partner has explicitly instructed you to use a different, specific certificate for signing, you would keep this option disabled.
|Do not confuse this with the HTTPS/SSL/TLS certificate; if your partner has a HTTPS URL and has sent you only one additional certificate (in addition to the "partner" or "encryption" certificate), it is probably the TLS certificate of their HTTPS endpoint - unless it is explicitly marked as a signature certificate.|
Enable this when you wish to compress your files/content before sending them to your partner (or your partner requests you to do so). This can potentially save bandwidth and speed up transmission.
You can choose to run the compression:
Before signing and/or encryption, i.e. on the original set of files that you included in the message; in this case, the partner would need to first decrypt/verify the payload, and then decompress it
After signing and/or encryption, i.e. compression would be the last (outermost) action or "layer" on the payload; in this case, the partner would need to first decompress the payload, and then decrypt/verify the content
Enable this when you want your partner to send back a MDN (acknowledgement, receipt) for each message that you send them.
|An MDN ensures that your partner received your message, and acknowledges that they managed to successfully verify and retrieve the content (or, notifies that there was an error when trying to do so - via an error MDN). This covers the non-repudiation aspect of AS2 security. Once the MDN is received, you should be able to see its status (success: green, error: red, etc.) against the message, on your outbox.|
An AS2 system can send MDNs in one of two ways:
synchronous: the MDN will be sent back on the same connection (HTTP/S channel) established for the original AS2 message, as the HTTP response to the original HTTP request that contained the AS2 message
asynchronous: the original AS2 message connection would be closed gracefully (e.g. with a HTTP 200 (OK) or 202 (Accepted) response), and the recipient (partner) will later send the MDN back to the sender (station) as a new HTTP request (on a new connection).
By enabling the Request Asynchronous MDN option, you request your partner to use the second approach.
In this case, AS2 Gateway will inform the partner system where (the URL/endpoint) to send the asynchronous MDN,
by including an additional
Receipt-Delivery-Option HTTP header on each AS2 message.
This URL is usually
test-service.as2gateway.com variant); HTTPS is not supported.
Similar to signing outgoing messages, you can request your partner to sign the MDNs that they send back to you.
|Just as described before, this ensures that the MDNs are originated from your partner (private-key signature) and they have not been tampered with (signed content hash).|
If you notice that your outbox AS2 messages are stuck in "MDN pending" status for prolonged amounts of time, your partner’s AS2 system may not be supporting the current MDN configuration. Contact your partner to learn the supported MDN scheme (e.g. synchronous, not signed), and update the AS2 Gateway MDN configuration accordingly.
Some trading partners require you to send additional HTTP headers along with a standard AS2 message (e.g. for authentication or routing purposes). You can use this option to add one or more such headers as key-value pairs.
For example, to add the two headers
X-Cyclone-Routing-Key: ACME_PROD Authorization: Basic abcdefgh1234
Click +, to add a new key-value pair.
X-Cyclone-Routing-Key (excluding the colon and space, `: `) on the Header Key field.
ACME_PROD on the Header Value field.
Repeat above steps for the second header: key
To remove an already defined header, click the dustbin-icon button against that row.
Header keys cannot be left empty. If you submit an entry with an empty header key, it will be ignored.
Headers will be included in the AS2 message (HTTP request) in the order they are defined.
If your partner provides you with a username/password pair to use as basic authentication, you need to derive the header value as:
E.g. for username
You can also use a secure utility, such as this page, to generate the header.
Once added, these headers will be included in every AS2 message that you send to this partner. If you want to:
contact AS2 Gateway Team for more information.