Settings

(1) Allowed sub types: Specifies for which subtype the channel may be used.

• OFTP via TCP/IP.

• OFTP via TLS .

(2) Local certificate (encryption), Partner certificate (encryption): Here the local certificate (with private key) is assigned. Only needed for OFTP2 to decrypt received encrypted files and to sign sent files. For OFTP2 via TLS (1), a client certificate for the TLS connection may additionally be required for outgoing connections. The local certificate will also be used for that.

In addition, the partner certificate is assigned here, i.e. the public part of the certificate of the partner to which the channel is assigned. Only needed for OFTP2 to encrypt sent files and to check received signed files.

(3) Local certificate pending, Partner certificate pending: Should your local certificate or the partner certificate expire soon and you already have a corresponding new certificate, then you can add the new certificate here. Once the old certificate has expired, then the pending certificate is used.

(4) Do not create user directory again: If this checkbox is set, the user directory is not created again when saving the channel. Note: The user directory is created when the channel is created, i.e. the first time it is saved. The checkbox is only visible if the channel already existed, i.e. not when it is created. If the checkmark is removed and the channel saved, the directory will be created again, but afterwards the checkmark will be set again automatically. Note: See also item (14).

(5) Send signed: Specifies whether files are to be signed or encrypted when sent to the partner system. The files are signed with the signature algorithm set in (11) and the local certificate (2). The files are encrypted using the encryption algorithm set in (13) with the partner certificate (2).

(6) Receive signed: If this checkbox is set, an error is generated if the received files are not signed and the files are rejected. If the checkbox Receive encrypted is set, an error is generated if the received files are not encrypted and the files are rejected.

(7) Suppress restart: The OFTP restart functionality can be suppressed.

(8) Expect signed EERPs: If set, the partner requires signed receipt confirmations (EERPs, End to End Responses) for outgoing data transmissions to the partner.

(9) Strict SFID check: If this checkbox is set then only files with an additional SFID combination listed in (19) will be accepted, otherwise they will be rejected.

(10) Automatic certificate exchange: Must be set if the automatic certificate exchange is to be used. See the corresponding section below.

(11) Signature algorithm: Determines the algorithm with which sent files are signed. The setting only works if the checkbox Send signed (5) is set.

(12) SecAuth authentication: SecAuth is an authentication by client certificate. The local certificate (2) is used for that, comparable to the pubkey authentication with SSH.

(13) Encryption: Determines the algorithm with which sent files are encrypted. The setting only works if the checkbox Send encrypted (5) is set.

Note: The signature and encryption algorithm specified by the partner should always be explicitly set to avoid problems in case Odette specifies a new default value.

(14) Input directory, Output directory: The directory, in which the received files or the files to be sent are stored. See also section Home folders. See also item (4).

(15) Partner certificate subject: Input field for the subject of the X.509 certificate to detect incoming partner certificates during the automated certificate exchange, e.g. *CN=OFTP2FIRMAX* or *CN=aaaa*. See the corresponding section below.

(16) TLS name: Here, the name of the ODETTE TSL list is expected. This is the name of an ODETTE-maintained list of allowed certification authorities (CAs) to be accepted for automated certificate exchange. Practically, the value will always be OFTP2.

(17) TLS cipher: The TLS encryption algorithm. This value should only be set to resolve TLS handshake issues.

(18) Credit Count, X.25 window size, Exchange buffer: Here, the value can be set to 0 in virtually all cases. Should other values be necessary in rare cases, please contact our support.

(19) Additional certificates/SFIDs: See section "Additional certificates/SFIDs" below.

(20) OFTP pickup: Starts the pickup test (in the background) for the configured partner.

(21) Connection test: An attempt is made to send a file TEST with the content TEST to the configured partner.

Note: The tests (20) and (21) always refer to the stored channel. Please save the channel before the test if you have made any changes.

Automatic certificate exchange

The exchange of local certificates in (2) and (3) can on the one hand be done manually, but it can also be carried out automatically. For this purpose, the checkbox (10) must be set.

Likewise, a partner can send you a certificate and you can enter it manually in (2) and (3). In addition, the OFTP protocol offers the possibility that the partner sends you such a certificate directly via this OFTP channel. If checkbox (10) is set and the subject in (15) matches, the partner certificate is automatically exchanged. Note: For the sake of understanding it should be mentioned that in the vast majority of cases you receive 'normal' data via OFTP, but in rare cases this data can also be a certificate (or up to 5 certificates). So the partner must tell you the appropriate subject before the exchange.

Additional certificates/SFIDs

If checkbox (9) is not set, all incoming files via this channel will be accepted. If the checkbox is set, you can restrict the accepted files to certain SFID combinations. So a file will only be accepted if its SFID combination matches an entry in the following list.

(22) Additional certificates/SFIDs: List of SFID combinations you have entered. Using the context menu, you can open, edit, delete and create an entry. See the following screenshot.

The local certificate selected in (2) is used by default both for SecAuth (12), as well as for the decryption of received data or the signing of sent data. Similarly, the partner certificate selected in (2) is used for the encryption of sent data and the signature check of received data. Only one local certificate and one partner certificate can be assigned here in the channel. However, here it is possible to assign individual certificates for these tasks for certain SFID combinations.