Creating SSL/TLS certificates for use with UIM or MainView Explorer
You can configure the User Interface User Interface Middleware ( UIM ) server and the MainView Explorer server to use certificates and private keys to enable Secure Sockets Layer/Transport Layer Security (SSL/TLS). If you are not familiar with SSL/TLS certificates, this information provides an overview of the server certificates and general instructions for creating them.
Important
- Best practices for creating and managing certificates vary depending on which System Authorization Facility (SAF) application you are using. Also, the approach that you use can require coordination between multiple organizations within your enterprise. The procedures provided here represent examples that can help you get started.
- Methods of creating and using client-side certificates vary from site to site. The UIM and MainView Explorer servers honor any client certificates and implementation that is based on the Windows Certificate Store. For more information, see your system administrator.
You can use these types of certificates:
For procedures and samples see the following topics:
- Creating a self signed certificate
- Creating a CA signed certificate
- Sample JCL to create a self signed certificate for RACF
- Sample JCL to create a self signed certificate for CA ACF2
- Sample JCL to export a self signed certificate for RACF
- Sample JCL to export a self signed certificate for CA ACF2
- Sample JCL to create a CSR for RACF
- Sample JCL to create a CSR for CA ACF2
- Sample JCL to import CA signed certificates for RACF
- Sample JCL to import CA signed certificates for CA ACF2
- Sample JCL to create a key ring for RACF
- Sample JCL to create a key ring for CA ACF2
See the following resources for additional information about RACF and CA ACF2:
- For RACF:
- IBM z/OS Security Server RACF Command Language Reference, “RACF Command Syntax”
- IBM z/OS Security Server RACF Security Administrator's Guide, “Using the IBM Encryption Facility for z/OS”
- For CA ACF2:
- CA ACF2 for z/OS Quick Reference Guide, “Digitial Certificate Commands"
- CA ACF2 for z/OS Cookbook, "Digitial Certificate Support”
- CA ACF2 for z/OS Administrator Guide, “Digitial Certificate Support”
Self-signed certificates
The simplest and easiest type of certificate to implement is a single self-signed certificate (although most production environments require CA-signed certificates). Many web browsers do not initially recognize self-signed certificates as "trusted" (signed by a known authority), prompting errors or warnings such as this example from Mozilla Firefox:
As the following example from the BMC Database Management console shows, you are usually offered the choice of accepting a self-signed certificate for one-time use or permanently:
Accept a self-signed certificate only if you are certain that you know and trust the certificate's origin.
Important
Certificate Authority-signed (CA-signed) certificates
Most production environments require that you use certificates signed by a Certificate Authority (CA) instead of self-signed certificates.
Your enterprise might rely solely on external CAs, or might have its own CA that uses a "signing certificate" to sign other certificates within the enterprise. The signing certificate might be signed by an external CA. Either way, the "trusted root" certificates are preapproved and then pushed to truststores (certificate repositories) throughout the enterprise.
The result is a "chain of trust": your application presents a certificate that was signed by another certificate, which might have been signed by another, and so on, down to a root certificate in your truststore.
For example, consider the certificate that the Google homepage presents via the Firefox Certificate Viewer. The certificate for www.google.com was signed by an intermediate Google CA named Google Internet Authority G2. This intermediate CA was signed by the GeoTrust Global CA (included in most truststores because GeoTrust is a major third-party CA provider).
Comments
Log in or register to comment.