Provisioning agents and repeaters with a SHA1 fingerprint of the Application Server self-signed certificate (Windows)

Use this procedure to create, or update, on each managed server and repeater a file named SYSTEM. This file contains the SHA1 fingerprint of the Application Server self-signed certificate. An agent or repeater uses this fingerprint to validate the self-signed certificate received from the Application Server during the TLS handshake.

To provision agents and repeaters with a SHA1 fingerprint of the Application Server self-signed certificate

  1. Ensure that the secure file on all managed servers is configured so that tls_mode=encryption_only. If necessary, generate this setting by running the following secadmin command on each agent: 
    secadmin -m rscd -p 5 -T encryption_only -e tls

    Tip

    You can also run this command using nexec from the Application Server (using nexec <hostname> secadmin ...) or by using a NSH script job.

    Before you can provision a managed server with the fingerprint of the Application Server's certificate, you must ensure that the secure file on the agent or repeater is configured correctly. If you prematurely set the rscd entry in a secure file so that tls_mode=encryption_and_auth, the agent or repeater will refuse the incoming connection because it will not have the SHA1 fingerprint of the Application Server's self-signed cert. The secure file must have the rscd entry set as shown below when deploying the certificate fingerprint. The secure file is located in the /etc/rsc directory on a UNIX server and C:\<WINDIR>\rsc on Windows, where <WINDIR> is typically windows
    rscd:port=4750:protocol=5:tls_mode=encryption_only:encryption=tls
    This is the default setting after a fresh installation of an agent, so in most situations there is no need to perform this step.

  2. Set up root or Administrator privileges on each managed server hosting an agent. 
    To provision an agent or repeater with the SHA1 fingerprint of an Application Server's certificate, you must have root or Administrator privileges on the server hosting the agent. To grant this privilege, update the exports file on a Windows server by creating the following entry: 
    * rw,user=Administrator
    On a UNIX server, update the exports file by creating the following entry: 
    * rw,user=root
    To be safe, you should replace the host wildcard ("*") with a more restrictive setting, such as the IP address or host name of the Application Server.
  3. Using a command line on the Application Server, cd to C:\WINDIR\rsc\certs\SYSTEM, the directory containing the id.pem file.
  4. Push the SHA1 fingerprint to managed servers by entering the following command: 
    putcert SYSTEM id.pem <agent1...agentN>
    where <agent1...agentN> is a space-delimited list of the host names or IP addresses (IPv4 or IPv6) of the managed servers hosting agents or repeaters. 
    This command creates or updates a fingerprint file on each targeted agent or repeater. On a Windows machine, the fingerprint file for a Window Application Server is C:\Program Files\BMC Software\BladeLogic\RSCD\certs\SYSTEM; on a UNIX machine, the fingerprint file for a Windows Application Server is /opt/bmc/bladelogic/NSH/certs/SYSTEM
    In environments where multiple Application Servers communicate with agents, you should provision each Application Server with its own self-signed certificate. Performing this procedure for each of those Application Servers generates multiple fingerprints in the SYSTEM file.
  5. Revert the setting in the exports file on managed servers back to a more restrictive user mapping. Otherwise, all users accessing those agents are mapped to root or Administrator.

Note

Ensure that you keep a backup of the id.pem file. This backup file will enable you to restore communication between the Application Server and your RSCD Agents if the id.pem file is inadvertently removed or changed. See also Backup and restore of the BladeLogic environment.

Was this page helpful? Yes No Submitting... Thank you

Comments