The SSL key repository
This book uses the general term key repository to describe the store for digital certificates and their associated private keys. The specific store names used on the platforms that support SSL are:
For more information, refer to Digital certificates and Secure Sockets Layer (SSL) concepts.
i5/OS certificate store Windows and UNIX key database file z/OS key ring A fully authenticated SSL connection requires a key repository at each end of the connection. The key repository contains:
- A number of CA certificates from various Certification Authorities that allow the queue manager or client to verify certificates it receives from its partner at the remote end of the connection. Individual certificates might be in a certificate chain.
- One or more personal certificates received from a Certification Authority. You associate a separate personal certificate with each queue manager or WebSphere MQ client. Personal certificates are essential on an SSL client if mutual authentication is required. If mutual authentication is not required, personal certificates are not needed on the SSL client.
The location of the key repository depends on the platform you are using:
- i5/OS
- On i5/OS the key repository is a certificate store. The default system certificate store is located at /QIBM/UserData/ICSS/Cert/Server/Default in the integrated file system (IFS). On i5/OS, WebSphere MQ stores the password for the certificate store in a password stash file. For example, the stash file for queue manager QM1 is /QIBM/UserData/mqm/qmgrs/QM1/ssl/Stash.sth.
Alternatively, we can specify that the i5/OS system certificate store is to be used instead. To do this you change the value of the queue manager's SSLKEYR attribute to *SYSTEM. This value indicates that the queue manager will use the system certificate store, and the queue manager is registered for use as an application with Digital Certificate Manager (DCM).
On i5/OS the certificate store also contains the private key for the queue manager.
For more information, see Working with a key repository.
- Windows and UNIX
- On Windows and UNIX systems the key repository is a key database file. The name of the key database file must have a file extension of .kdb. For example, on UNIX, the default key database file for queue manager QM1 is /var/mqm/qmgrs/QM1/ssl/key.kdb. If WebSphere MQ is installed in the default location, the equivalent path on Windows is C:\Program Files\IBM\WebSphere MQ\Qmgrs\QM1\ssl\key.kdb.
On Windows and UNIX systems each key database file has an associated password stash file. This file holds encrypted passwords that allow programs to access the key database. The password stash file must be in the same directory and have the same file stem as the key database, and must end with the suffix .sth, for example /var/mqm/qmgrs/QM1/ssl/key.sth
On Windows and UNIX systems, PKCS #11 cryptographic hardware cards can contain the certificates and keys that are otherwise held in a key database file. When certificates and keys are held on PKCS #11 cards, WebSphere MQ still requires access to both a key database file and a password stash file.
On Windows and UNIX systems, the key database also contains the private key for the personal certificate associated with the queue manager or WebSphere MQ client.
- z/OS
- Certificates are held in a key ring in RACF. Refer to Set up a key repository for more information about creating a key ring in RACF.
Other external security managers (ESMs) also use key rings for storing certificates.
On z/OS, private keys are managed by RACF.
- Protecting WebSphere MQ client key repositories
- Refreshing a key repository
- Resetting SSL secret keys
Parent topic:
WebSphere MQ SSL support
sy10970_