Creating a JKS application object

To enable Trust Protection Platform to manage certificates for JCEKS and JKS keystores, you must configure a JKS application object. This object provides the information Trust Protection Platform needs to monitor, enroll, or provision certificates for JCEKS and JKS keystores.

BEST PRACTICE Consider managing object settings using a policy. For more information, see Managing applications using policies.

DID YOU KNOW? When you add an installation to a certificate, you'll have the option of defining (and editing) this object during that process, which means that you don't have to log in to Policy Tree as the following procedure describes. And because the settings are the same, you can use this topic for information about each setting.

For more information, see Creating a certificate installation.

To create and configure a JKS application object

From the TLS Protect menu bar, click Policy tree.
In the Policy tree, select the device object to which you want to add the new application object, and then click Add > Application, and then select JKS.
When the new application object page appears, then under Status, clear the Processing Disabled checkbox.

When checked, this option disables provisioning of the certificates installed on the current application. This means that Trust Protection Platform does not attempt to install, renew, process, or validate certificates on the application.
(Optional) In the Device Certificate box, click to select and associate a certificate with the new application.

NOTE If you don't have a certificate ready, you can do this later or you can do it on the certificate's Association tab.

To associate a certificate with the current application, you must have write permissions to the application object and either write or associate permissions to the certificate object.

For detailed information on associating a certificate with an application, see Associating a certificate with an application object.
Under General, do the following:
1. In the Application Name field, type a name for the new application.
2. (Optional) In the Description field, type a description for the purpose of the application.
  
  A strong description can help to provide context for other administrators who might need to manage the new application.
3. In the Contacts field, select user or group identities you want assigned to this application object (or choose the Use policy value to configure contacts using a policy).
  
  Default system notifications are sent to the contact identities. The default contact is the master administrator.
  
  TIP If the Identity Selector dialog is not populated when it first opens, enter a search query to retrieve the Identity list. The administration console does not automatically display external users and groups. You must first enter a search string so Trust Protection Platform can query the external Identity store, then return the list of requested users or groups. If you want to display all user or group entries, enter the wildcard character (*).
  
  Press Shift+click to select multiple, contiguous users and groups. Press Ctrl+click to select multiple, discontiguous users and groups.
4. In the Approvers field, select user or group Identities you want to assign to approve workflows (certificate approval or injection command) for the new application.
  
  The default approver is the master administrator. For more information on defining workflow objects, see Implementing certificate workflow management.
5. (Conditional) If your application (or certificate) object is affected by a defined workflow and you want users to use a console other than Policy Tree, click Managed By and select which administration console to use as part of the workflow.
  
  You only need to configure this if you are using workflows and expect users to perform a task using a particular administration console. The default setting is Policy Tree.
  
  For more information, see Specify folders and certificates to be managed by TLS Protect .
Under Application Information, do the following:
1. Click next to Application Credential to browse for the credential object that you want to use to authenticate with the application.
  
  DID YOU KNOW? Credential objects store the credentials Trust Protection Platform uses to authenticate with devices, applications, and CAs. The stored credential might be a user name or private key credential; some drivers—such as F5, which is not SSH-based—can only use the user name credential for authentication.
  
  NOTE The user account you select must have Read and Write access to the Temporary, Private Key, and Certificate directories.
  
  For more information, see Working with system credentials.
  
  DID YOU KNOW? The Connection Method is the protocol that Trust Protection Platform uses to connect to the server and manage the certificates installed on that server. In an application object's settings, this field is typically read-only.
2. (Conditional) In the SSH Port field, specify the port number that Trust Protection Platform should use to communicate with the appliance via an SSH connection.
  
  The default SSH port assignment is 22.
3. (Optional) In the Port field, type the port that Trust Protection Platform should use to communicate with the server where the application is installed.
  
  Trust Protection Platform uses the SSH protocol to communicate with the application server installed on Linux or Windows. The default SSH port assignment is port 22.

Under Remote Generation Settings, click the Private Key Location list and select where you want remotely generated key pairs to be created:

TIP The Thales SafeNet Luna SA HSM and Entrust nShield HSM settings are not visible if you have not activated Advanced Key Protect. For more information, see Enabling Venafi Advanced Key Protect.
- Device: Key pairs are generated on the device. This is the default setting.
- Thales SafeNet Luna SA HSM: Key pairs are generated on a Thales SafeNet Luna SA HSM. When you select this option, do the following:
  - In the Slot Number field, type the HSM slot number used by your JKS.
    
    The slot is actually the only contents of the JKS file. If the JKS file doesn't exist, the Venafi JKS driver creates it using the specified slot number. If the JKS file already exists, the driver simply verifies that the slot specified in the file matches the Trust Protection Platform configuration.
