Configuring TLS for the Community Server

This step ensures that all Community Server communications use TLS.

• 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:
  1. 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.
  2. Start the Sametime server. Upon initialization, Sametime creates the password stash file and deletes the cleartext password from the configuration.
  3. 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.