For full server and client authentication, the digital certificates must be stored in a repository accessible by the secure sockets function used by the application. The application code differs, depending on the type of certificate repository, so the type and location of the repository is generally passed as a parameter to the application. An application references a specific certificate by its “label,” which is assigned when the certificate is generated. A certificate repository can also specify one certificate to be its “default,” allowing applications to use the default certificate without having to know or specify its label.
z/OS supports three certificate repositories:
- HFS Database — Digital certificates can be saved in an HFS database. Multiple databases can exist and each database can hold multiple certificates. The database must be protected by a password, which can be encrypted and saved in a stash file. The application must know the full path name to the database and the password or the stash file name.
- RACF Keyring — Digital certificates can be saved in a keyring database managed by RACF. A keyring can contain one or more digital certificates and can have one certificate assigned as the default. Multiple keyrings can exist on one system. RACF keyrings have three categories of certificates: those owned by a specific user, certificates owned by a CA, and SITE-level certificates. With RACF keyrings, the application only needs to know the keyring name and have sufficient authority to access the keyring.
- LDAP Server — Digital certificates can be stored on a server supporting the Lightweight Directory Access Protocol (LDAP). Certificates are referenced by their LDAP distinguished name. Although an LDAP server is available on z/OS, the server can run on any platform with the advantage of having a central repository for all certificates. To use LDAP-based certificates, the application needs to know the IP address or host name of the LDAP server and may need to know an LDAP user ID and password, if required.
CREATING AND MAINTAINING DIGITAL CERTIFICATES
Two distinct tools have been provided to manage digital certificates on a z/OS system:
- GSKKYMAN command — This command is supported from the OE shell and is used to create and maintain HFS-based key databases. Although it is possible to manage certificates using an extensive range of command options, the easiest way is to use the GSKKYMAN command with no options, as this provides a menu-driven system for creating and maintaining certificates.
- RACDCERT command — This command can be used to create and maintain RACF keyrings. The RACDCERT command can be used natively, or the RACF ISPF Dialogs can be used to drive the RACDCERT command.
Both tools provide the range of functions required to create and manage certificates, including:
- Creating the HFS key database or RACF keyring
- Creating and exporting certificate requests to be sent to a CA
- Importing the fulfilled certificate request after it has been signed by the CA
- Importing and exporting certificates to/from files
- Creating self-signed certificates
- Listing certificate contents.
True digital certificates must be “signed” by a trusted CA (such as Thawte or Verisign). Before using a trusted CA, a certificate identifying the CA must be installed on the system where the certificates are to be used. In z/OS, certificates for some of the more common CAs are provided by default, removing the need to obtain the certificate from the CA.
To obtain a digital certificate, a certificate request must be generated and sent to the CA using one of the digital certificate management utilities. The CA processes the certificate request and a “signed” version of the certificate is returned to the requestor. This signed certificate must be installed on all systems that need the certificate for authentication using the certificate management utilities.
Although full server and client authentication can only be achieved using digital certificates signed by a trusted CA, it is not always necessary to purchase a digital certificate from a CA. In situations where secure sockets are only being used inside a private network, the organization can act as a CA for itself and its certificate can be added to all clients as another trusted CA. Certificates for other clients and servers within the private network can then be issued by the “internal CA,” giving a high level of internal security. Technically speaking, systems within the private network could use the internally issued certificates to communicate with systems outside the network. However, the outside systems would need to have knowledge (and trust) of your organization sufficiently to accept the internally signed certificates.
Finally, it is also possible to create self-signed certificates. These do not require any internal or external CA for authentication and therefore have little security value. However, self-signed certificates are very useful when implementing new applications to test for correct SSL/TLS functionality prior to requesting and receiving officially signed certificates.
IBM SERVER SUPPORT FOR SECURE SOCKETS