Security Levels

Control-M components are classed according to four possible connection security levels, as described in the following table.

Security Level	Security
1	Encrypted client-server connection only No client or server authentication Any key pair (Diffie-Helman secure key exchange method) Client and server must both be configured to level 1 For more information, see Security Level 1.
2	SSL Encrypted client-server connection No client or server authentication Valid server certificate required For more information, see Security Level 2.
3	SSL Encrypted client-server connection Server authentication only Client and server contain valid certificates that are signed by the same Certificate Authority (CA) For more information, see Security Level 3.
4	SSL Encrypted client-server connection Client and server authentication Client and server contain valid certificates that are signed by the same Certificate Authority (CA) Client and server must both be configured to level 4 For more information, see Security Level 4.

You can view the

In Zone 2, Control-M/EM is the client and Control-M/Server is the server. In Zone 3, Control-M/Server acts as the server and the Agent acts as the client, and for other connections the Agent acts as the server and the Control-M/Server acts as the client.

You must define the same security level for a pair of components that communicate with each other. However, you can define level 3 for communication in a server role and level 4 for communication in a client role to the communication channel between the Agent and Control-M/Server.

Security Level 1

Security level 1 provides privacy only. After a secure connection is established, user data is encrypted. This level does not provide authentication. When a client-server connection is established, a session key is generated and exchanged via the Diffie-Helman secure key exchange method. Security level 1 usually prevents access by a casual network browser. To prevent access by a skilled and determined intruder, use security level 2 or higher.

Security Level 2

Security level 2 implements the Secure Socket Layer protocol. A server operating at security level 2 accesses a private database of key pairs and retrieves the key pair named in the identity attribute of its security policy. It uses the key pair values and accompanying certificate to establish an SSL connection with the client.

A client operating at security level 2 accepts the server certificate. SSL ordinarily requires the client to establish a chain of trust for the server's certificate down to a trusted root. But, in security level 2, the client omits this step and accepts the server certificate if the certificate attributes, such as the certificate structure and expiration date, are acceptable.

When using security level 2, the server and client cannot be sure of each other’s identity. Nevertheless, a secure exchange of the session key occurs and privacy superior to that of security level 1 is provided.

Security Level 3

Security level 3 operates like security level 2 except that the client must use its own database of certificates to establish a chain of trust for the server's certificate down to a trusted root. This is in addition to the requirement that all other attributes of the server’s certificate be acceptable. Therefore, the client can be certain of the identity of the server, but the server cannot be certain of the identity of the client. This connection is said to have server authentication only.

Security Level 4

Security level 4 provides privacy and authentication for both client and server. Security level 4 is enforced by the server. After a handshake with the client as described in security level 3, the server sends a message to the client demanding an additional handshake.

The client returns its own certificate, which the server verifies down to a trusted root. If the client does not provide a certificate that the server can verify, the server shuts down the connection. Since each peer has identified itself to the other, this connection is said to have mutual authentication.

Access Files

Access files use email fields in server certificates for authentication. Access files can be defined for Control-M/Server and the Agent. The default access file for Control-M/Server is called access, and it is located in the <Control-M/Server Home Directory>/data/SSL/cert directory. The default access file for the Agent is called access, and it is located in the <Agent Home Directory>/data/SSL/cert directory.

Both files contain lines similar to these:

[SSL_SERVER]

;

ALLOW_ACL = *

DENY_ACL =

The following table describes the parameters in the access file.

Parameter	Description
SSL_SERVER	Authentication confirming a server's identity
ALLOW_ACL	Allows signed certificates to be sent to specified addresses. Default: * (Allow every client).
DENY_ACL	Deny the sending of signed certificates to specified e-mail addresses. Default: blank (Does not deny any client).

The security level must be 4. For more information, see Security Level 4.

The server certificate email field is checked after the regular SSL handshake, and after both peers have checked that the certificates that they received are signed by a trusted root CA.

DENY_ACL and ALLOW_ACL are used to control the sending of signed certificates to email destinations.