Certificate and password management

To securely transfer information between servers and clients, we can configure IBM Security Verify Access to use server-side and client-side certificates, key files, and stash files for authentication. During the initial configuration, we can configure the settings for the default lifetime of the certificates and the key file passwords. This information describes certificate and password management from the perspective of the administration C API run time. However, ISAM also provides a Java run time to complete the same tasks. For information about the administration Java runtime and classes, see the Administration Java Classes Developer Reference and the Authorization Java Classes Developer Reference.

Security Verify Access can use Secure Sockets Layer (SSL) for encryption, system authentication, and application-level authentication. SSL uses certificates to ensure a secure environment. SVA can also use Transport Layer Security (TLS) version 1 and SSL. TSL can be enabled to work when compliance modes are enabled. The policy server acts as the certificate authority (CA) and is responsible for creating and renewing certificates. The ISAM runtime package (pdrte) relies on only SSL server-side authentication and does not require a client-side certificate. All of the ISAM servers, including the policy server, authorization server, policy proxy server, and resource manager server, rely on client-side certificates to operate.

The ISAM servers use certificates to authenticate themselves. For example, when the authorization server wants to communicate with the policy server, it presents its client-side certificate. In this example, the policy server is considered the server, and the authorization server is the client. The policy server verifies the certificate is valid and is signed by a trusted signer. In this case, the trusted signer is the policy server itself, using the SVA certificate authority (PDCA) certificate. The authorization server does the same for the certificate presented by the policy server. During the ISAM application-level authentication, the policy server:

If the authentication succeeds, then the servers can communicate.

The certificates used by ISAM are in key files. Key files have a .kdb extension (or .ks extension for Java keystores). Key files must be secured and protected by the strictest operating system controls available, because they contain the private keys for the certificates. For example, the key file for the policy server is ivmgrd.kdb and, by default, it can be read and written to by only the ivmgr user.

The certificate files in a directory need to be accessible to the user ivmgr (or all users). Ensure the ivmgrd.kdb file and the directory or folder containing the ivmgrd.kdb file is accessible by the user ivmgr or all users. Ensure these users have the appropriate permissions for this file.

Furthermore, to facilitate unattended server operation, there are files that contain an obfuscated (not encrypted) version of the password to the key files. These versions are stash files, which are denoted by a .sth file extension. Java key files generated by ISAM do not have correspondingstash files. These stash files must be secured using the local standard operating system measures. For the policy server, the stash file is ivmgrd.sth and its permissions are the same as the ivmgrd.kdb key file.

For security reasons, both the certificates and the key file passwords can be set to expire after a configurable amount of time. The default lifetime for a certificate is four years. The default lifetime for a key file password is 183 days. The fixed lifetime for the PDCA certificate is 20 years. By default, the ISAM servers refresh the certificates and passwords automatically while they are running. The refresh process reissues a new certificate with a new lifetime and generates a new password with the configured lifetime.

The SVA calculates the life span of the certificate when you open the security context. When opening the security context, the ISAM verifies the need to refresh the context. If there is a need to refresh the certificate, then Security Verify Access creates an SSL context with the new certificate and processes the request.

If the servers are not running in a specified time frame, then their certificates or passwords can expire. In this case, a manual refresh is necessary. Also, if a certificate or a password or the entire key file is damaged, manually refresh it. Refreshing the expired or damaged certificate, password, or key file is necessary to maintain the security of the ISAM domain. For information about manually refreshing the certificates, passwords, and key files, see Key file and stash file renewal information.

Parent topic: Verify Access Platform and Supporting Components administration