TLS Certificate Installation on ZENworks Orchestrator 1.2 - 1.5

over 13 years ago

Currently, TLS encryption and certificate support is very basic, and behaves a bit like SSH. This article was originally posted to the zos-dev mailing list, and provides useful information on how certificates are used in the 1.2 and 1.5 versions of ZENworks Orchestrator.

Initial note posted to zos-dev:

The current TLS/SSL implementation is rather simple in its handling of certificates. It doesn't currently hook into X.509 or any higher level certificate management. It's more like SSH. The server has two ".pem" files. One is the private key in Base64 PEM text format, and the other is the public certificate file, also in Base64 PEM text format. The clients and agents,then have a copy of the public certificate in a local file called "server.pem". When a TLS encrypted connection is attempted, the client or agent verifies during the handshake that the server possesses the secret key and is thus not a fake server. The server, on the other hand, authenticates the client or agent with an old fashioned user name and password, once encryption is established.

By default, the server, the first time comes up, will automatically generate a brand new secret key and matching certificate. The client or agent will print a warning and download/accept the server's certificate IF THE CLIENT DOES NOT YET HAVE ONE. This is like SSH when you connect to a new host. The agent just prints a warning in the log and the client prompts yes/no to accept the new certificate.

Once the agent or client has a certificate, either will complain bitterly if the server's presented certificate doesn't match with the client's copy, as this is evidence of an attempted man-in-the-middle attack.

Getting back to the certificates, it should be possible to generate the server certificate and private key files using your CA, as long as they are formatted in standard PEM text form and use hashes and/or ciphers supported by the default Sun Java 1.5 implementation. They should be installed in:


This can be done after the initial start up by shutting down ZOS, replacing those two certificate files, then starting up again. Note that you'll also probably need to manually copy the cert.pem file to the 'server.pem' files on the agents. On the agents, the server.pem is usually located in:


and is an exact copy of the certificate from the server. (NOT the private key!)

Normally <zosserverdir> is /var/opt/novell/zenworks/zos/server, and <zosagentdir> is /opt/novell/zenworks/zos/agent.

By "PEM" format, I mean certificates that are encoded as text files like you'd use to set up SSL/TLS on an Apache web server. For example:

RvPfXCZwatNOaUsa0qDov2T68l5uSms nth8XN2f28Q8Gv4/mjpMXIQeP1zdOTTp
TsuLXdqlKtgz0megAS6go6yDRk0ywDfA9sfPL0F XoSBmjWpI8vmBQa11sSV uSK
C6to06fSTG7 U3c0NVy6W9UxLHR7CA==

Note that generating the certificate using a separate CA does not really buy you anything right now. The purpose of the current scheme was simple to provide channel encryption between clients/agents and the server. In the future, once we have a pluggable authenication back-end system, we will probably extend the TLS support to allow client certificate chains and X.509 integration, among other things.

And a followup question:

Thanks for the info, very useful. I've verified that the server and agent have the same certificate but the agent still complains about not being trusted. Do I need to include the entire certificate chain in the pem file?

My followup on this:

Well, using an externally generated certificate is not "officially" supported yet, and is not thoroughly tested. I suspect you may have to generate a "self signed" certificate without a trust chain, since the current validation code doesn't support full certificate chains. Like I said, it's pretty basic right now.

Is there a reason you need to use an external CA? One thing you could do to investigate this issue is let the ZOS server create a cert and key for you then use the 'openssl' command line tool to take a look at what's inside. Right now, it's just a self-signed certificate. Validation is done by directly copying the certificate file to the agents. In a more complete setups, you would have a set of root certificates on the client and would validate via cert chains, but that's not available yet.


How To-Best Practice
Comment List
Related Discussions