Frequently Asked Questions (FAQ)
When using the *OFTP2 module, questions may arise during initial use/setup or during operation. We are happy to provide answers to these questions in this chapter.
How can I see if the STROFTP2 command has worked?
You can get a quick overview by pressing F13 to open the i-effect logbook.
Can I send an empty file?
Often, an empty file is created and sent during testing. This is not very useful and can even lead to errors in some clients/servers. Therefore, always test with meaningful file content.
Is there any way I can test my OFTP2 connection?
We are happy to offer you the opportunity to connect to our OFTP2 test server. To set up and run this test, please contact our support team (support@menten.com).
In which directory should the trust store be stored?
You can, of course, use any directory you like to store your trust store. The default directory in i-effect is:
/home/ieffect/oftp2/
/home/ieffect/oftp2/oftp2Truststore.p12
Is i-effect *OFTP2 backward compatible with OFTP?
Backward compatibility is not yet available. This feature is currently under development.
What is a trust store or keystore and what is it used for?
The truststore and keystore are used to store certificates and keys. The two stores differ mainly in their purpose and content. During the SSL handshake, for example, the keystore is used to provide the login data, while the truststore is used to verify the login data.
A keystore contains your own private key and the server certificate. The keystore is required if you are using an OFTP2* server with SSL or have enabled client authentication. The keystore therefore acts as a certificate store.
A trust store contains the certificates of communication partners or trusted certification authorities (known as CAs). Third-party certificates (from communication partners) are stored in the trust store. The trust store does not contain any private keys. The partner's certificate is used in *OFTP for file encryption.
Which programme is used to manage the keystore or truststore?
The i-effect installation includes the KeyStoreExplorer:
/i-effect/v2r6m0/CRYPT/tools/KeyStoreExplorer
Sollten Sie den KeyStoreExplorer nicht mehr auffinden, können Sie ihn jederzeit unter der Webadresse des Anbieters herunterladen: http://keystore-explorer.sourceforge.net/
What is a .p12 file?
A .p12 file is a file in the PKC #12 (Public-key cryptography standards #12) container format. A large number of different certificates can be stored as a single file in the container (the container file, e.g. .p12).
Which receiving path is used when exchanging data?
As in every module, the order of settings is as follows:
Partner profile (menu item 50)
a. *DEFAULT for using the receiving path from the communication profiles or your own entry for another path.
Communication profile of a server *RECEIVE (menu item 52)
a. is taken from the module configuration.
What basic settings can be configured for the *OFTP2 module?
Within the module configuration (menu item 80), you can specify the following settings for all *OFTP2 clients and servers:
Possible value | Description | |
Maximum client threads | 1-50 | The maximum number of simultaneous connections to your *OFTP2 server. |
Maximum send retries | 0-50 | The number of retries to resend a file that could not be sent on the first attempt. |
Send retry pause | 5 - 99000 | Waiting time in seconds between connection attempts. |
Client timeout | 5 - 36000 | Time in seconds that a user can be inactive before the connection is terminated by the server. |
Client internal timeout | 5 - 36000 | Time in seconds after which a connection attempt is considered to have failed. |
Which key/certificate is selected?
If no key or certificate needs to be specified, all information on the intended use from the configuration is tried out. This is the case, for example, when checking the signature. The usual i-effect hierarchy is used for testing: partner profile, then communication profile. If an entry is marked as active, it is selected first at its hierarchy level.
If the key or certificate must be specified, the first key or certificate is selected. This is the case, for example, when signing. If an entry cannot be used, e.g. because the keystore path was specified incorrectly, the next entry is selected. The search is performed in the usual i-effect hierarchy: partner profile then communication profile. If an entry is marked as active, it is given priority at its hierarchy level.