ZENworks Linux Management uses SSL certificates and cryptographic signatures to verify the identity of the server and the packages it ships, respectively. All ZENworks Linux Management communications are encrypted, but there are several ways that you can increase your security with better cryptography management.
An SSL certificate is a way for your server to identify itself to clients and enable secure transactions. There are two major kinds of certificates: those signed by a Certificate Authority (CA), and those you generate and sign yourself.
Certificates signed by a CA are more secure, because the CA guarantees the identity of the server. However, signed certificates must be purchased. If you prefer, you can generate your own certificate and sign it yourself. A self-signed certificate does not provide the same guarantee of identity, but it still prevents others from eavesdropping on client-server communications.
To purchase a certificate, consult a certificate authority such as Thawte or Verisign. To generate a certificate and sign it yourself, use the openssl command or another cryptography tool. See the man pages for openssl for more details.
Once you have a certificate, you must install it. Place the private portion of the certificate in the same location you would for Apache, which is /etc/httpd/conf/ssl.crt/server.crt (for Red Hat) or /etc/apache2/ssl.crt/server.crt (for SUSE). Put the public portion of the certificate in /usr/share/rcd for both SUSE and Red Hat. The value of the prefix changes depending on the operating system.
If you have purchased a CA-signed certificate, set the require-verified-certificates option to true in the client machines:
rug set require-verified-certificates true
An rcd.conf file set that way would have these lines in it:
[Network]
require-verified-certificates=true
If you have generated and signed your own certificate, set that token to false.
If you have an improperly installed or unsigned SSL certificate, and the require-verified-certificates token on your clients is set to true, all transactions fails.
XimianTM packages come signed by Ximian, and the client applications recognize the Ximian GPG keys. However, non-Ximian packages, including those created by you or by third parties, can generate spurious warnings if the keys are unrecognized. To prevent spurious warnings or rejected installs, add your public keys to the keyrings on the client machines.
On systems using RPM 4.1 or later, use the command rpm --import filename, where filename is a file containing your key or keys. For systems using RPM versions earlier than 4.1, use the command gpg --import filename.
Signing packages, like building them, is not within the scope of this manual. To learn how to sign packages, see the manual pages for the rpm tool.