Skip to content

Create a new Common KeyStore machine

Creating a new machine is the initial step in enabling TLS Protect Cloud to connect directly to application keystores for certificate management. Once you have created machines, you can move on to provisioning certificates to those machines.

Important

This topic is a continuation of steps started in Creating a new machine. Please read that topic before continuing in this one.

Before you begin

  • SSH Protocol
    • IP Address or hostname
    • Port

  • Minimum required credentials on the Common Keystore: Choose between user credentials or shared credentials. You must have permissions to create, read, and write to the destinations specified in the machine installations, and optionally to restart services on the Common Keystore for either account.

    • User credentials: The username and password you enter.
    • Shared credentials: Optionally, you can use shared credentials from your credential provider (CyberArk is the only credential provider currently supported by TLS Protect Cloud). To use this option, first set up the connection to CyberArk.

  • Windows remote management

    • IP address or hostname
    • Windows Remote Management (WinRM) port
    • Domain name (Kerberos authentication only)
    • Key distribution center address or hostname (Kerberos authentication only)
    • Service Principal Name (Kerberos authentication only)
    • Minimum required credentials on the Common Keystore: Choose between user credentials or shared credentials. You must have permissions to create, read, and write to the destinations specified in the machine installations, and optionally to restart services on the Common Keystore for either account.
      • User credentials: The username and password you enter.
      • Shared credentials: Optionally, you can use shared credentials from your credential provider (CyberArk is the only credential provider currently supported by TLS Protect Cloud). To use this option, first set up the connection to CyberArk.

  • Supported Windows versions

    • Windows Server 2019 and 2022
  • Supported Linux versions
    • Ubuntu 18.04 LTS (or later), Red Hat Enterprise Linux 7.9, and Oracle Linux 8 (or later)

If you've already done the steps in Create a new machine, you can continue the procedure to create a Common KeyStore machine by following these steps.

  • From the Protocol drop-down, select either SSH or Windows Remote Management.

Tip

What you do next depends on the tech stack you are using. Make sure you select the correct tab to continue.

  1. From the Authentication Type drop-down, select either password or private key.
  2. Enter the IP Address/Hostname and Port number.

  3. (Optional) From the Credential Type drop-down, select either Enter Credentials or Select Credentials. Only users with the enabled "CyberArk shared credential" capability will see this option.

    Important

    Your view of credentials may be limited due to your role. System Administrators and PKI Administrators should be able to select any credential, but users with the Resource Owner role are limited to only using the credentials associated with their teams.

    Note

    • Enter Credentials - Enter your admin credentials manually.
    • Select Credentials - Select shared credentials from CyberArk.
    • If you choose Enter Credentials, enter your Common KeyStore admin credentials in the Username and Password fields.
    • If you choose Select Credentials, select your shared credentials from the Credential drop-down.

  4. Enter your Common KeyStore admin credentials in the Username and Password fields.

    Warning

    Remember to store your username and password securely when creating a new machine. For security reasons, you will not be able to modify the fields under the "Access" tab without these credentials. This ensures that only authorized individuals can modify these fields.

  5. (Optional) To restart a service after certificate deployment, provide a value for the Service Name field. See Linux service restart support for details.

    If you do not provide a service name, the certificate is deployed but no restart is triggered.

  6. Click Test Access, then click Create. Create is enabled only if Test Access succeeds.

Linux service restart support

The Service Name field is only supported for Linux systems using the Machine Identity Agent and systemd1.

  • This field defines the name of the systemd-managed service to restart after certificate provisioning.
  • The Agent executes sudo systemctl restart <service-name> on the target machine.
  • The restart process does not apply to machines accessed via SSH or WinRM. These protocols do not support service restart automation.
Customer responsibilities

