Novell Cool Solutions

TLS Certificate Installation on ZENworks Orchestrator 1.2 – 1.5



By:

February 29, 2008 3:08 pm

Reads:4,608

Comments:0

Score:Unrated

Print/PDF

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:

    <zosserverdir>/tls/cert.pem
    <zosserverdir>/tls/private/private.pem

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:

    
    <zosagentdir>/tls/server.pem

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:

-----BEGIN CERTIFICATE-----
MIICUjCCAbugAwIBAgIGARhXF89JMA0GCSqGSIb3DQEBDQUAMCgxJjAkBgNVBAMM
HWJ1c3Rlci5hcmVhZmlmdHlvbmUudXNfbWF0cml4MCAXDTA4MDIyNjE4NTM0MVoY
DzMwMDgwMjI2MTg1MzQxWjAoMSYwJAYDVQQDDB1idXN0ZXIuYXJlYWZpZnR5b25l
LnVzX21hdHJpeDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAkMr+Ck4QHtL9
KJI88yq7PC5KoGjaQsR66qFE/me/YtQwqmKOgm0iqEEfvLmyU0qF/vLZm1ojz5Qp
RvPfXCZwatNOaUsa0qDov2T68l5uSms+nth8XN2f28Q8Gv4/mjpMXIQeP1zdOTTp
3Zlsxvd4KAYTq3RW+ffUW7fY3v1Z5TkCAwEAAaOBhDCBgTAJBgNVHRMEAjAAMB0G
A1UdDgQWBBRR+5R1j9q/hXzH52YuPXtCtHWIZzBVBgNVHSMETjBMgBRR+5R1j9q/
hXzH52YuPXtCtHWIZ6EspCowKDEmMCQGA1UEAwwdYnVzdGVyLmFyZWFmaWZ0eW9u
ZS51c19tYXRyaXiCBgEYVxfPSTANBgkqhkiG9w0BAQ0FAAOBgQB5t2pNF1fdUkVU
TsuLXdqlKtgz0megAS6go6yDRk0ywDfA9sfPL0F+XoSBmjWpI8vmBQa11sSV+uSK
pJboXs8/Aw5E8Q/Y6wTFoqq/FLlQcej67JnRVE1XBfEa38OhWOmm2JyXrfmqTYDT
C6to06fSTG7+U3c0NVy6W9UxLHR7CA==
-----END CERTIFICATE-----

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.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.
Loading...Loading...

Categories: Uncategorized

0

Disclaimer: This content is not supported by Novell. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.

Comment

RSS