Cloud Manager Orchestration uses Transport Layer Security (TLS) to provide encryption for both user and agent connections. The Orchestration Agent, the Orchestration Console and other Orchestration clients use TLS to initiate their connections to the Orchestration Server, and then the server specifies whether to “fall back” to plain text or continue the session fully encrypted.Although you can manually configure the agent and clients to either always require TLS encryption or to fully disable TLS encryption, we recommended that you leave the agents and clients in their default configuration, and then use the Orchestration Console on the server to specify the default behavior. This is the purpose of the TLS Options section on the main server tab of the Orchestration Console.
Figure 7-1 TLS Options in the Cloud Manager Orchestration Server Console
Here, there are 4 levels that you can set separately for both agent connections and user/client connections:
Forbid TLS for (agents/clients): This option is to fully disable and prohibit TLS encryption altogether. This is the least secure option and is therefore usually not the desirable choice, but it could be required in countries that restrict encryption or in low security environments where performance is more critical than security.
Allow TLS on the (agents/clients); default to falling back to unencrypted: This option (the factory default for both agents and clients) is to allow TLS encryption if the agent or client explicitly requests it, but to default to falling back to plain text after authentication.
NOTE:Authentication always occurs over SSL, regardless of settings.
Allow TLS on the (agents/clients); default to TLS encrypted if not configured encrypted: This option is similar to the second option. Agents/clients may specify whether or not to use TLS, but if they use the default of “server specified,” the server defaults to using TLS.
Make TLS mandatory on the (agents/clients): This option is the most secure, locked down option. It requires TLS at all times, and fails connections if the agent or the client tries to specify plain text.
In addition to these settings for TLS configuration, there are files that need to be protected on both the server and on the client/agent. For more information, search for the TLS Certificate Installation on PlateSpin Orchestrate article at the Novell Cool Solutions Community.
NOTE:The principles of this article are still technically correct, although the product branding and some terms have been updated in the product since the original posting of this article.
Understanding Transport Layer Security (TLS) encryption is particularly important if you reinstall the server and have an old server certificate in either your agent or client user profile similar to ssh shared keys. If you have an old certificate, you need to either manually replace it or delete it and allow the client or agent to download the new one from the server using one of the following procedures:
For the Agent: The TLS certificate is in <agentdir>/tls/server.pem. Deleting this certificate will cause the agent, by default, to log a minor warning message and download a new one the next time it tries to connect to the server. This is technically not secure, since the server could be an impersonator. If security is required for this small window of time, then the real server’s <serverdir>/<instancedir>/tls/cert.pem can be copied to the above server.pem file.
For the Client: The easiest way to update the certificate from the command line tools is to simply answer “yes” both times when prompted about the out-of date certificate. This is, again, not 100% secure, but is suitable for most situations. For absolute security, hand copy the server’s cert.pem (see above) to ~/.novell/zos/client/tls/<serverIPAddr:Port>.pem.
For Java SDK clients: Follow the manual copy technique above to replace the certificate. If the local network is fairly trustworthy, you can also delete the above ~/.novell/.../*.pem files, which will cause the client to auto-download a new certificate.