Mainframe > Tips & Techniques > Systems Management

RACF and SSL Security With Digital Certificates

You can use RACF as your intra-company certificate authority, avoid costs and possibly extend it beyond your company perimeter to save even more money.

You can use RACF as your intra-company certificate authority, avoid costs and possibly extend it beyond your company perimeter to save even more money.

This article, a deep–dive about using digital certificates with RACF* to provide SSL encryption for communications links, provides a quick and practical how–to on the topic.

Digital certificates are provided free with your RACF installation. Organizations often pay for the capacity to verify digital certificates via one of the trusted well–known public certificate authorities (CAs). An alternative is using RACF as your intra–company CA and avoid substantial costs. With coordination between your company and business partners, you can even extend this RACF CA beyond your company perimeter and potentially save even more money on third–party CA validations.

Starting With Something Simple

Perhaps the simplest implementation of digital certificates is their use in encryption of FTP communication. I’ll begin with a simple FTP example and build on this as we progress.

In any FTP exchange there’s a server and a client. The client is by definition the end of the connection that initiated the file transfer. Note that it doesn’t matter in which direction data is moving—the FTP GET and PUT instructions used are irrelevant—since the client started the conversation.

z/OS as the Server

Digital certificates are first used when the server passes the client a certificate after initiating the FTP connection. The client uses this certificate to validate the identity of the server to which it’s attempting to connect. This is commonly referred to as “server certificate security.” In this scenario, the client presents no certificate, and the server doesn’t ask for one. All that’s required is that the client accepts and validates the certificate presented by the server.

Use the following RACF command to define a server certificate:

RACDCERT ID(FTPD) GENCERT +

  SUBJECTSDN(CN('your.server.name') +

  OU('my organization') O('my section') C('AU')) +

  WITHLABEL('my server certificate') +

SIGNWITH(CERTAUTH LABEL('my company’s CA

certificate'))

Some other glue gets involved here, as we need to somehow associate this certificate with the server we’re running. These pieces of glue are referred to as keyrings. Each keyring contains a set of digital certificates that may be used for various purposes. The following commands accomplish what we need in this case:

RACDCERT ID(FTPD) +

  CONNECT(CERTAUTH LABEL('my company’s CA

certificate') +

  RING(FTPSSL)

RACDCERT ID(FTPD) +

  CONNECT(LABEL('my server certificate') +

RING(FTPSSL) +

DEFAULT)

Of course we have to add the keyring definition prior to setting up its contents above, using this simple RACF command:

RACDCERT ADDRING(FTPSSL) ID(FTPD)

You can choose the name you use for the keyring, and the user ID will be the user ID associated with your FTP server.

Now the client needs a method for validating the certificate that the server presents. For this we used RACF as a CA and signed the certificate with this CA. We had to generate the CA prior to issuing the commands above, as it was used to sign the server certificate. Use these commands to generate the initial CA certificate:

RACDCERT CERTAUTH GENCERT +

  SUBJECTSDN(OU('my organization') +

  O('my section') C('AU')) +

  KEYUSAGE(CERTSIGN) +

WITHLABEL('my company’s CA

certificate')

Once the CA has been generated and used to sign the server certificate, let the client know about it. Export the CA and load it into the client software as a trusted root CA:

RACDCERT CERTAUTH +

  EXPORT(LABEL('my company’s CA

certificate')) +

  DSN('your-hlq.TEST.LOCCERTA.CERT

.B64')

After this, inspect the certificate and you should see something similar to this:

MIIChzCCAfCgAwIBAgIBADANBgkqhkiG9w0BAQUFADBGMQswCQYDVQQGEwJVUzEM

MAoGA1UEChMDSUJNMRMwEQYDVQQLEwpDUyBaL09TIENBMRQwEgYDVQQDEwtURVNU

(some lines removed for brevity)

yr9HX3/iEgDCjoIqCqtYe6pqLv2tbOZniTn

EMh+5gtgsXq1PLASBGrtwf+wjwlhs

4ELVGqaVwm2RUCHBTz75gTFvY6kY0bw3F0YE

Now when the client software attempts a connection to the z/OS* server, it’ll receive a copy of the server key. Our FTP client can use the CA certificate just imported to validate the server certificate presented.

Michael Cairns works for IBM as a technical specialist in the Tivoli zSecure range of software. Michael can be reached at mike.cairns@au1.ibm.com.


comments powered by Disqus
Buyers Guide

Advertisement

Optimal Service Delivery

Overcome eight key challenges and reduce costs

Advice for the Lazy Administrator

Steps you can take to avoid late nights and system frights.

A System Programmer's Guide to Data Warehousing

A mainframe systems programmer must address high-level issues when installing a data warehouse

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
AIX News Sign Up Today! Past News Letters

Advertisement