Understanding SSL-Enabled REN Servers
You can enable a secure channel of communication between the clients and the REN server by enabling SSL on the REN server using openssl. The SSL protocol runs above Transmission Control Protocol/Internet Protocol (TCP/IP) and below higher-level protocols, such as HTTP and IMAP4. By using TCP/IP on behalf of higher-level protocols, openssl allows an SSL-enabled server to authenticate itself to an SSL-enabled client, a client to authenticate itself to a server, and both machines to establish an encrypted connection.
REN servers require digital certificates to work in SSL mode. The servers pick up the certificates from the keystore in the PeopleTools database or an external keystore. The certificates must be imported into PeopleTools database from Certificates that are installed in the database will have a unique combination of certificate type and alias.
The certificate type that is used for the server should be of the type CERT, and the alias is <machine name>.<domain name>. When the certificate is configured with a unique alias name, it should be associated with the REN server that is SSL-enabled. The REN server loads its server certificate from the database at the start-up.
For server authentication, the server sends its certificate to the client as a part of the SSL handshake and the client authenticates by verifying the Certificate Authority (CA) of the certificate against its trusted keystore. When the REN server is configured for SSL, all clients must trust the CA of the server certificate to participate in a successful communication. The keystore can either be in the database or an external keystore.
Client authentication verifies the clients's authenticity to participate in a communication with the server. When the REN server is configured for client authentication, all clients must supply a valid client certificate to participate in a successful communication.
All clients must use the REN cluster's HTTPS URL to communicate in the SSL mode. If the REN server is SSL only, access is denied to any client trying to communicate with a HTTP URL port. The browser-based clients, the application server client, and the REN Java clients should be configured appropriately to communicate with an SSL-enabled REN server.
During an SSL transaction, the handshake is an added overhead that occurs. However, for every transaction, the handshake is done once to authenticate the server and the client. After authentication, the data is digitally signed, encrypted, and exchanged on an established session. For each console, authentication establishes a session only once, and no subsequent transactions inherit any overhead of authentication.