Embedded transport servers > HTTP (embedded) fields

HTTP (embedded) fields

An embedded HTTP server is available after a community adds a delivery exchange that uses an embedded HTTP server other than the global server. You can change the server’s settings and advanced options.

To change settings:

Select System management > Manage embedded servers. Or, click Trading configuration on the toolbar.
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 HTTP or HTTPS 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.

Host – The fully qualified domain name of the computer on which the embedded server runs. Activator detects this setting; you cannot change it.
Port – The port on which the server listens for connection requests.

The following display only for an HTTPS server.

This server requires client authentication – Select this to use the partner’s certificate to authenticate the partner when the partner connects to the server.
Add an SSL server certificate or SSL server certificate – An HTTPS server requires an SSL certificate. If the server has a certificate, the name of the certificate is displayed. You can click the certificate link to open a details page, where you can export the certificate to a file. If the server does not have an SSL certificate, you are prompted to provide one.

Advanced tab

Minimum threads – The least number of threads Activator must dedicate to the server.
Maximum threads – The most threads Activator can dedicate to the server.
Read timeout (seconds) – The maximum number of seconds the server waits when reading data from a partner.
Restartable minimum size (KB) – The minimum size of a file that triggers the system to continue the file transfer at the point interrupted before the connection was lost. The minimum size is in kilobytes. The system only resumes transfers of files that meet this minimum. The system starts over the transfer of smaller files whose processing is interrupted.
Temporary file lifetime (hours) – If attempt restarts is selected, how long the system retains a file whose transfer has been interrupted while waiting for the connection to be restored. This temporary file enables the system to resume the transfer at the point interrupted.

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, ....).
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. Activator 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 Activator earlier than Activator 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.