Settings

(1) Local certificate (encryption): A local certificate (with private key) can be assigned to the channel here. This certificate is used to decrypt the incoming data encrypted by the partner. If no local certificate has been assigned under (3), it also serves to sign outgoing data. Note: For AS2 over HTTPS, a client certificate may additionally be required for the outgoing HTTPS connection. The certificate in (1) is also used for this purpose. See also section Authentication by Client Certificate. The external server is allowed to use a self-signed certificate for HTTPS. The import of the server certificate as a partner certificate is not required.

(2) Partner certificate (encryption): A partner certificate, i.e. the public part of a certificate of your partner, can be assigned to the channel here. This certificate is used to encrypt the data to be sent. If no partner certificate has been assigned under (3), it also serves to check the signature of received data.

(3) Local certificate (signing) , Partner certificate (signing): See (1) and (2).

(4) Send signed , Send encrypted: Specifies whether data sent to the partner system will be signed and/or encrypted. The data is signed with the signature algorithm set in (6) and encrypted using the encryption algorithm set in (9).

(5) Receive signed , Receive encrypted: If set, data that is not signed or encrypted is rejected. Attention: If the partner sends encrypted or signed data, a local certificate to decrypt the data or a partner certificate to check the signing must still be available, even if the option here in (5) is not set. Otherwise, the message would not be decryptable or the signature could not be checked. But the message will not be rejected.

(6) Remove security settings of signature: Removes a security attribute of the signature. Note: Only needed in rare cases for old AS2 connectors. Note: See also https://datatracker.ietf.org/doc/html/rfc6211.

(7) Sending chunked data: Divides messages into smaller chunks (CTE). Note: Only needed in rare cases for old AS2 connectors.

(8) Signature algorithm: Determines which algorithm is used to sign sent data. The setting is only effective if the checkbox Send signed (4) is set.

(9) Encryption: Determines which algorithm is used to encrypt send data. The setting is only effective if the checkbox Send encrypted (4) is set.

(10) MDN type , MDN URL: Here, you can define how the channel sends the MDN to the communication partner. The following possibilities are available.

• System setting. The settings in configuration file ./etc/as2.xml are used.

• Synchronous. A synchronous transmission of the MDN is used.

• Asynchronous. An asynchronous transmission of the MDN is used. If no URL is defined in the configuration file ./etc/as2.xml, it must be specified in field MDN URL. An entry in the configuration file would look as follows.

  <Set name="defaultMDNAsynchronousURL">http://100.1.20.45:8080/partner/AS2Retrieve</Set>

(11) MDN digest alg: The algorithm by which the so-called digest of the MDN is calculated. A digest is a hash value of the sent message. The digest can be used to ensure that the MDN is actually referring to the sent message.

(12) Error handling: Opens another dialogue, which can be used to determine how to react to various errors. The values set there should only be changed in exceptional cases.

(12.1) OK, accept this way: The data is accepted and passed on for further processing (response code "processed").

(12.2) Edit error: The data is accepted but is not passed on for further processing (response code "processed/error").

(12.3) Edit warning: The data is accepted and passed on for further processing, although something unforeseen has happened. Such a response can, for example, be given if the sender of the data could not be authenticated, but the data should still be processed (response code "processed/warning").

(12.4) Failed: The data is not accepted (response code "processed/failure").

Note: For the response codes see also section Comm-Log (Input Agent).