The restart command runs with elevated privileges. Customers are responsible for ensuring security and audit readiness:

  • Restrict sudo rights: 
    <integration-user> ALL=(ALL) NOPASSWD: /bin/systemctl restart <service-name>
  • Harden the unit file:
  • Avoid ExecStart or ExecReload scripts you do not fully control.
  • Use User=, Group=, ProtectSystem=, ProtectHome=, and PrivateTmp= in your unit file to minimize risk.
  • Validate input: Ensure that environment variables or config inputs used by the service are sanitized.
  • Log and audit: Use auditd2 or journald3 to monitor restarts and track who triggered them.
Testing and troubleshooting
  • After setup, monitor the machine’s log output and confirm that the service restarts correctly.
  • If the restart fails, TLS Protect Cloud logs a warning, but the certificate is still deployed.
  • Restart failures may stem from:
  • Incorrect service name
  • Lack of sudo permissions
  • Broken unit files or failed dependencies

From the Authentication Type, select either Basic Authentication or Kerberos Authentication, then follow the steps from the correct tab below.

  1. Enter the IP Address/Hostname and the Port.

  2. Enable Use TLS for WinRM to secure the username and password when TLS Protect Cloud communicates with the IIS server.

    Warning

    Disabling this option will send the username and password in plaintext over the network.

  3. (Optional) From the Credential Type drop-down, select either Enter Credentials or Select Credentials. Only users with the enabled "CyberArk shared credential" capability will see this option.

    Important

    Your view of credentials may be limited due to your role. System Administrators and PKI Administrators should be able to select any credential, but users with the Resource Owner role are limited to only using the credentials associated with their teams.

    Note

    • Enter Credentials - Enter your admin credentials manually.
    • Select Credentials - Select shared credentials from CyberArk.
    • If you choose Enter Credentials, enter your Common KeyStore admin credentials in the Username and Password fields.
    • If you choose Select Credentials, select your shared credentials from the Credential drop-down.

  4. Enter your Common KeyStore admin credentials in the Username and Password fields.

    Warning

    Remember to store your username and password securely when creating a new machine. For security reasons, you will not be able to modify the fields under the "Access" tab without these credentials. This ensures that only authorized individuals can modify these fields.

  5. Click Test Access, then click Create. Create is enabled only if Test Access succeeds.

  1. Enter the IP Address/Hostname and the WinRM Port.

  2. Enable Use TLS for WinRM if you want TLS to be used when TLS Protect Cloud communicates with the IIS server.

    Tip

    Since Kerberos already has built-in encryption, this option isn't necessary to secure data sent over the network.

  3. Enter the Domain Name, Key Distribution Center Address/Hostname, and Service Principal Name. You can get these from your Active Directory administrator.

  4. (Optional) From the Credential Type drop-down, select either Enter Credentials or Select Credentials. Only users with the enabled "CyberArk shared credential" capability will see this option.

    Important

    Your view of credentials may be limited due to your role. System Administrators and PKI Administrators should be able to select any credential, but users with the Resource Owner role are limited to only using the credentials associated with their teams.

    Note

    • Enter Credentials - Enter your admin credentials manually.
    • Select Credentials - Select shared credentials from CyberArk.
    • If you choose Enter Credentials, enter your Common KeyStore admin credentials in the Username and Password fields.
    • If you choose Select Credentials, select your shared credentials from the Credential drop-down.

  5. Enter your Common KeyStore admin credentials in the Username and Password fields.

    Warning

    Remember to store your username and password securely when creating a new machine. For security reasons, you will not be able to modify the fields under the "Access" tab without these credentials. This ensures that only authorized individuals can modify these fields.

  6. Click Test Access, then click Create. Create is enabled only if Test Access succeeds.

What's next

Reference

  1. Learn more about systemd (System and Service Manager): https://github.com/systemd/systemd/blob/main/README.md ↩

  2. See the manual page for auditd (Linux Audit Daemon): https://linux.die.net/man/8/auditd ↩

  3. See documentation for systemd-journald: https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html ↩