FTP (embedded) fields

An embedded FTP server is available after a community adds a trading or application delivery exchange that uses an embedded FTP server. You can change the server’s settings and advanced options.

To change settings:

  1. Select System management > Manage embedded servers. Or, click Trading configuration on the toolbar.
  2. On the Communities page, click the link near the bottom of the page named Manage all embedded servers.

The following are the maintenance fields for an embedded FTP transport server that has been added by a community.

Settings tab

  • Server name – A name you give the transport server to distinguish it from other embedded servers. This field gets its initial value when you type it in the delivery exchange wizard.
  • Port – The port on which Interchange listens for connection requests.
  • Add an SSL server certificate or SSL server certificate – For optional SSL, the server requires an SSL certificate. If the server has a certificate, the name of the certificate is displayed. If the server does not have an SSL certificate, you are prompted to provide one.
  • For FTP, once a certificate is added the server becomes FTPS using explicit SSL. Non-SSL connections are not allowed. If the certificate is removed, the server becomes FTP once more.
  • This server requires client authentication – Select this to use the partner’s certificate to authenticate the partner when the partner connects to the server. This field displays only if you have added an SSL certificate for the server.
  • Use implicit SSL – Select this if you want to use implicit SSL rather than explicit SSL, which is the default mode. FTP supports two methods to accomplish security through a sequence of commands passed between two computers. The sequence is initiated with explicit (active) or implicit (passive) security.
    • Explicit security. To establish the SSL link, explicit security requires the FTP client to issue a specific command to the FTP server after establishing a connection. The default FTP server port is used.
    • Implicit security. Implicit security begins with an SSL connection as soon as the FTP client connects to an FTP server. The FTP server defines a specific port for the client to be used for secure connections.
  • This field displays only if you have added an SSL certificate for the server.
  • External host or IP address – The fully qualified domain name or IP address that a community’s partners must use to connect to this embedded server. Interchange supplies a value based on the name of the host computer. In many cases you must change this to the external name used by your network firewall or load balancer. Contact your network administrator if you need help with this field.
  • External port – The port number that a community’s partners must use to connect to this embedded server. Contact your network administrator if you need help with this field.

DMZ ports tab (trading only)

Note   This tab displays in the user interface only if your software license enables Secure Relay DMZ nodes. The tab only applies to servers used for trading and not integration.
  • Enable DMZ port forwarding – Select this check box if you want the external firewall or load balancer to send inbound connections to Secure Relay DMZ nodes rather than directly to embedded servers in the protected network.
  • In the simplest case there is one DMZ port with the same value as the corresponding embedded server port in the protected network. If you add a machine to your cluster and return to the DMZ ports tab, another DMZ port automatically is added in sequence. This happens because every machine in the cluster that can host the embedded server must be assigned a unique corresponding port in the DMZ.
  • Click the port field to display a list of ports already in use.
  • Enable security termination in DMZ – Select this check box to have various security functions performed in the DMZ. If connections are via SSL, the secure connection is terminated at the router agent in the DMZ. For delivery exchanges that require a user name and password to connect (for example, FTP, SFTP, WebDAV), the router agent authenticates the user.
  • Enable IP address checking in DMZ – Select this check box to have Interchange check partners’ IP addresses against a whitelist of authorized IP addresses. Connections from unknown IP addresses are not allowed.
    • Match IP address against partner definition – When IP address checking is enabled, select this check box to have the router agent check whether the partner is registered to the IP address. If not selected, the agent only checks the user’s credentials. (This control is not available to all types of servers.)
  • Zone – If you want to receive messages through a Secure Relay DMZ zone, select a zone. This drop-down field is available only if zones have been set up.
  • See Port forwarding details for more information.
  • FTP passive ports – If you enable port forwarding for embedded FTP, go to the Advanced tab and specify a range of ports. The default value of 0 is not compatible with DMZ nodes.
  • When port forwarding is enabled for an embedded FTP server, the same range of passive ports specified on the Advanced tab also is used in the DMZ. Temporary forwarding rules are established and canceled as FTP data connections come and go. Make sure none of the passive ports in the range is in use on any cluster machine or any DMZ machine.
  • If you do not allow SSL connections, the external firewall automatically opens FTP passive ports on an as-needed basis, assuming you explicitly tell it which control ports are being used for FTP. If you allow SSL connections, you must open the entire range of passive ports on the firewall. Otherwise it cannot eavesdrop on the control connection to dynamically open the passive ports.
  • Configuring the load balancer to work correctly with DMZ nodes and passive FTP ports requires special care. See the example script in <install directory>\util\dmzNode\ loadBalancer for more information. This script is intended for use by someone who is familiar with the complexities of the FTP protocol and load balancer configuration.

