Configure the TLS settings used for securing an IBM® Sametime® client, server,
and LDAP connections.
About this task
Use this procedure and the information in this table to configure
your TLS settings.Note: TLS support is not available when the Sametime Community Server
runs on IBM i.
Table 1. TLS connections settingsConnection |
Applies to |
Server application connections |
Outbound TLS connections created by server applications.
See the topic Managing server connections |
Server connections |
Inbound connections accepted by the server.
See the topic Managing server connections |
Client connections |
Inbound connections accepted by the IBM Sametime Community Mux.
See the topic Managing client connections |
LDAP community connections |
Connections to the LDAP server. See the topic Using SSL to encrypt connections between the Sametime and LDAP servers |
- To use the same value for all four settings, specify the value
once in the Server Application Connections column, and do not specify
a value in the other columns. To specify a unique value for the Server
Connections, Client Connections or LDAP Connections, select the corresponding
checkbox and then enter the new value.
- Sametime clients,
such as the Sametime Connect
Client,
have their own TLS configuration. The settings in this section affect
server-side components only. In this case, the term client refers
to a server-side endpoint that initiates an outbound TLS connection;
the term server refers to a server-side endpoint that receives an
inbound TLS connection.
- Any field in this table that accepts a file name, such as trust
store file, trust store password stash file, key store file, and key
store password stash file, are specified as either an absolute or
relative path. If the file is specified in relative path form, it
is located relative to the Sametime server installation
directory.
|
Procedure
- Log in to the Integrated Solutions Console.
- Click .
- In the Sametime Community
Servers list, click the deployment name of the server that you want
to change.
- Click the TLS Configuration tab
and specify your TLS settings as appropriate to your configuration.
- Trust store file - The trust store is used
by the client side of a TLS connection to validate the server's certificate.
With mutual authentication, the trust store is also used by the server
to validate the client's certificate. You can either specify the full
path to the trust store file, or specify the path relative to the
directory where the sametime.ini file is stored.
- Trust store type - The trust store file
format of PKCS#12, CMS (KDB), or JKS. Select Use file ext. to
determine the trust store type according to the trust store file extension:
- PKCS#12 is assumed for files ending with .p12 or .pfx. PKCS#12
is the recommended certificate store type.
- CMS/KDB is assumed for files ending with .kdb.
- JKS (Java Key Store) is
assumed for files ending with .jks.
- Trust store password - The password needed
for opening the trust store. The trust store password is copied from
this table to the sametime.ini file in cleartext
form. If a trust store password is not set, and the trust store password
stash file is set, Sametime obtains
the password from the password stash file.
- Trust store password stash file - A file
containing the trust store password. Storing the certificate store
password in a stash file is useful for keeping sametime.ini file
clean of passwords. The password stash file is not securely encrypted,
and therefore it should be protected from unauthorized access. To
create the password stash file for the first time, complete these
steps:
- Set both the trust store password and the trust store password
stash file. Make sure the password stash file does not exist in the
file system.
- Start the Sametime server.
Upon initialization, Sametime creates
the password stash file and deletes the cleartext password from the
configuration.
- The next time the server is started, the password is obtained
from the password stash file.
- Key store file - The key store is used
by the server side of a TLS connection to store the server certificate
as well as chain certificates, if any chain certificates exist. During
client authentication, the key store is used by the client to store
its client certificate and chain certificates, if any exist. You can
either specify the full path to the key store file, or specify the
path relative to the directory where the sametime.ini file is stored.
- Key store type - The key store file format,
providing the same options as the trust store type setting.
- Key store password - The password needed
for opening the key store, as in the trust store password setting.
- Key store password stash file - A file
that contains the key store password, as in the trust store password
stash file setting.
- Certificate alias in key store - Necessary
only if you have a key store with multiple key certificates. In which
case, each certificate has a different alias in the key store. On
the server side, specify the alias of the certificate that identifies
the server. If the key store is used on the client side of TLS connections,
specify the alias of the certificate that identifies the client.
- FIPS 140-2 compliance - Enables compliance
with FIPS (Federal Information Processing Standard) 140-2.
- Minimum security level - The required security
level. The minimum security level controls compliance with the security
standards NIST SP800-131a and NSA Suite B.
- None - There is no standard security level
enforcement.
- NIST SP800-131a "transition" mode - The
security standard acceptable for use in federal deployments until
the end of 2013, as defined by NIST (National Institute of Standards
and Technology) Special Publication 800-131a.
- NIST SP800-131a "strict" mode - The security
standard mandatory for use in federal deployments after 2013, as defined
by NIST SP800-131a.
- NSA Suite B 128-bit level - The security
standard defined by NSA (National Security Agency) Suite B cryptography,
imposing tighter security restrictions than SP800-131a, at a minimum
security level of 128 bits, as specified in RFC 6460.
- NSA Suite B 192-bit level - The security
standard defined by NSA Suite B cryptography, at a minimum security
level of 192 bits.
- Minimum TLS protocol version - The oldest
version of the SSL/TLS protocol to negotiate during handshake. The
default value depends on the value specified for the Minimum security
level setting. Valid options are:
- SSL 3.0
- TLS 1.0 - By default, this is the minimum protocol version if
the Minimum security level setting is lower than NIST SP800-131a strict
mode.
- TLS 1.1
- TLS 1.2 - By default, this is the minimum protocol version if
the Minimum security level setting is set to NIST SP800-131a strict
mode, or higher.
- Maximum TLS protocol version - The newest
version of the SSL/TLS protocol to negotiate during handshake. TLS
1.2 is the maximum version by default.
- List of supported cipher suites - A comma-separated
list of cipher suites. Leave this field blank to enable the default
cipher suites. By default, Sametime only negotiates
cipher suites which meet this criteria:
- Not anonymous
- Comply with the Minimum security level setting
- Are supported by the selected SSL/TLS protocol versions
- Request certificate from the client - Specifies
whether the server requires a certificate from the client. There are
three options:
- None - The server does not request a certificate from the client.
- Want - The server requests a certificate from the client, but
will proceed with the handshake even if the client does not present
one.
- Need - The server requests a certificate from the client, and
fails the connection if the client does not present one.
- Trusted certificate host names - A comma-separated
list of one or more trusted hosts, to compare against the peer certificate.
This comparison takes place during the TLS handshake, when receiving
a certificate from the peer -- either when the client receives the
server certificate, or when the server receives a client certificate.
The name in the peer certificate is typically specified in either
the subject CN (common name) or the subjectAltName field.
Validation passes if there is at least one match between the name
in the peer certificate and a name in the trusted hosts list. A trusted
host name may contain the wildcard character *, indicating comparison
of domain components rather than the entire string as a whole. This
follows the matching rules of RFC 2818 section
3.1. Certificate subject validation only applies when receiving a
certificate from the peer. In order to ensure that a server performs
this comparison, the server must require a client certificate, by
setting the Request certificate from the client value to Need.
- Compare peer certificate hosts to self certificate -
Use this option to set the trusted certificate host name according
to the self certificate host name. This has a similar effect as setting
a host name in the Trusted certificate host names setting, except
the trusted host name is extracted from the certificate in the local
key store.
- Maximum number of cached sessions - The
number of TLS sessions that a server keeps in memory, for session
reuse. This option tells the server to keep a cache of the TLS session
state after the connection is closed. It is useful after temporary
network outage, when the client attempts to reconnect to the server,
by reusing the session that was established earlier. If the server
finds the session in cache, the handshake is abbreviated, consuming
less resources. If the session is not in cache, a new session is established,
including the full handshake. The default value of -1 implies no session
caching, which is generally sufficient for most Sametime deployments. A
value of 0 imposes no limit on the number of cached sessions.
- Maximum age of cached sessions - The time
to keep a session, in seconds, before deleting it from cache. The
default of -1 implies no cache, which is generally sufficient for
most Sametime deployments.
A 0 implies no limit on the age of cached sessions.
- Time before renegotiating a session - The
maximum age of a TLS session, in seconds. If the same session is used
longer than this setting, a new session is renegotiated over the same
connection. The default value of 0 implies no session renegotiation.