SSL and FIPS 140-2 support
The Tivoli Event Integration Facility supports the use of the Secure Sockets Layer (SSL) encryption and authentication protocol to send and receive events. In addition, EIF SSL connections can operate in FIPS 140-2 mode, which means the use of FIPS 140-2 approved cryptographic providers.
SSL uses digital certificates for key exchange and authentication. When a client initiates an SSL connection, the server presents the client with a certificate that is signed by a certificate authority (CA). A CA is a trusted party that guarantees the identity of the certificate and its creator. The server certificate contains the identity of the server, the public key, and the digital signature of the certificate issuer.
In FIPS 140-2 mode, all encryption and key generation functions that are required for the secure SSL connections are provided by FIPS 140-2 approved cryptographic providers. These providers are the same providers that are used for FIPS 140-2 mode for the main Tivoli Netcool/OMNIbus product. FIPS 140-2 support is provided as follows for each version of the EIF API:
FIPS 140-2 mode is facilitated by the use of IBM® Global Security Kit (GSKit).
Ensure that the path to the GSKit libraries appears in the following
environment variables:
GSKit can be accessed from $NCHOME/bin on UNIX operating systems, or from %NCHOME%\bin on Windows operating systems.Operating system Environment variables UNIX LIBPATH, SHLIB_PATH, or LD_LIBRARY_PATH Windows PATH Restriction: SSL support is unavailable in the EIF C API for platforms that are not supported by GSKit.
FIPS 140-2 mode is facilitated by the use of IBM Java™ runtime
environment (JRE) 1.4.2 or higher. The JRE must be configured for
FIPS 140-2 mode.
Enabling FIPS 140-2 mode
To enable FIPS 140-2 mode:
- Edit the EIF configuration file and set the channel_nameSSLFIPSMode property to ON.
- For all Java based applications, configure the Java runtime environment for FIPS 140-2 mode.
- If an EIF receiver application is enabled for FIPS 140-2 mode, enable FIPS 140-2 mode for all EIF client programs that connect to the receiver.
Generating and managing key and digital certificates
If you configure SSL in the EIF configuration file, use the nc_gskcmd command-line utility or the iKeyman graphical utility to generate and manage keys and digital certificates that are required for SSL communication. The following table describes the keys and certificates to manage and explains them in the context of the EIF.
| Database file | Description | Instructions |
|---|---|---|
| Keystores for the EIF receiver applications | The keystore of the receiver is a key database.
The default personal certificate of the keystore is presented by the EIF receiver
to EIF clients
during an SSL connection. This certificate can be either a self-signed
certificate that you create, or a certificate that is obtained from
and signed by a CA. The certificate must be set as the default personal
certificate in the key database of the receiver. The following database
formats are used:
|
Create keystores for EIF receiver
applications. Use the channel_nameSSLKeystore configuration keyword to configure the EIF receiver to use a key database as its keystore. If an EIF receiver application uses the configuration keyword, that is, if the channel_nameSSLRequireClientAuthentication keyword is set to YES, clients must also present a certificate during an SSL connection. The keystore of the receiver must then contain not only the personal certificate of the receiver, but also the default personal certificates of any trusted clients. Import these trusted certificates into the keystore of the receiver. |
| Keystores for EIF client applications | The keystore of the client is a key database
that contains the default personal certificates of any EIF receiver
applications that are trusted by the EIF client.
Import these trusted certificates into the keystore of the client
so that the client can connect to the EIF receiver
that is using SSL. The following database formats are used:
|
Create keystores for EIF client
applications. Use the channel_nameSSLKeystore configuration keyword to configure the EIF receiver to use a key database as its keystore. If an EIF receiver application uses the configuration keyword, that is, if the channel_nameSSLRequireClientAuthentication keyword is set to YES, clients must also present a certificate during an SSL connection. The keystore of the receiver must then contain not only the personal certificate of the receiver, but also the default personal certificates of any trusted clients. Import these trusted certificates into the keystore of the receiver. |
| Truststores | Truststores are key databases that contain certificates that are trusted by an EIF application. Any EIF application, whether client or receiver, can use a single key database to hold both trusted certificates and the default personal certificate of the application. | Use the channel_nameSSLKeystore keyword
to configure truststores.
|
| Stash file | For automatic login to access
the digital certificates, save the password for a key or trust database
in encrypted format to a stash file. Whenever the keystore or truststore
is accessed, the system checks whether a stash file exists. If found,
the file contents are decrypted and used as input for the password.
|
|
| Ciphers | The sending and receiving ends of the EIF connection must have at least one cipher in common in order for the connection to succeed. FIPS 140–2 mode restricts the ciphers that are allowed for both the C and Java versions of EIF | Use the SSLCipherList keyword
to specify the ciphers that are permitted during SSL authentication.
If no ciphers are specified or restricted, all available ciphers are
permitted.The following ciphers are available:
|