Secure SSL communication with the SSM Web Interface

The ServerView System Monitor Web Interface (SSM Web Interface) allows you to use a secure HTTPS connection to remotely monitor your PRIMERGY server via the Web browser on a communication end device. On the server side, the ServerView Connector Service(SCS) is responsible for establishing the HTTPS connection.

4.4.1 Requirements and overview

The following explains the requirements for using a secure HTTPS connection and the steps to fulfill them.

4.4.1.1 Requirements for using a secure HTTPS connection

To allow the ServerView System Monitor Web Interface to securely communicate with the browsers running on the communication end devices, the following requirements must be met:

l A certificate signed by a CA must be available on the managed node on which the ServerView System Monitor is running.

The ServerView System Monitor Web Interface (incl. ServerView Connector Service) is available on Windows and Linux operating systems once you have installed the ServerView agents as of Version 7.01 on the managed node.

The ServerView Connector Service is supplied with a predefined server certificate (default certificate). If you want to access the ServerView System Monitor over secure connections, it is strongly recommended that you replace the default certificate with one signed by a CA as soon as possible. Besides bypassing security issues, this procedure will avoid browser security warnings when accessing the ServerView System Monitor from a properly prepared communication end device.

l The root certificate which is used for signing the server certificates must be available on each participating end device.

To meet these requirements, you can use various strategies:

1. Using a server certificate signed by a trusted (commercial) CA

In this case, a valid certificate signed by a trusted (commercial) CA must be installed on the managed node. As most Web browsers (e.g. those running on communication end devices) come with the majority of well-known root certificates already included, it will normally not be necessary to explicitly import CA certificates into the trust store of the Web browsers.

2. Using a server certificate signed by your own CA

You can create your own CA which is based on a self-signed certificate. This self-signed certificate now acts as the root certificate of your CA and can therefore be used for signing server certificates. To ensure that the browsers running on the end devices will accept server certificates signed in this way, self-signed root certificates must have been previously imported into each browser or into the Trusted Root Certification Authorities store of the end device.

3. Creating / using a PKI (public key infrastructure), e.g. Active Directory Certificate Services.

4.4.1.2 Steps needed to establish a secure HTTPS connection via strategy 2 The following steps are needed to establish a secure HTTPS connection between the ServerView System Monitor Web Interface on the managed node and the browsers on the communication endpoints:

1. Creating your own CA by creating a self-signed certificate which will later be used as the (Root) CA certificate for signing the server certificates.

Step 1 may be omitted if an own CA already exists or a CA certificate purchased from a trusted commercial CA is available. A significant advantage of using your own CA is that this is free of charge.

2. Importing the Root CA certificate into to establish Trusted Certification Authorities store of the communication endpoints (or the browsers running on them) for accessing the ServerView System Monitor.

Step 2 may be omitted if you use a CA certificate purchased from a trusted commercial CA. This is because most current browsers come with the root certificates of all well-established CAs already installed on them, so it will normally not be necessary to import these CA certificates into the browsers.

3. Preparing the managed node for the secure HTTPS connection:

a. Creating a host certificate for the managed node and signing it with the (Root) CA certificate.

b. Creating a ServerView Connector Service certificate from the host public key, host private key, and the public key of the root certificate.

c. Installing the ServerView Connector Service certificate on the managed node and configuring the ServerView Connector Service properly.

In the following, a continuous example is used to illustrate how you can use the OpenSSL toolkit for implementing the "Using a server certificate signed by your own CA" variant. For detailed information on how to use the OpenSSL toolkit, see http://www.openssl.org.

You can use the OpenSSL command openssl <openssl command> -?to display the complete syntax description of the respective OpenSSL command (e.g.

openssl genrsa -?).

4.4.2 Creating your own CA

The basic concept of creating and operating your own CA consists of creating a self-signed certificate whose private key will be used later to sign the server certificates. The self-signed certificate thus serves as the Root CA certificate of your own CA. To avoid browser security warnings when accessing the ServerView System Monitor from a communication end device, this Root CA certificate has to be imported into the Trusted Root CA stores of the individual communication end devices (or of the browsers running on them). A significant advantage of using your own private CA is that it is free of charge, although with the drawback, that the corresponding root certificate must be imported into the Trusted Certification Authorities store of the communication endpoints (or of the browsers running on them).

The following explains by way of example how you can use the OpenSSL toolkit to create your own CA. Creating your own CA primarily consists of creating a private key, which later on will be used for signing the server certificate.

Proceed as follows:

1. Create the private key that is to be used for your CA:

openssl genrsa -aes256 -out rootCAprivate.key 4096 You will then be prompted to enter a passphrase for the key. The created private key is output in the .key file (here: rootCAprivate.key)

Important!

The .key file containing the private key of your CA must be protected securely. An offender gaining unauthorized access to your CA's private key can easily sign certificates which will be trusted by the clients. This risk can be greatly reduced by securing the private key with a

passphrase as shown above. Beyond that, it is strongly recommended to store the private key in a specially protected directory (e.g. on a separate server) or even on a smartcard.

2. Create a self-signed certificate (root certificate) using the previously created private key:

openssl req x509 new key rootCAprivate.key days 730 -out rootCApublic.pem

You will be prompted to enter the passphrase for the previously created private key (here: rootCAprivate.key). Then you will be prompted to enter the values for some identifying certificate attributes: Country Name, State or Province Name, City or Locality, Organization Name,

Organizational Unit, Common Name, Email Address.

The created root certificate is output in the .pem file (here:

rootCApublic.pem).

4.4.3 Importing the Root CA certificate into the browsers of the communication end devices

In the next step, you import your root certificate (here: rootCApublic.pem) into the Trusted Root CA stores of all communication end devices from which users want to access the managed node via the ServerView System Monitor Web Interface. On Windows systems, Internet Explorer and Chrome, for example, use

Windows's own internal Trusted Root CA Store, whereas Firefox, for example, holds its own separate Trusted Root CA Store.

For example, on an end device running a Windows operating system, you can use the Certificate Manager (Certmgr.exe) to install your root certificate in the end device's Trusted Root CA store. In Firefox, you use the browser settings to import the Root CA certificate.

Once your root certificate has been installed on a communication end device, this device will accept any X.509 certificates that are signed with this root certificate without warning.

4.4.4 Preparing the managed server for secure HTTPS communication with the end devices

The following steps are required to enable the managed server to communicate securely with the browsers running on the communication end devices:

1. Creating a server certificate (host certificate) for the managed node.

2. Creating the ServerView Connector Service certificate (for the ServerView Connector Service running on the managed node).

3. Configuring the ServerView Connector Service.

4.4.4.1 Creating a server certificate for the managed node

The managed node needs the certificate to authenticate itself to the Web browsers.

Proceed as follows:

1. Create the private key (here: serverAprivate.key) for the server certificate