This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.
BMC Client Management
Any version of BMC Client Management (BCM)
Fisrt thing to know is that BCM Master automatically generates an unique Certificate Authority first time it starts.
This is a self signed authority that is used for all BMC Client Management communications.
If you want to replace BCM self signed authority with another self signed authority, this is possible but not really needed: yo have to device.
Please find hereafter common information on certificates and BCM prerequisites that help you in implementing certificates in BCM.
A- Global information about certificates (BCM Prerequisites in bold characters):
1) Encryption Method:
There are several encryption methods available : RSA , DSA and ECC. BCM only accepts certificates based on RSA encryption method and X.509 v3 standard.
2) Certificate files :
Certificate files can be PEM (text file with .crt or .pem extension) or DER (binary file with .cer extension).
Note: In case of DER certificates, certificate file is deleted when BMC Client Management agent starts and following error can be found in mtxagent.log file :
3 ) Certificate files name : In BCM, files names must be the same for all files related to a certificate
Note: It is not possible to replace an exiting certificate (which is about to expire for example) with a new certificate having very same name.
e.g: " mycert" can't be replaced by "mycert" again but can be replaced by " mycert2"
4 ) Authorities or Server certificates : This is a property that indicates if certificate can generate other certificate or not. CA = true or false
There are various Root Authority providers CAs or Certificates can be bought from.
5 ) Certificate Signing Request : A .csr file is a request file that contains information that has to be provided when a certificate is requested to these vendors.
6 ) Certificate properties : When generating a certificate, some properties can be added.
- If any critical property is added to it, be sure they are supported by OpenSSL, if not BMC Client Management won't be able to validate and use the certificate.
- One available property is the certificate revocation parameter, please note this is not taken into account by BMC Client Management.
B- Implementing Certificates in BMC Client Management :
BCM accepts both Certificate Authorities (that are used to generate Agent certificate) and Server certificates.
For Certificate Authorities BCM needs to be set to trust all the Authority chain : Root Authority --> Intermediate Authority 1 --> Intermediate Authority 2 --> ... --> x Intermediate Authority x
For Server Certificate BCM must either be set to trust the Server Certificate or all the Authority chain.
For information, certificates are only taken into account when the SSL parameter is set with a different value than 0.
First step is to know which certificate is currently is use on the BMC Client Managment platform.
a) Working with CA (recommended) :
This way BMC Client Management agents are provided information about the CA and the BCM is going to generate a certificate using it.
The following articles explain how to proceed according to what has to be achieved:
b) Working with Server certificate (CertUser= parameter in mtxagent.ini file) :
In this case a final certificate (not a CA) has been generated and the goal is to have BMC Client Management to use it instead of using an authority.
There are two types of User certificates:
- a final certificate with a wildcard is deployed on all the devices. This is what the following addresses.
The following article explains how to proceed according to what has to be achieved:
Replace my Server Certificate which is about to expire
Additional information about certificate files :
.pem stands for PEM, Privacy Enhanced Mail; it simply indicates a base64 encoding with header and footer lines. Mail traditionally only handles text, not binary which most cryptographic data is, so some kind of encoding is required to make the contents part of a mail message itself (rather than an encoded attachment). The contents of the PEM are detailed in the header and footer line -
.pem itself doesn't specify a data type - just like
.html do not specify the contents of a file, they just specify a specific encoding;
.key can be any kind of key, but usually it is the private key - OpenSSL can wrap private keys for all algorithms (RSA, DSA, EC) in a generic and standard PKCS#8 structure, but it also supports a separate 'legacy' structure for each algorithm, and both are still widely used even though the documentation has marked PKCS#8 as superior for almost 20 years; both can be stored as DER (binary) or PEM encoded, and both PEM and PKCS#8 DER can protect the key with password-based encryption or be left unencrypted;
.kep file is automatically created by BCM Master when unencrypted .key and .crt files are present in \master\bin\auth directory, a new \master\bin\auth\<checksum> directory is created and contains both crypted .key, .crt and .kep files.
.kep files contain passphrase generated during the private key encryption process. .kef is related to FIPS standard and may not be present.
.csr stands for Certificate Signing Request, it contains information such as the public key and common name required by a Certificate Authority to create and sign a certificate for the requester, the encoding could be PEM or DER (which is a binary encoding of an ASN.1 specified structure);
.crt stands simply for certificate, usually an X509v3 certificate, again the encoding could be PEM or DER; a certificate contains the public key, but it contains much more information (most importantly the signature by the Certificate Authority over the data and public key, of course).