What is a Truststore?
A trust store is a collection of Root certificates that are trusted by default and are maintained by the companies that make operating systems and web browsers, such as Apple, Microsoft, Mozilla, and Chrome. Each has its own standards and requirements for Root certificates but they all require an issuing CA to undergo one or more audits before their Root certificate is included. Trust store objects are created under devices and are associated with certificate trust bundles.
A certificate trust bundle is a collection of whitelisted and blacklisted certificates that are assigned to a truststore. The trust bundle is associated to the trust bundle and the trust bundle is the application that is provisioned from its associated device.
Trust Store configuration (including trust bundle assignments) can be done via policy and is the recommended method if there are many trust stores with the same configuration, otherwise a Certificate Trust Bundle object can be added underneath a policy and associated with the Truststore.
Sudo permissions for the ID being used to provision the truststore must be granted in the /etc/sudoers file in order for the TPP truststore application driver to successfully provision on UNIX.
The TPP truststore application driver will first see if the truststore exists in the designated directory and if it does then if will make a backup before provisioning the new trust bundle into the truststore.
As the truststore is being provisioned, the TPP application driver will create a tmp directory similar to below where it temporarily stores the file. It is removed after provisioning completes.
UNIX PEM, GSK, JKS and PKCS#12 Truststore Provisioning Commands and Permissions
UNIX provisioning uses SSH to provision the Truststores in PEM, GSK, JKS and PKCS#12 keystore format. This table shows the commands used for the formats. Sftp is used to transfer the keystore from the VTPP server. Set is a shell builtin command and uname does not need to be executed with any privileges. The UNIX commands cp, ls, rm and mkdir need to be executed as root in order to place the Truststore into the designated directory. In this example, /etc/default is used as the target directory.
Note: If mkdir has read and write permission to the /tmp directory, then sudo permission is not needed for mkdir.
sudoers file example entry
This /etc/sudoers example represents a least privilege security best practice. However, you should give serious consideration to using a password:
venafi01 ALL=NOPASSWD: /bin/cp, /bin/ls, /bin/rm, /bin/mkdir
Windows CAPI Truststore Provisioning Permissions
Windows uses WinRM to provision the Truststore in the CAPI store and requires an ID with local administrator rights in order to provision.
Blue Coat SSLVA, IBM Sterling Connect Direct, F5 LTM and Palo Alto Networks Provisioning Permissions
These devices would use the same access permissions as used for SSL certificate provisioning. Please refer to the Venafi TPP documentation for more information on setting up the credentials for the specific devices.
Info: About using Sudo
Configuring a trust bundle
Configuring trust stores