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.
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 +
OU('my organization') O('my section') C('AU')) +
WITHLABEL('my server certificate') +
SIGNWITH(CERTAUTH LABEL('my company’s CA
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
RACDCERT ID(FTPD) +
CONNECT(LABEL('my server certificate') +
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')) +
WITHLABEL('my company’s CA
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
After this, inspect the certificate and you should see something similar to this:
(some lines removed for brevity)
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.