Provisioning agents with a fingerprint of the repeater's self-signed certificate

Use this procedure to provision managed servers with a fingerprint of the repeater's self-signed certificate. An agent uses this fingerprint to validate the self-signed certificate received from the repeater in the course of the TLS handshake. 

NEW IN 21.02You can use the following hash algorithms for the fingerprint apart from SHA1: SHA224, SHA256, SHA384, and SHA512

These hash algorithms are supported with RSCD Agent 21.02. Therefore, make sure to upgrade the RSCD Agents to 21.02 before using these hash algorithms.

To provisioning agents with a fingerprint of the repeater's 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
    Before you can provision an agent with the fingerprint of the repeater's certificate, you must ensure the secure file on the agent is configured correctly. If you prematurely set the rscd entry in an agent's secure file so that tls_mode=encryption_and_auth, the agent refuses the incoming connection because it does not have the SHA1 fingerprint of the repeater'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 directory on Windows server, where <WINDIR> is typically windows.
    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 with the fingerprint of an repeater server certificate, you must have root or Administrator privileges on the server hosting the agent. To grant this privilege, update the exports file on the target server with the following entry:
    <repeater's hostname> rw,user=Administrator
    <repeater's hostname> rw,user=root
    where <repeater's hostname> is the host name or IP address of the repeater server host. Ensure that you revert these settings to more restrictive settings after performing the next two steps, as discussed in step 5.
  3. Change to the directory on the repeater where id.pem is stored.
    • (UNIX) The id.pem file resides in <userHomeDirectory>/.bladelogic, where <userHomeDirectory> is the user's home directory. For example, if you are logged in as root, id.pem is created at /root/.bladelogic/id.pem.
    • (Windows) The id.pem file resides in <WINDIR>\rsc\certs\BladeLogicRSCD.
  4. Push the fingerprint for the repeater's certificate to managed servers that communicate with the repeater.

    • To push SHA1 fingerprint, use Network Shell to enter this command:
      putcert <user> id.pem <agent1...agentN>
    • To push other hash algorithm fingerprint, enter this command:
      putcert -hashalgo <sha_algorithm> <user> id.pem <agent1...agentN>
      For example, to push SHA512 fingerprint, specify the following command:
      putcert -hashalgo sha512 <user> id.pem <agent1...agentN>

    <user> is either the name of the UNIX user you were logged in as when you created the certificate or BladeLogicRSCD if the repeater is on a Windows platform.
    <agent1...agentN> is a space-separated list of the host names or IP addresses (IPv4 or IPv6) of the managed servers hosting agents.
    <sha_algorithm> can be any of the following: sha512, sha384, sha256, or sha224
    When you issue the putcert command, TrueSight Server Automation places the SHA1 fingerprint of the id.pem file for root in a file called root. It places the SHA1 fingerprint of the id.pem file for BladeLogicRSCD in a file called BladeLogicRSCD. The file resides in the <Agent Installation Directory>/NSH/certs directory on UNIX servers and in <Agent Installation Directory>/certs on Windows.

  5. Revert the setting in the exports file on managed servers back to a more restrictive user mapping. Otherwise, all users accessing those agents from the repeater server are mapped to root or Administrator.
Was this page helpful? Yes No Submitting... Thank you