z/OS Security Server RACF Security Administrator's Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Certificate hierarchies

z/OS Security Server RACF Security Administrator's Guide
SA23-2289-00

Certificate authorities digitally sign the certificates they issue using their own private key. Thus, another party can verify the information in a certificate, including its extensions, by validating the signature on the certificate with the certificate authority's own public key. The other party gets the certificate authority's public key from a certificate issued to the certificate authority and does a signature check that might involve the public key from yet another certificate. The chain of verification can be quite long, depending on the certificate hierarchy. Figure 1 is an example of a simple certificate hierarchy.
Figure 1. Example of a simple certificate hierarchyExample of a simple certificate hierarchy

Figure 1 is a representation of a certificate hierarchy containing four entities where the end-entity certificate is issued by subordinate certificate authority (CA #2). The certificate of CA #2 is issued by subordinate certificate authority (CA #1). The certificate of CA #1 is issued by the root certificate authority. The certificate of the root certificate authority is self-issued, meaning that its certificate is signed by its own private key (a self-signed certificate).

The chain of signature verification begins with the end-entity certificate. The public key of CA #2 is used to verify the signature of the end-entity certificate. If the signature is valid, the public key of CA #1 is used to verify the signature of the CA #2 certificate. If the signature is valid, the public key of the root certificate is used to verify the signature of the CA #1 certificate. Finally, the signature of the root certificate is verified using its own public key.

Signature verification for the self-signed root certificate simply provides assurance that the root certificate is unaltered. It does not guarantee that the information in the certificate, or the certificate authority itself, is trustworthy because anyone can create a self-signed certificate and claim to be a certificate authority. You must establish trust in your own selected set of certificate authorities and individual certificates before using public key protocols.

Your selected set of trusted certificates or CAs might be referred to using various terms, such as your trusted roots, trusted signers, or, simply, your trust policy. RACF® supports your trust policies through RACF key rings. For details, see RACF and key rings.

RACF, like other security software that supports digital certificates, has a method for supplying a predefined set of trusted root certificates. RACF includes a base set of well-known certificate authority certificates that are added to the RACF database whenever the system is IPLed. Unlike with other security software, these certificates are initially disabled. They are supplied as a convenience so that you need not define them yourself. However, you must determine which of these certificate authorities to trust, if any, and you must enable trust for those. For details, see Supplied digital certificates.

Remember: You must select and enable trust for the certificate-authority certificates supplied with RACF before using them. Perform Steps to begin using a supplied CA certificate.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014