Configure the TLS settings used for securing an IBM® Sametime® client, server,
and LDAP connections.
About this task
Establishing a TLS connection requires a key store and a trust store. The key store contains the
full server certificate, including the private key. The trust store contains the public certificate
of the CA (certificate authority), which has signed the server certificate.
Configure the Community Server's key store and trust store settings on the Sametime System Console. Table 1 describes the Community
Server's TLS settings, which are configured on the Sametime System Console. The procedure explains
how to access those settings.
Table 1. TLS connections settings
The TLS connections settings table lists types of connections used when
configuring TLS settings, and lists what each connection applies to. For example, the server
application connections apply to outbound TLS connections created by server applications. The
Applies to column also contains a link to a topic with more information. The table also contains a
list of additional information pertaining to the connections listed in the table.
Connection |
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 Configuring TLS encryption between the Community Server and the LDAP server |
- 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
-
On the server hosting the Sametime System Console,
log in to the WebSphere® Integrated Solutions Console as
the WebSphere administrator.
- Click .
- In the Sametime Community
Servers list, click the deployment name of the server that you want
to change.
-
On the Connectivity tab, select Strict TLS for both
the Server Encryption Mode and the Client Encryption
Mode settings.
This step ensures that all Community Server communications use TLS.
- 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.
Attention: The password stash file is not securely encrypted, so you should
protect it from unauthorized access.
- 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.
The TLS handshake protocol provides two methods of authentication using certificates:
- Server authentication: The server presents its certificate to the client, allowing the client to
authenticate the server. In a Sametime deployment, server
authentication is enabled by default and cannot be modified; a server with a key store will always
present its certificate to the client.
- Client authentication: The client presents its certificate to the server, allowing the server to
authenticate the client. For a Sametime deployment,
client authentication is optional.
Client authentication instructs the Community Server to require a client certificate when
accepting connections on port 1516. Server components that reside on the same computer as the
Community Server can use the same key store file as the Community Server for this purpose. Remote
server components will either need a copy of the Community Server's key store file, or a key store
that contains a certificate signed by the CA (certificate authority) that is trusted by the
Community Server.
The Community Mux (accepting client connections on port 1533) can be
configured to request client authentication as well. However, this is not common practice, because
Sametime clients already authenticate using passwords (or
tokens). If you do configure the Mux to require client authentication (by setting this field to
Need, you must supply each client with a personal certificate, signed by a CA
(certificate authority) that is trusted by the Mux.
- 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.
You must restart the Community Server for the TLS settings to take effect.