This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.
BMC Client Management
BCM All Versions
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). In BCM you have to use PEM file with .crt extension.
When implementing certificates in BMC Client Management, you have to put specific files in specific directories (and also in parameters corresponding to these parameters) :
- .crt file in \bin\certs\trusted
- .crt, .key (file is encrypted at agent first startup) and .kep files in \bin\certs\auth if you want to work with Certificate Authority
- .crt, .key (file is encrypted at agent first startup) and .kep files in \bin\certs\user if you want to work with User Certificate
Note : If you do not have .kep file you can generate it by putting both .crt and .key (not crypted) files in \bin\certs\auth directory, then start BMC Client Management agent.
A new checksum directory is created in \bin\certs\auth in which you can find both .crt, .key (encrypted) and .kep files. So you can use these files on all BMC Client Management agents.
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 : "ERR .* Failed to load Certificate"
Note : If your certificate is not self signed, you need to provide the \bin\certs\trusted directory with all certificate from your certificate up to the self signed certificate your certificate is issued from.
For example: your certificate 'MyCert' is issued from 'MyAuth2' issued from 'MyAuth1' issue from 'MyAuth' which is self signed.
Then you have to put both MyCert.crt, MyAuth2.crt, MyAuth1.crt and MyAuth.crt in \bin\certs\trusted directory (and also in corresponding parameter).
3) Certificate files name :
In BCM, files names must be the same for all files related to a certificate ex: mycert.key, mycert.crt and mycert.kep.
4) Authorities or Server certificates : This is a property that indicates if certificate can generate other certificate or not. CA = true or false
A Root Authority is basically a self signed CA. There are some Root Authority (https://en.wikipedia.org/wiki/Certificate_authority#Providers) you can buy CA or Certificate from.
Basically an Authority (Certificate Authority) can generate another Authority (intermediate CA) or a Server Certificate :
Root Authority, can generate:
a) Server Certificate
b) Intermediate authority lvl1, which can generate:
a1) Server Certificate
b1) Intermediate authority lvl2, which can generate: etc...
5) Certificate Signing Request :
.csr file is a request file that contains information you have to provide when you are requesting for a certificate. It will be signed with an Authority in order to generate your certificate.
6) Certificate properties : When generating a certificate, you can add some properties.
- If you add critical properties, be sure they are supported by OpenSSL, if not BMC Client Management won't be able to validate your certificate.
- One available property is the certificate revocation parameter, please note this is not taken into account by BMC Client Management.
Implementing Certificates in BMC Client Management :
There are two way to use certificates in BMC Client Management depending if you want to use CA (recommended) or final certificates.
For information certificates are taken into account only when SSL parameter is set with a different value than 0.
a) Working with CA (recommended) :
This way your are going to provide BMC Client Management agents with information about your CA and BMC Client Management agent is going to generate a certificate using it.
Following article explains how to proceed :
b) Working with Server certificate (CertUser= parameter in mtxagent.ini file) :
In this case you have generated a final certificate (not a CA) and you want BMC Client Management to use it.
This is more secure but way more complicated to implement as each BMC Client Management agent can have its own certificate.
Your certificate can be generated for a specific device or can be a wildcard certificat.
Following article explains how to implement this in BMC Client
Note : In case of SSL=3, Console must have its own certificate in \console\certs\console, as a consequence Authorities for this certificates must be included in Master\bin\certs\Trusted
Additional information about certificate files :
.pemstands 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 -
.pemitself doesn't specify a data type - just like
.htmldo not specify the contents of a file, they just specify a specific encoding;
.keycan 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;
.csrstands 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);
.crtstands 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).