About SSL communication in InfoSphere Information Server

Starting with version 11.3 of IBM® InfoSphere® Information Server, all communication between the client and services tier is done over HTTPS (SSL). This includes all clients that access the services tier, whether a rich desktop client, a browser-based client, or a command-line client.

When a client accesses the services tier over SSL, the server is authenticated by the client: the services tier presents to the client its SSL certificate and the client decides if it is valid.

A valid SSL certificate is a certificate that is signed and the signer is trusted by the client. The signer of the certificate is the entity that signed the certificate to assert that it is a valid certificate issued for this particular site. To be precise, what the server presents to the client is a chain of signed certificates: the certificate of the server itself with its signature and the certificate of the signer of the server certificate. The signer certificate can itself be signed by another signer certificate and so on. A given client decides that a server SSL certificate is valid if the client trusts any of the signer certificates present in the server certificate chain.

Remote clients have a trust store that contains the trusted signer certificates. When the client connects to the server, if the server certificate is signed by a trusted signer (a signer for which its certificate is in the client trust store), then the server is recognized as valid and no certificate prompt is displayed. If the client trust store does not contain the signer certificate that was used to sign the server SSL certificate (such as when the client first connects to the server), the server is considered untrusted and the user is prompted to validate and accept the SSL certificate.

Certificate signing

For both IBM WebSphere® Application Server Network Deployment and IBM WebSphere Application Server Liberty Profile, the default installation uses a self-signed SSL certificates (an SSL certificate that is signing itself instead of using a separate signer certificate). Specifically, in the case of WebSphere Application Server Network Deployment, a signer certificate is generated at the WebSphere cell level and a separate SSL certificate is created for each WebSphere server profile and signed by the cell level certificate. This means that client browsers will never automatically trust the services tier SSL certificates, because they are not signed by a well-known certificate authority (CA).

You can replace the default self-signed SSL certificate by a signed certificate that you purchase and obtain from a CA (such as Symantec, Thawte, and others). You could then deploy the CA-signed certificates in your desktop and browser trust stores as part of your IT policy and process. Web browsers normally have signer certificates from well-known CAs in their trust store by default.

Certificate storage for clients

For Java-based clients, the SSL configuration (and especially the trust store configuration) is specified in the <IS_install_path>/ASBServer/conf/iis.client.site.properties and <IS_install_path>/ASBNode/eclipse/plugins/com.ibm.iis.client/iis.client.site.properties files. These files contain the path to the trust store file, its encrypted password, and the type of the trust store. The files also provide the level of SSL that is used and supported. The default client trust store location as specified in the iis.client.site.properties file is <IS_install_path>/ASBNode/conf/iis-client-truststore.p12 or <IS_install_path>/ASBServer/conf/iis-client-truststore.p12. The default trust store password is iiskeypass for WebSphere Application Server Liberty Profile (unless it was changed during the installation interview) or WebAS for WebSphere Application Server Network Deployment.

During InfoSphere Information Server installation, the services tier certificate is automatically added to the ASBServer trust store for a services tier installation and the ASBNode trust store for an engine tier installation. Therefore, you will not be prompted to accept the SSL certificate for the Java-based clients. Also, because the trust store is specific to the entire node, a Java™ client that is installed on the same computer as the engine will not prompt for you to accept the certificate, because it shares the same trust store.

In a client tier only installation, however, there are no services tier SSL certificates in the ASBNode trust store and you will be prompted to accept the certificate for each first time connection to a new services tier. The reason for this is that a client tier can be used to connect to different services tiers and no specific services tier is specified as part of the installation interview process.

For browser-based clients, the trust store is specific to the web browser (such as with Mozilla Firefox), or it can be more global in the case of Internet Explorer where the trust store is a Microsoft Windows operating system level trust store. As long as you use the same browser, you will not be prompted to accept the certificate after you permanently accept the certificate the first time.

The IBM InfoSphere DataStage® and QualityStage® Designer client is unique, however, in that it uses both the Windows .NET HTTP API to communicate with the services tier as well as a Java based HTTPS communication layer. The Windows .NET HTTPS API uses the Microsoft Windows operating system trust store, which means that installing the certificate from the Designer client or from Microsoft Internet Explorer would remove any future prompt for the Designer client and browser based client access through Microsoft Internet Explorer. The Java based HTTPS communication layer uses the ASBNode trust store that used by all Java clients, but it is updated automatically if the certificate prompt for the .NET HTTPS API is accepted.

Certificate acceptance for clients

If you accept the certificate just for the session, the client side trust store on disk is not modified. The SSL certificate is accepted only for this particular client instance. If you close and reopen the client and start a new one, you will be prompted again.

If you accept the certificate permanently, the signer of the certificate (all the signers in the chain) is added to the client trust store and no certificate prompt is required in the future.

The default certificate is not signed by an official certificate authority. You can, however, use the default certificates within your organization. The certificate prompt displays a hash of the certificate, and you could notify your end-users through another secure channel the value of this hash so that the certificate can be validated by users before they accept the certificate. Another option for the browser-based clients is to distribute to all end-users the signer certificate to be loaded into the web browser trust store before they connect so that no certificate prompt is required. Or, you can choose to obtain a certificate from a CA.

Certificate removal for clients

For browser-based clients, you remove the certificate through the SSL options of your web browser.

For rich clients, you can delete the client trust store file. The client trust store is IS_install_path/ASBNode/conf/iis-client-truststore.p12 or IS_install_path/ASBServer/conf/iis-client-truststore.p12. It is re-created automatically if deleted.