Security Levels
There are 4 possible security levels determining the level of the connection’s security. The default security level for each product is 4.
The following table describes the security provided and requirements for each security level.
Security Level |
Security |
Requirements |
---|---|---|
1 |
Encryption only |
Key Pair, both endpoints must be configured for security level 1. |
2 |
Encryption and presence of valid certificate on the server (with no server authentication) |
Requires a valid certificate on the server. |
3 |
Server authentication |
Server was deployed with a valid certificate (possibly with a certificate chain), and the client was deployed with a certificate which is trusted by the same root CA (possibly with a certificate chain). |
4 |
Client and server authentication |
Same as level 3, and in addition both sides must be configured with security level 4. |
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 Control-M/Agent acts as the client, and for other connections the Control-M/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 Control-M/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 using 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 later.
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's 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’s certificate if the certificate’s attributes (for example, inception 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 a 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 Control-M/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 Control-M/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.
Include the following lines in an access file to accept only the certificates issued to controlm@bmc.com and email@bmc.com. The access file must deny all other certificates, including those signed by a trusted root.
[SSL_SERVER]
;
ALLOW_ACL = controlm@bmc.com,email@bmc.com
DENY_ACL =