SSL provides a secure connection between a client and server. The SSL protocol runs above TCP/IP and below higher-level protocols such as HTTP, LDAP, and IIOP, and provides privacy for the higher-level protocol data. Depending upon the SSL configurations of both the client and server, various levels of trust and privacy are established. Understanding the basic operation of SSL is very important in order to properly configure and to therefore achieve the desired level of trust and privacy for both client and application data.
SSL uses a technology known as public key cryptography. This technology is based upon something called key pairs, in which one key in the pair is public and the other is private. An important mathematical property of a key pair is the following: if data is encrypted with one key; it can only be decrypted with the other key in the pair. This property is fundamental to the operation of SSL in order to establish both trust and privacy. For example, trust in a server can be established as follows:
Trust between a client and server is often not directly established. It is not administratively feasible for a client to know the public key of every server it wants to interact with. Trust is therefore established indirectly through a trusted third party known as a CA (Certificate Authority). The client trusts the CA, and the CA certifies the server; therefore the client can indirectly trust in the identity of the server.
The CA certifies the server by issuing what is known as a digital certificate to the server. A certificate contains information such as:
Note that a digital certificate can be issued by a CA, or it can be self-signed in which case the entity being certified and the issuer are the same.
SSL requires that the server always send it's certificate to the client; that is, the server is always authenticated to the client. The client trusts the server if the server's certificate was issued by someone that the client trusts. The client consults a file containing signer certificates, called an SSL key file, in order to determine if it should trust the signer/issuer of the server's certificate. This SSL key file may not only contain signer certificates, but also personal certificates. Stored along with each personal certificate in the SSL key file is the private key. This is the private key associated with the public key in the certificate and is used to create a digital signature.
SSL does not require that the client be authenticated to the server; that is, the client will only send it's certificate to the server if the server requests it. Furthermore, a server only requests a certificate from the client if client authentication is enabled in the server's SSL configuration. By default, client authentication is disabled.
Because the server must always authenticate itself to the client, the server's SSL key file must always contain a personal certificate. The client's SSL key file need only contain a personal certificate if client authentication is enabled on the server.
The strength of the encryption algorithm which is used to provide privacy for an SSL connection is dependent upon the configuration of both the client and server. Encryption algorithms are packaged together into entities called cipher suites. During the SSL handshake (the initial exchange of information) between the client and server, the list of allowable cipher suites is exchanged. SSL always chooses the strongest cipher suite which is in common between the client and server.
The following diagram depicts the typical flow of a request from a browser to
a WebSphere Application Server.
The browser sends a request to the Web server over connection A. The WebSphere plug-in recognizes that the request is intended for WebSphere Application Server and so forwards it over connection B to the application server. Each connection has both a client and a server. For connection A, the browser is the client and the Web server is the server. For connection B, the WebSphere Application Server plug-in is the client and the WebSphere Application Server is the server.
In this scenario, either or both of these connections can be an SSL connection. For example, if the link between the Web server and the WebSphere Application Server is thought to be a "safe zone", it may be desirable to forward a request to the application server over a non-secure TCP connection B even though connection A was a secure SSL connection. This may be desirable to increase performance because a TCP connection is much faster than an SSL connection; however, if your WebSphere Application Server is running sensitive applications which require privacy and trust, both connection A and connection B should be SSL connections.
It should be noted that for an SSL connection, each client and each server have their own SSL configurations. Therefore, if both connection A and B are SSL connections, there are a total of four SSL configurations: the SSL configuration of the browser, of the Web server, of the WebSphere plug-in, and of the WebSphere application server.
The SSL implementation used by the application server is the IBM JSSE (Java Secure Sockets Extension). Configuring JSSE is very similar to configuring most other SSL implementations (for example, GSKit); however, a couple of differences are worth noting.
SSL/JSSE is used by multiple components within WebSphere Application Server in order to provide trust and privacy. These components are the HTTPS server, the ORB (acting as a client and a server), and the LDAPS client. The LDAPS client is used to connect to an LDAP user registry and is present only in WebSphere Application Server Advanced Edition; furthermore, note that the LDAPS client resides only in the admin server, not in the application server. Nevertheless, configuring SSL through an SSL settings GUI panel is essentially the same for all components.