SSL certificates

Normal usage of the SSL standard is the server authentication. When connecting to a secured Web server with a browser (HTTPS instead of HTTP) often a pop-up displays with a warning because the received certificate is not trusted. Then it must be decided if the connection is to be accepted or the handshake stopped. This is because a secured server is responsible for sending its server certificate at the beginning of the SSL handshake. The client is then responsible for allowing or not the connection depending on the certificate issuer. The certificate issuer is the authority that signed (delivered) the certificate. If an authority is trusted, all those certificates are trusted that are signed by this authority. SSL connections themselves between the agents are managed by certificates. These allow an agent to access all other agents it needs to. However, via these certificates it is also possible to completely isolate a part of the network, for example a subnet or even the whole network.

Certificate types

The following different types of certificates are used for agent communication:

Certificate Authority (CertAuth)
The certificate authority is the authority signing the agent certificate (client CM server).
Trusted Certificates (CertTrusted)
An agent requesting a connection with another agent accepts the connection if the certificate was signed by one of the trusted authorities which is listed in its parameter for trusted certificates. If the returned certificate is signed by an unknown authority the requesting agent will abandon the connection.

These certificates are specified via the respective parameters in the Security section of the agent configuration file (mtxagent.ini). If no certificates are defined the default BMC certificates will be established as the authority and used for certification. The parameters must be modified individually on the device agents in the .ini file or they can be modified in bulks via the operational rule that allows to modify a configuration file.

The preceding graphic shows an example with two subnets with separate certificate authorities, Asia and Europe. The agents from the subnet may contact all other agents in their subnet, but not those of the rest of the network.

Certificate Example

If the example previously shown is split up in its individual parts, the following authorities and certificates must be established for proper communication within the subnets and the complete network:

The network has three certificate authorities: MasterServer, Asia, and Europe.

The master server must have the following certificates to connect to all its children:
CertAuth: MasterServer
CertTrusted: MasterServer, Asia, Europe
The console in the following example can only connect to the master server with its certificates:
CertAuth: MasterServer
CertTrusted: MasterServer
If the console also needs to connect to other devices via remote control or direct access it will also need to trust the other authorities, otherwise these devices cannot be accessed via the previously mentioned functionalities. It therefore requires the following certificates:
CertAuth: MasterServer
CertTrusted: MasterServer, Asia, Europe
All devices located in subnet Asia must have the following certificates to be able to communicate with each other:
CertAuth: Asia
CertTrusted: Asia
All devices located in subnet Europe must have the following certificates to be able to communicate with each other:
CertAuth: Europe
CertTrusted: Europe
The main Asia relay must have the following certificates to communicate with all its children and its direct parent, the master server:
CertAuth: Asia
CertTrusted: Asia, MasterServer
If it should also be able to communicate with the European main relay (and thus all its children) the trusted entry should contain the following entries:
CertTrusted: Asia, MasterServer, Europe.
This means that the Asia relay can contact any device in the subnet Europe, but not vice versa, that is, the devices in this subnet cannot contact the Asian relay.
The main relay Europe must have the following certificates to communicate with all its children and its direct parent, the master server:
CertAuth: Europe
CertTrusted: Europe, MasterServer

To completely isolate a subnet, for example the European subnet France, another authority must be created for the main French server: France.

The French relay and all its children has the following certificate configuration, then they will not be able to contact any other device outside their subnet:

CertAuth: France

CertTrusted: France

For the preceding example the main European relay will now need another trusted authority to be able to contact this subnet, otherwise no communication is possible between the subnet France and the rest of the network:

CertTrusted: Europe, France

The way the connections are shown now in the preceding graphic, the French network can be contacted by one device only, the European relay, not even the master server can contact this subnet. For the master server to be able to the French subnet must also be added to its list of trusted authorities:

CertTrusted: MasterServer, Asia, Europe, France

Certificate logging

The agent log mtxagent.log protocols also the authorities and certificates that are created. An entry would look like the following, which represents the default BMC certification, the generated name of the authority is BMC , the only trusted authority is the BMC authority.

Certificate Authority

2008/01/21 14:39:03 AgentSecurity   I   Cert[000] Root   : certs/auth/
2008/01/21 14:39:03 AgentSecurity   I   Cert[000] Name   : Numara_ca
2008/01/21 14:39:03 AgentSecurity   I   Cert[000] Home   : fde4b4e9dbd690bd2c56d60f061598da
2008/01/21 14:39:03 AgentSecurity   I   Cert[000] Hash   : f061c793e7f33e6d04f12cf8c2c9cec3
2008/01/21 14:39:03 AgentSecurity   I   Cert[000] Issuer : <emailAddress=info@Numarasoftware.com;
    CN=Numara CA; OU=Numara AMP; O=Numara Software; L=Sophia Antipolis; ST=PACA; C=FR>
2008/01/21 14:39:03 AgentSecurity   I   Cert[000] Subject: <emailAddress=info@Numarasoftware.com;
    CN=Numara CA; OU=Numara AMP; O=Numara Software; L=Sophia Antipolis; ST=PACA; C=FR>
2008/01/21 14:39:03 AgentSecurity   I   Cert[000] Valid  : Yes
2008/01/21 14:39:03 AgentSecurity   I   Cert[000] Active : No

Server Certificate

2008/01/21 14:39:03 AgentSecurity   I   Cert[001] Root   : certs/server/
2008/01/21 14:39:03 AgentSecurity   I   Cert[001] Name   : Numara_agent
2008/01/21 14:39:03 AgentSecurity   I   Cert[001] Home   : d862892c0c275bd377ff77d2b83c4345
2008/01/21 14 :39:03 AgentSecurity   I   Cert[001] Hash   : dd8d10f9bc9c4cc5b1bff423072848b0
2008/01/21 14:39:03 AgentSecurity   I   Cert[001] Issuer : <emailAddress=info@Numarasoftware.com;
    CN=Numara CA; OU=Numara AMP; O=Numara Software; L=Sophia Antipolis; ST=PACA; C=FR>
2008/01/21 14:39:03 AgentSecurity   I   Cert[001] Subject: <CN=192.168.1.229; O=Numara Software;
    L=Sophia Antipolis; ST=PACA; C=FR>
2008/01/21 14:39:03 AgentSecurity   I   Cert[001] Valid  : Yes
2008/01/21 14:39:03 AgentSecurity   I   Cert[001] Active : Yes

Trusted Certificate

2008/01/21 14:39:03 AgentSecurity   I   Cert[002] Root   : certs/trusted/
2008/01/21 14:39:03 AgentSecurity   I   Cert[002] Name   : Numara_ca
2008/01/21 14:39:03 AgentSecurity   I   Cert[002] Home   : 33c402d87af0a0359db2c73339b013e4
2008/01/21 14:39:03 AgentSecurity   I   Cert[002] Hash   : f061c793e7f33e6d04f12cf8c2c9cec3
2008/01/21 14:39:03 AgentSecurity   I   Cert[002] Issuer : <emailAddress=info@Numarasoftwaren.com;
    CN=Numara CA; OU=Numara AMP; O=Numara Software; L=Sophia Antipolis; ST=PACA; C=FR>
2008/01/21 14:39:03 AgentSecurity   I   Cert[002] Subject: <emailAddress=info@Numarasoftware.com;
    CN=Numara CA; OU=Numara AMP; O=Numara Software; L=Sophia Antipolis; ST=PACA; C=FR>
2008/01/21 14:39:03 AgentSecurity   I   Cert[002] Valid  : Yes
2008/01/21 14:39:03 AgentSecurity   I   Cert[002] Active : Yes