Configuring SSL

Now the real difference between SSL=2 and SSL=3 becomes clear. With SSL=2, the agent authenticates the server agent on which it performs a connection. With SSL=3, the verification is mutual as the agent still authenticates the server agent on which it perform a connection but the agent server also performs this verification on the client. This way ensures that both client and server are part of a common network.

To configure the console for SSL

For the console to connect the following must be configured:

• a list of trusted authorities
• a console certificate to be used in case of SSL=3 on one of the connected agents

In order to allow the console trusting new authorities, the files (X509 certificates with extension .crt ) must be copied in the directory ${CONSOLE_MAIN_DIR}/certs/trusted . When starting, the console scans this directory and configures its communication layer in order to trust all the listed certificate authorities.

In order to allow the console using a certificate, the file (PKCS12 with extension .p12 ) must be copied in the directory ${CONSOLE_MAIN_DIR}/certs/console . When starting, the console scans this directory and configure its communication layer in order to use this certificate when connecting to an agent performing client authentication (SSL=3).

When using SSL=3 (on master or any agent where console is supposed to connect), we need to supply a client certificate to the console. We already documented this process. The certificate is embedded in a PKCS12 file generated by the mtxcert.exe (or any other) tool. But this file is protected by a password. In order to be able to load this file registered in the $(CONSOLE_MAIN_DIR)/certs/console directory, the console needs this password. We just need to update the file $(CONSOLE_MAIN_DIR)/config/ConsoleConfig.properties .

Add (or update if existing) the following line:

ssl_pwd=[password]

where [password] is replaced by the correct password protecting the PKCS12 file.

To configure the agent interface for SSL

As the agent performs a verification on the client actually connecting, this impacts also the console and any browser in case of HCHL trying to connect.

For the HCHL agent interface to connect the following must be configured:

• a browser certificate to be used in case of SSL=3 on one of the connected agents

This is more or less browser dependant but in any case, the browser raises a pop-up when connecting to a server performing client authentication. This pop-up is dedicated to the selection of an installed client certificate. With IE, such a client certificate can be installed with the corresponding PKCS12 file (the one used in the preceding console).

Example

Finally, it is important to understand that a certificate is signed by an authority which is itself a certificate, and so forth until a root certificate is reached. We talk about certificate chain in this case. For instance, we might think about the following:

• Starfleet Root Level (0)
• Enterprise Root Level (1) - issued by level (0)
• Enterprise EMEA Level (2) - issued by level (1)
• Enterprise Nice Level (3) - issued by level (2)

If we supply the level 3 certificate to an Enterprise agent, this last will emit its agent certificate signed by the third level. A client agent will accept the connection if and only if it trusts the server agent certificate (3) and all its ancestors up to (0).