In a standard CoreMedia installation, session handles and content are transmitted in clear text across the network between client and server. This is usually not a problem when the editorial workplaces and the servers reside in the same trusted network. However, for secure remote access, encrypted communication is sometimes required.

If SSH tunneling is not an option, alternatively a Secure Socket Layer (SSL) connection can be used for the CORBA communication between CoreMedia applications.

The setup is slightly more complex than in the SSH case, because the certificate handling has to be administered explicitly for Java's SSL implementation, and because the port mapping has to be specified in CoreMedia configuration files.

In the following example it is assumed that communication has to be encrypted between a Site Manager on one side, and the Content Server and Workflow Server on the other side.

Note

In this example, the port numbers from table Table 4.3, “Example SSL Ports” are used. You may want to use different port numbers for your deployment.

The servers open an SSL Port in addition to the clear-text port. This allows the same server to be accessed using clear text communication from within a trusted network, and using SSL from outside. When a client is configured to use SSL, not a single byte will be sent to the clear text port, which may be blocked from outside access by a firewall.

Note that the server's HTTP port will have to be accessible to clients, for example to retrieve the IOR.

Enable SSL Encryption

Enabling SSL encryption for CORBA communication requires the following steps:

Create key stores

Create key stores which will later be distributed to the servers and clients. Consult your JDK documentation for further details about the keytool command.

keytool -genkey -alias contentserver -v -keyalg RSA \
   -keystore contentserver.keystore
keytool -genkey -alias workflowserver -v -keyalg RSA \
   -keystore workflowserver.keystore

keytool -export -rfc -keystore contentserver.keystore \
   -alias contentserver -file contentserver.public-key
keytool -export -rfc  -keystore workflowserver.keystore \
   -alias workflowserver -file workflowserver.public-key  

Prepare the Content Server for SSL communication

Prepare the Workflow Server for SSL communication

The following two steps are optional and are limited to rare cases, in which SSL encrypted communication may also be required between workflow server and content server.

keytool -import -alias contentserver -keystore \
  workflowserver.keystore -file contentserver.public-key 

Preparing a client ORB for SSL communication

All CoreMedia clients use CORBA to communicate with the servers.

The comma separated values of the clear-text-ports and the ssl-ports properties must match. They must have the same length, and the n-th value of each property refers to the same component. In this example the first values, 14300 and 14443, denote the content server, and the second values, 14305 and 14445 belong to the workflow server.

Prepare the Site Manager for SSL Communication

keytool -import -alias contentserver \
  -keystore editor.keystore -file contentserver.public-key
keytool -import -alias workflowserver \
  -keystore editor.keystore \
  -file workflowserver.public-key

Caution

Though stated in the examples, it is not recommended to place the editor.keystore at any publicly accessible place. This is only intended for testing and development. For productive use, an official key should be deployed with every Unified API installation on the client machines. Another possible way would be to download the key store via HTTPS using a certificate that is already present on the workplace computers.

Restart Workflow Server, Content Server, and clients.

Restart all servers by restarting the servlet container where they are deployed.

Verify SSL communication

Verify SSL communication by searching the applications' logs for error messages, and by using netstat or lsof. Under Solaris, using the port numbers in this example, you could use the command:

netstat -e -a -p|grep ":14[34]"

It should show that before starting the Site Manager, the server is listening on port 14443/14445 (which are the SSL ports) and 14300/14305 (the clear text ports). After the Site Manager is started and a user has logged in, a connection should be established on port 14443/14445 (and not 14300/14305) towards the client's machine. Note that other applications might continue to connect to the clear text ports.