Advanced tab

  • Maximum concurrent connections – Default = 500. The maximum number of concurrent connections that can be accepted by the embedded server from a trading partner or back-end application.
  • For example, if the value is 100 connections and there are 150 messages to consume, Interchange opens only 100 connections for the connecting partner or back-end application. The remaining 50 messages must wait until connections become available.
  • If you are operating in a cluster environment, this is the total number across the entire cluster, no matter how many nodes are running.
  • Read/idle timeout (seconds) – The maximum number of seconds the server waits when reading data from a partner.
  • Allowed passive ports – Ports for inbound passive data connections from FTP clients. You can enter multiple ports. Each port number must be separated by a comma or you can specify a range of ports. The following example uses comma-separated port numbers and a range of ports:
  • 50000,50001,50010-50020
  • No other computers other than the machine running Interchange server can use this same range of ports. If you operate multiple instances of Interchange in a cluster, the same applies to all machines in the cluster.
  • If clients are to make secure data connections to the server, these ports must be opened in the firewall. If secure connections are not required, most firewalls are FTP-aware and automatically open the data connection port based on the fact that a client already has a connection to the FTP control port.
  • If you use a Windows operating system, we strongly suggest disabling the Windows firewall. Use instead an FTP-aware external firewall. Otherwise, you must add an exception for each passive port in the Windows firewall.
  • In the case of SSL connections, even FTP-aware firewalls cannot dynamically open passive ports. If clients are to connect over SSL, open the same range of ports in the firewall as you specify in this field. Failure to do so results in clients experiencing hangs when performing LIST, GET and PUT operations.
  • For help with this field, ask your network administrator.
  • Override SSL and TLS cipher suites – Select this option and then use the Add and Remove buttons to specify the cipher suites supported for the embedded server.
  • If you do not select this option, all cipher suites are supported by default. Keeping the default cipher list is less secure than specifying a restricted set of cipher suites.
  • The cipher suites that are displayed in the "Available" column depend on your runtime environment (JRE version, IACK or FIPS enablement, Secure Relay configuration, ....).
  • The default order in the "Available" column is the preferred order of use. Once ciphers are moved to the Selected column, you can arrange the order. Interchange uses the ciphers in the order listed.
  • A cipher suite is a collection of security algorithms used in making connections via Secure Sockets Layer or Transport Layer Security. For example, an SSL or TLS protocol requires signing messages using a message digest algorithm. But the choice of algorithm is determined by the particular cipher suite being used for the connection. Typically, you can select an MD5 or SHA digest algorithm.
  • Of the many algorithms for encrypting data and computing the message authentication code, there are varying levels of security. Some provide the highest levels of security, but require a large amount of computation for encryption and decryption. Others are less secure, but provide rapid encryption and decryption. The length of the key used for encryption affects the level of security. The longer the key, the more secure the data.
  • The option for overriding cipher suites lets you select the level of security that suits your needs and enables communicating with others who might have different security requirements. For example, when an SSL connection is established, the client and server exchange information about the cipher suites they have in common. Then they communicate using the common cipher suite that offers the highest level of security. If they do not have a cipher suite in common, secure communication is not possible.
  • In versions of Interchange earlier than Interchange 5.9, cipher suites configuration was handled by a file named sslciphersuites.xml. As data in that file is saved in the database, the custom cipher suites configuration is retained upon upgrading and is displayed in the Selected list under the option in the user interface. The sslciphersuites.xml file is no longer used.

Trusted roots certificates tab

The trusted roots certificates tab displays the roots of clients’ certificates that a server trusts. In the case of a self-signed certificate, the trust is for the certificate itself, as a self-signed certificate is a root certificate. In the case of a certificate authority certificate, the trust is for the root certificate in the chain of trust of a client’s certificate.

Home directories tab

Use the Home directories tab to force messages to be directed to a single directory. Specifying home directories is optional.

Home directories are used by FTP and SFTP embedded servers to direct messages to a single subdirectory for a transport user. For example, a community has three delivery exchanges for receiving messages from partners. All exchanges use the same embedded server and the same user to connect to the server. The user subdirectories for each exchange are different. The subdirectories are:

Exchange point

User

User subdirectory

AS3

foo

foo\AS3

Secure file

foo

foo\SecureFile

No packaging

foo

foo\NoPackaging

Normally, when a remote partner connects to the server as user foo and sends messages via AS3, the messages are written to the foo\AS3 subdirectory. Messages sent via secure file and no packaging are similarly routed to the designated subdirectories for those exchanges.

However, if a home directory for the foo user is set as foo\home, all messages are re-routed to the home directory. This occurs regardless whether a partner uses the AS3, secure file or no packaging exchange to send messages to the community

If the advanced control is enabled on a delivery exchange to allow clients to add and remove subdirectories, the home directory for the embedded server is honored. This means the embedded server's settings take precedence over the settings for the exchange point, which is hosted on that embedded server. In this case, messages are re-routed to the home directory even when the transport user sends to the subdirectory the user created earlier.

If a user has an FTP or SFTP client and logs on to the embedded server directly – outside of a messaging protocol – the client connects to the home directory rather than to the user subdirectory.

Related topics

Related Links