> Configuring SSL in EMS Clients
> To use an SSL connection to the EMS server, a Java client must include appropriate JAR files in the CLASSPATH (see Table 65 below). These files are included with EMS, and also with JDK (1.4 and later).

> Table 65 SSL JAR Files
> JAR File | Included with
> jsse.jar | JDK
> jnet.jar | JDK
> jcert.jar | JDK
> tibcrypt.jar | EMS

> To use Entrust with an EMS client, you must separately purchase and install the Entrust Version 7.1 libraries. If you use the Entrust libraries, you must include them in the CLASSPATH before the JSSE JAR files. To use Entrust Version 7.1 with JDK, you must download the unlimited strength policy JAR files from Sun's website and install them in your local installation of JDK. For installation and configuration details, see Entrust Version 7.1 documentation.
> Client Digital Certificates
> When client authentication with a digital certificate is required by the EMS server (see the description of the ssl_require_client_cert parameter in tibemsd.conf), the client may combine its client certificate and private key in a single file in one of the following formats:

> ● | PKCS#12

> ● | Java KeyStore

> ● | Entrust Store

> You can also store the private key file separately from the client certificate file. If this is the case, the certificate and private key must be stored in one of the following formats:

> ● | PEM

> ● | PKCS#8

> The format of the client digital certificate and private key file depends on the SSL vendor used by the client. JSSE and Entrust support different formats and combinations of formats. For more information about formats, see your SSL vendor’s documentation.
> Configuring SSL
> A client connecting to an EMS server can configure SSL characteristics in the following ways:

> ● | Create a connection factory that specifies the appropriate SSL parameters and use JNDI to lookup the connection factory. The server URL in the connection factory must specify the SSL protocol, and the factory must specify appropriate SSL parameters.

> A preconfigured connection factory is the preferred mechanism in many situations. See Creating Connection Factories for Secure Connections and Performing Secure Lookups for details on how to create a connection factory with SSL parameters in EMS.

> ● | Dynamically create a connection factory, as described in Dynamically Creating Connection Factories and set the global SSL parameters locally using the TibjmsSSL class (Java), tibemsSSLParams type (C), or EMSSSL class (C#).

> Specifying any SSL parameters within a connection factory causes all global SSL parameters set with the TibjmsSSL class to be ignored.
> Configuring a Connection Factory
> You can configure a connection factory using the administration tool or the EMS Administration APIs. See Chapter 6, Using the EMS Administration Tool.
> When configuring a connection factory, you can specify several SSL parameters, similar to the server parameters that you can configure in tibemsd.conf.

> | When configuring a connection factory, EMS does not verify any file names specified in the SSL parameters. At the time the factory is retrieved using JNDI, the EMS server attempts to resolve any file references. If the files do not match the supported types or the files are not found, the JNDI lookup fails with a ConfigurationException.

> | Because connection factories do not contain the ssl_password (for security reasons), the EMS server uses the password that is provided in the "create connection" call for user authentication. If the create connection password is different from the ssl_password, the connection creation will fail.

> Table 66 briefly describes the parameters you can set in a connection factory, and refers to additional information about each parameter. For more information about each parameter, see the description of the equivalent parameter in tibemsd.conf on page 165.

> Table 66 ConnectionFactory SSL parameters
> Parameter | Description
> ssl_vendor | The vendor name of the SSL implementation that the client uses.
> ssl_identity | The client’s digital certificate. For more information on file types for digital certificates, see File Names for Certificates and Keys.
> ssl_issuer | Issuer’s certificate chain for the client’s certificate. Supply the entire chain, including the CA root certificate. The client reads the certificates in the chain in the order they are presented in this parameter. Example ssl_issuer = certs\CA_root.pem ssl_issuer = certs\CA_child1.pem ssl_issuer = certs\CA_child2.pem For more information on file types for digital certificates, see File Names for Certificates and Keys.
> ssl_private_key | The client’s private key. If the key is included in the digital certificate in ssl_identity, then you may omit this parameter. For more information on file types for digital certificates, see File Names for Certificates and Keys.
> ssl_trusted | List of CA certificates to trust as issuers of server certificates. Supply only CA root certificates. For more information on file types for digital certificates, see File Names for Certificates and Keys.
> ssl_verify_host | Specifies whether the client should verify the server’s certificate. The values for this parameter are enabled or disabled. By default, this parameter is enabled, signifying the client should verify the server’s certificate. When disabled, the client establishes secure communication with the server, but does not verify the server’s identity.
> ssl_verify_hostname | Specifies whether the client should verify the name in the CN field of the server’s certificate. The values for this parameter are enabled and disabled. By default, this parameter is enabled, signifying the client should verify the name of the connected host or the name specified in the ssl_expected_hostname parameter against the value in the server’s certificate. If the names do not match, the client rejects the connection. When disabled, the client establishes secure communication with the server, but does not verify the server’s name.
> ssl_expected_hostname | The name the client expects in the CN field of the server’s certificate. If this parameter is not set, the expected name is the hostname of the server. The value of this parameter is used when the ssl_verify_hostname parameter is enabled.
> ssl_ciphers | Specifies the cipher suites that the client can use. Supply a colon-separated list of cipher names. Names may be either OpenSSL names, or longer descriptive names. For more information, see Specifying Cipher Suites.
> ssl_rand_egd | The path for the entropy gathering daemon (EGD), if one is installed. This daemon generates random data for the client.

Copyright © TIBCO Software Inc. All Rights Reserved.