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

Use this procedure to provision managed servers with the SHA1 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.

To provisioning agents with an SHA1 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.
    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 with the SHA1 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:
    (Windows): 
    <repeater's hostname> rw,user=Administrator
    (UNIX): 
    <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 SHA1 fingerprint for the repeater's certificate to managed servers that communicate with the repeater. To accomplish this, use Network Shell to enter the following:
    putcert <user> id.pem <agent1...agentN>
    where,
    <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.
    When you issue the putcert command, BMC 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

Comments