Default language.

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.

Related topic

Generating-configuration-jobs

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:

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:

dna_notSecure.jpg

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:

dna_notTrusted.jpg

Accept a self-signed certificate only if you are certain that you know and trust the certificate's origin.

Important

Most IT departments maintain a Windows repository called a truststore, which contains certificates and indicates whether they are trusted. Many web browsers and Oracle Java applications (such as the BMC Database Management console) also maintain their own truststores.

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).


 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*