Security for Inter-Server Communication Across Non-Secured Connections

Policy and Distribution Services uses XMLRPC (Extensible Markup Language Remote Procedure Call) for its normal inter-server communications. XMLRPC optionally provides security for inter-server communication across non-secured connections. Policy and Distribution Services can use this security for inter-server communications between servers across non-secured connections, or between a management workstation and servers across non-secured connections. For example, firewalls, intranets, NAT configurations, and so on.

This inter-server communications security ensures that data received across a non-secured connection is from a trusted source, that it has not been tampered with en route, and that the data received can be trusted by other machines. This is accomplished through the use of signed security certificates and digital signatures.

This security requires modifications to certain text files, and is installed using a ZfS wizard.

For instructions on installing XMLRPC security, see "Installing Additional Security for Non-Secured Connections" in the Installation guide.

The following are instances when you would want inter-server communication security:

Review the following sections to understand inter-server communications security using XMLRPC:


Terms Used in This Section

The following terms and acronyms are used in the inter-server communications security documentation:

Term Explanation

CA

Certificate Authority

The trusted certificate source responsible for digitally signing other server's X.509 certificates.

CS

Certificate Signer

The trusted certificate source responsible for digitally signing other server's XMLRPC certificates.

certificate
or
security certificate

An electronic document that contains an electronic signature for validating anything associated with the certificate, such as a Distribution.

CSR

Certificate Signing Request

Request by a server to have an XMLRPC certificate signed by the trusted CS. This is not an X.509 certificate that would be signed by a root CA, such as VeriSign or Thawte Consulting.

self-signed certificate

A valid certificate signed by its creator.

signed certificate

A certificate signed by a CS, which makes it valid for acceptance by the receiving server.

SSL

Secure Socket Layer

XMLRPC

Extensible Markup Language Remote Procedure Call

Software used by ZfS and TED for inter-server communications.

ZenCSServlet

ZENworks Certificate Signer Servlet

Servlet that implements the Certificate Signer functionality.


Security Certificates

Inter-server communications security uses signed certificates issued by the Certificate Signer (CS), which are valid only within the context of the Novell ZENworks family of products.

The certificates used are not X.509 compliant and cannot be used for any e-commerce or SSL applications.

However, because SSL can be used by inter-server communications security for the ZenCSServlet, X.509 certificates provided by SSL can be used to secure inter-server communications. These certificates could be self-signed or signed by a root CA, such as VeriSign.


Using SSL for the ZenCSServlet

When a CS servlet signs a Certificate Signing Request (CSR), the requesting client must authenticate with a username and password via HTTP Basic Authentication. You can secure the username and password by using SSL for the ZenCSServlet.

For information on how to enable SSL for a commercial Web server, see your SSL documentation.

For information on setting up SSL with the ZfS Web Server, see "Configuring the Zen Web Server to Use SSL" in "Configuring Other Related Components" in "Installing Additional Security for Non-Secured Connections" in the Installation guide.


Format of the Password File

Inter-server communications security uses a password file for the username and password that are authenticated for CSR signing. You can create the password file in a text editor and place it in any secure location. You should also restrict access to the file to only the users who are listed in the file.

Usernames and passwords are both case sensitive. The syntax for the password file is:

username=password

For example:

admin=adminpassword 
CSsigner=cspassword
JohnDoe=jdpassword

You should limit the access to the password file to those users included within the file.


TCP/IP Addresses and DNS Names

In setting up inter-server communications security, the installation program relies on addresses or names of the servers where you want this security enabled. You can use either TCP/IP addresses or fully distinguished DNS server names.

IMPORTANT:  For NetWare servers, DNS names cannot have underscores. Distribution sending or receiving errors will occur if the server's DNS name contains underscores. We recommend that you use dashes instead of underscores as word separators.

For the various methods you can use to obtain these addresses or server names, see "Information to Know Before Beginning the Installation" in "Installing Inter-Server Communications Security" in "Installing Additional Security for Non-Secured Connections" in the Installation guide.