- Entrust nShield HSM: Key pairs are generated on an Entrust nShield HSM. When you select this option, do the following:
  - In the Java Vendor field, select the vendor of the JDK you have installed on the device (either Oracle or IBM).
  - In the Protection Type field, select the appropriate level of protection:
    - Module: This is the baseline protection level. It requires that your device has been properly configured to use the HSM for key generation.
      If you select this protection type, the Key Store Credential and Private Key Credential values are required.
    - Softcard: This is a higher level of protection and is a kind of password that is stored on your HSM.
      If you selected Softcard as the Protection Type, then in the Softcard Identifier field, enter your softcard's 40-character hash.
      Selecting this option requires that the device has been properly configured to use the HSM for key generation and that a softcard has been previously generated using the HSM and that the requester knows the passphrase for that softcard.

Refer to the following table to complete the remaining settings:

Field	Policy	Description
Java Keystore Settings
Keytool Path		Full path name of the Java keytool utility. A full path includes the path and the filename. For example: `/bin/keytool`. Beginning with Trust Protection Platform 15.4, the Keytool Path only applies when Generate Key/CSR on Application is enabled on the certificate object.
Version		Version of the Java Keytool utility you are using to manage keystores. Trust Protection Platform supports the following versions of the Java Keytool utility: Java 1.6 Java 1.7 Java 1.8
Store Type		Type of store managed via the current JKS Application object. The store type determines the key file format. You must select the keystore type supported by the platforms and applications that consume the keystore’s certificates. Trust Protection Platform supports the following keystore types: JCEKS JKS
Keystore		To configure these settings via policy, go to the Applications > JKS tab in the policy object's configuration. The JKS keystore settings defined in the Policy object may be inherited by all subordinate JKS application objects.
Keystore Path		Full path to the keystore. A full path includes the path and the filename. For example: `/opt/pki/keystore.jks`
Keystore Credential		Password used to access the keystore. Click the Browse button to open the Credential Selector dialog. Select a Password Credential object, and then click Select. If you select the Create option to create a new keystore, Trust Protection Platform defines a new keystore password using the current credential. Trust Protection Platform does not include the key store password on the command line when performing key management operations via the Java Keytool utility. Instead, it causes the utility to prompt for the password.
Private Key Credential		The credential required to access the private key file for certificate renewal. To select a private key password credential Click to open the Credential Selector dialog. Select the credential required to access the private key file for certificate renewal, and then click Select. For more information, see Working with system credentials.
Create		Creates a new keystore file, if one does not already exist.
Replace Existing		Deletes the existing keystore and creates a new one. This option is available only when the Create option is selected. Trust Protection Platform automatically deselects this option after it replaces the keystore.
Processing Options		The following are server-specific certificate settings. They are referenced only when you associate a certificate with a current JKS application object.
Certificate Alias		A label that is assigned to the key/certificate in the keystore so it can be used by servers and applications accessing the Java Keystore. This value must be unique within the keystore. NOTE When certificates are discovered by the Server Agent, the agent captures and sends the certificate label to Trust Protection Platform using the existing friendly name JSON object property. Trust Protection Platform then sets the certificate label value when it creates the new application object. DID YOU KNOW? Depending on the trust store, this setting goes by different names. For example, GSK refers to this setting as the Certificate Label, JKS refers to it as the Certificate Alias, and CAPI and PKCS#12 refer to it as the Friendly Name.
Reuse Alias		Reuses the alias that is assigned to the key/certificate in the keystore when the certificate is renewed. This option keeps the existing certificate available during the renewal process and simplifies management of the applications that use the key/certificate referenced by the alias.

(Optional) Under File Ownership and Permissions, select Yes on the Set Owner and Permissions after Provisioning Files drop-down—if you want to set specific permissions and ownership on files after they have been provisioned by Trust Protection Platform—and then do the following:
1. In the Owner field, type the user account name of the user who should have access to the provisioned files.
  BEST PRACTICE Who you assign as owners and approvers of your certificates is an important part of your PKI strategy. This is especially true because employees continue to pose the greatest threat to securing trust. Typically, this is because many employees fail to follow security best practices.
2. From the Owner Permissions list, select the level of permissions you want to grant to the owner (Read, or Read and Write).
3. In the Group field, type the group name to which the owner belongs.
4. From the Group Permissions list, select the level of permissions you want to grant to that group (None, Read, or Read and Write).

When you are finished, click Save.

For additional HSM configuration information, see Managing applications using HSM-protected keys and Venafi Advanced Key Protect and Configuring HSM-based remote key generation.

What's next?

After you've created an application object, here are other things you can do to manage the new application:

On the application's Settings sub-tab:
- Click to push a certificate to its associated application.
  
  For more information, see Pushing a certificate and private key to an application .
- Click Reset to stop processing the application and reset the status and stage.
- Click to reattempt installation of the certificate to its associated application, .
- Click Validate Now to validate the applications associated certificate.
  
  Validation requests are placed into a queue. When your validation runs, the application and its associated certificate are scanned according to the settings configured in the application object’s Validation tab.
  
  For more information, see About certificate and application validation.
On the application object's Validation tab, you can configure validation settings for the application object.
On an object's General tab:
- Click the Log sub-tab to view any events that are triggered by the template object.
- Click the Permissions sub-tab to configure the users or groups to whom you want to grant permissions to the new object. For more information, see Permissions overview.