To Create a Common KeyStore Machine

1. Sign in to Next-Gen Trust Security.
2. Click Insights > Certificate Installations > Machines.
3. Click New, and then select Common KeyStore (PEM, JKS, PKCS#12).
4. On the Properties step, in Name, enter a name for the machine.
5. (Optional) For Authorized Workspaces, choose the workspaces to share the machine with. Sharing is supported for machines that use credentials you enter directly. To learn what other workspaces can do with a shared machine, see Sharing Makes a Resource Visible Elsewhere.
6. For VSatellite, choose a VSatellite that can reach the machine. The list shows each VSatellite with the number of its active replicas.
7. For Protocol, choose SSH or Windows Remote Management.
8. For Authentication Type, choose how Next-Gen Trust Security signs in to the host:
   • If you chose SSH, choose Password or Private Key.
   • If you chose Windows Remote Management, choose Basic or Kerberos.
9. In IP Address/Hostname, enter the IP address or hostname of the host.
10. (Optional) In Port, enter the port that SSH or the host's WinRM listener listens on. If you leave it empty, Next-Gen Trust Security uses 22 for SSH and 5985, the default WinRM HTTP port, for WinRM. If you enable Use TLS for WinRM, enter the HTTPS listener port, which is usually 5986.
11. If you chose Windows Remote Management, (Optional) to connect to the host over HTTPS, enable Use TLS for WinRM. If you leave it disabled, Next-Gen Trust Security connects over HTTP.
    Note: Next-Gen Trust Security doesn't verify the TLS certificate of the host's WinRM listener. The connection is still encrypted.
    Warning: Use Basic authentication only with Use TLS for WinRM enabled. Without TLS, the username and password cross the network unencrypted.
12. If you chose Kerberos, under Kerberos Details, enter the Domain Name, the Key Distribution Center Address/Hostname, and the Service Principal Name. Enter the SPN in the form WSMAN/<host FQDN>, for example WSMAN/server.company.com.
13. For Credential Type, choose how to provide the credentials:
    • Enter Credentials to enter the credentials in the next step. This is the default.
    • Select Credentials to use credentials stored in a credential manager integration. Then, for Credential, choose the credential.
    Note: Select Credentials requires a configured credential manager integration. Credential manager integrations require additional licensing.
    Important: Your view of credentials depends on the workspace you have selected. Under Tenant you can select any credential in the tenant. Inside a workspace you can select only that workspace's credentials.
14. If you chose Enter Credentials, in Username, enter the account's user name. Then:
    • For Password authentication over SSH, or for WinRM, in Password, enter the account's password.
    • For Private Key authentication, in Private Key, paste the account's SSH private key. The key can't be protected by a passphrase.
    If you chose Select Credentials, the stored credential must hold the account's user name and password. For Private Key authentication, it holds the private key in place of the password.
    Note: Next-Gen Trust Security encrypts the credentials you enter and doesn't display them again. On the machine's Properties tab, they appear masked. To keep a stored credential when you edit the machine, leave its masked value unchanged. Keep your own secure record of the credentials in case you need them again.
15. Click Test Access. After the connection succeeds, click Continue. The Discovery step opens.
    Note: A successful test confirms that Next-Gen Trust Security can reach the host through the VSatellite, sign in, and run a command. It doesn't confirm that the account can read or write the keystore paths or restart services.
16. On the Discovery step, under Discovery Configuration, in File or Directory Path, enter the absolute path of a single keystore file, or of a directory to scan. Enter it in the form the host uses, for example /etc/ssl/certs on Linux or C:\certs on Windows. The path can't contain a .. segment.
17. (Optional) To scan the directory's subdirectories too, enable Include Subdirectories. It's disabled by default and has no effect when the path is a single file.
18. (Optional) In File Extensions, enter a comma-separated list of the file name endings to read in a directory. Each entry matches files whose name ends with it, so .pem matches every PEM file, and a whole file name such as cacerts matches a keystore that has no extension. Matching isn't case-sensitive, and the dot counts: .pem matches server.pem, while pem also matches a file named notapem. If you leave it empty, discovery reads .pem, .cer, .crt, .key, .jks, .keystore, .p12, and .pfx files.
19. (Optional) In Keystore Passwords, enter the passwords that open your password-protected JKS files and PKCS#12 archives, one per line. You can enter up to 25. Discovery tries them in order, and it also tries an empty password, so you don't need to enter one. Leading and trailing spaces count as part of a password, so don't pad a line.
    The passwords are visible while you type them.
    Note: Next-Gen Trust Security encrypts these passwords and doesn't display them again. On the machine's Discovery tab, they appear masked. To keep the stored passwords when you edit the machine, leave the masked value unchanged.
20. (Optional) To discover certificates on a schedule, enable Schedule. For Repeat every, choose Day, Week, or Month, and then in At, enter the time. For Week, select the days of the week. For Month, enter the days in Day of month. Times are in Coordinated Universal Time (UTC).
21. Click Continue. The Provisioning step opens.
22. (Optional) To provision certificates on a schedule, enable Schedule. For Repeat every, choose Day, Week, or Month, and then in At, enter the time. For Week, select the days of the week. For Month, enter the days in Day of month. Times are in Coordinated Universal Time (UTC).
    Scheduled provisioning pushes only certificates that are queued for deployment, such as renewed certificates, so renewals install during the window you choose.
23. Click Finish.

What Discovery Finds

• JKS files: the certificates in a JKS file are readable without the store password, so they're discovered even when none of your Keystore Passwords opens the store. Private keys aren't. An alias whose key password discovery doesn't know yields nothing, not even its certificate.
• JKS aliases: each alias is discovered as a separate installation. The installation keeps the alias and has Append to JKS enabled, so renewing one alias doesn't remove the others from the store. Trusted certificate entries, which have no private key, are discovered as installations too.
• PKCS#12 archives: an archive that none of your passwords opens is skipped, and the discovery run continues.

• PEM certificates: if discovery doesn't find the certificate's private key, Private Key Path (including filename) is blank. Discovery matches a key to a certificate cryptographically, never by file name. It searches the certificate's own file and the other files in the same directory, whatever their extension.
• JKS files: if none of your passwords opens the store, Store Password is blank.

What's Next?