BCM - About SSL certificates

Version 1
    Share This:

    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).  

      BCM only accepts PEM files with .crt 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 : "ERR  .* Failed to load Certificate" 

        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.  
    You can not replace an exiting certificate (which is about to expire for example) with a new certificate having very same name.  
    ex: you cannot replace "   mycert" by "mycert" but you can replace it 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  
      A Root Authority is basically a self signed Certificate Authority.   
    There are some Root Authority (https://en.wikipedia.org/wiki/Certificate_authority#Providers) you can buy CA or Certificate from.   
               Authority (Certificate Authority) can generate another Authority (intermediate CA) or a Server Certificate. 

        5  )   Certificate Signing Request :  A .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 :

    BCM accepts both Certificate Authorities (that are used to generate Agent certificate) and Server certificates. 
    For Certificate Authorities you need to set BCM to trust all the Authority chain : Root Authority  --> Intermediate Authority 1  --> Intermediate Authority 2  -->  ...  --> x Intermediate Authority x 
    For Server Certificate you can either set BCM to trust your Server Certificate or all the Authority chain. 

    For your information, certificates are only taken into account when SSL parameter is set with a different value than 0. 

    First step is to know   which certificate is currently is use on your BMC Client Managment platform. 

          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 according to what you want to do : 
          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 if this is not a wildcard certificate. 
            Following article explains how to proceed according to what you want to do : 

    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 .xml and .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;

    .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).


    Article Number:


    Article Type:

    Product/Service Description

      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles