Certificate stores

A certificate store is a special key database file that Digital Certificate Manager (DCM) uses to store digital certificates.

The certificate store contains the certificate's private key unless you choose to use an IBM® Cryptographic Coprocessor to store the key instead. DCM allows you to create and manage several types of certificate stores. DCM controls access to certificate stores through passwords in conjunction with access control of the integrated file system directory and the files that constitute the certificate store.

Certificate stores are classified based on the types of certificates that they contain. The management tasks that you can perform for each certificate store vary based on the type of certificate that the certificate store contains. DCM provides the following predefined certificate stores that you can create and manage:

local Certificate Authority (CA): DCM uses this certificate store to store local CA certificates and associated private keys. You use a local CA certificate in this certificate store to sign or issue other certificates that you create. When a local CA issues a certificate, DCM puts a copy of the CA certificate (without the private key) in the appropriate certificate store (for example, *SYSTEM) for authentication purposes. You can create more than one local CA. When you create a certificate in one of the other certificate stores, you select which CA to sign that certificate. Creating more than one CA can be useful. For example, in cases where you want to upgrade to use ECDSA certificates but still must also continue to issue RSA certificates for clients that do not yet support ECDSA. Applications use CA certificates to verify the origination of certificates that they must validate as part of the Transport Layer Security (TLS) negotiation to grant authorization to resources.
*SYSTEM: DCM provides this certificate store for managing server or client certificates that applications use to participate in TLS communications sessions. IBM i applications (and many other software developers' applications) are written to use certificates in the *SYSTEM certificate store only. When you use DCM to create a local CA, DCM creates this certificate store as part of the process. When you choose to obtain certificates from a public CA, such as VeriSign, for your server or client applications to use, you must create this certificate store.
*OBJECTSIGNING: DCM provides this certificate store for managing certificates that you use to digitally sign objects. Also, the tasks in this certificate store allow you to create digital signatures on objects, as well as view and verify signatures on objects. When you use DCM to create a local CA, DCM creates this certificate store as part of the process. When you choose to obtain certificates from a public CA, such as VeriSign, for signing objects, you must create this certificate store.
*SIGNATUREVERIFICATION: DCM provides this certificate store for managing certificates that you use to verify the authenticity of digital signatures on objects. To verify a digital signature, this certificate store must contain a copy of the certificate that signed the object. The certificate store must also contain a copy of the CA certificate for the CA that issued the object signing certificate. You obtain these certificate either by exporting object signing certificates on the current system into the store or by importing certificates that you receive from the object signer.
Other System Certificate Store: This certificate store provides an alternate storage location for server or client certificates that you use for TLS sessions. Other System Certificate Stores are user-defined secondary certificate stores for TLS certificates. The Other System Certificate Store option allows you to manage certificates for applications that you or others write that use the gsk_environment_init API to programmatically access and use a certificate to establish an TLS session. This API allows an application to use the default certificate for a certificate store rather than a certificate that you specifically identify. Most commonly, you use this certificate store when migrating certificates from a prior release of DCM, or to create a special subset of certificates for TLS use.

Note: If you have an IBM Cryptographic Coprocessor installed on your system, you can choose other private key storage options for your certificates (with the exception of object signing certificates). You can elect to store the private key on the coprocessor itself or use the coprocessor to encrypt the private key and store it in a special key file instead of in a certificate store.

DCM controls access to certificate stores through passwords. DCM also maintains access control of the integrated file system directory and the files that constitute the certificate stores. The local Certificate Authority (CA), *SYSTEM, *OBJECTSIGNING, and *SIGNATUREVERIFICATION certificate stores must be located in the specific paths within the integrated file system, Other System Certificate stores can be located anywhere in the integrated file system.