The TLS related certificate(s) need to be available to mainframe clients.
The certificate(s) are stored in a certificate store accessible to the mainframe client.
There are multiple mainframe client certificate store options available. They include:
- SAF key ring
- Key database file
- PKCS#11 token
The customer can select whatever technique they prefer. The SAF key ring is a traditional approach.
They will load the certificate(s) into the store and later configure Teradata Gateway Mediated CLI to reference the store.
SAF Key Ring
The certificate(s) needs to be uploaded to the mainframe where they can be loaded by RACF.
In some cases of signed certificates, the certificate authority chain may already be loaded. Inquire with site RACF administrator.
Instructions for adding the certificate are provided by IBM and can be found in the IBM manual, “z/OS Security Server RACF Command Language Reference” under the heading “RACDCERT ADD (Add certificate)”.
A customer can choose to add the certificate(s) to either:
- ID(<certificate-owner>)
- SITE
- CERTAUTH
The certificate(s) should be marked “TRUST” when added.
A traditional approach for a self-signed certificate would be to add the server certificate to SITE. For a signed certificate, a traditional approach would be to add the certificate authority chain to CERTAUTH.
Alternatively, a customer may create a new RACF user or leverage an existing RACF user and store the certificate(s) under that ID. From there a key ring can be created for that user and the certificate(s) connected to that key ring. These instructions can be found in the IBM manual, “z/OS Security Server RACF Command Language Reference” under the headings “RACDCERT ADDRING (Add key ring)” and “RACDCERT CONNECT (Connect a certificate to key ring).” For other users to leverage this user’s key ring, the following permission is needed by all users that wish to leverage certificate for TLS connectivity:
UPDATE on profile IRR.DIGTCERT.LISTRING in class FACILITY
Key Database File
Key database files are Unix System Services password protected files.
Instructions for creating and managing a key database can be found in the IBM manual, “z/OS Cryptographic Services System SSL Programming” under the heading “gskkyman overview.”
In the case of a self-signed certificate, load the single server certificate into the key database.
In the case of a signed certificate, load the certificate authority certificates into the key database.
Take note of the password used to protect the Key Database as it will be needed later.
PKCS#11 Token
PKCS#11 tokens are another mechanism for storing certificates.
Similar to the KEY Ring method, the certificate(s) need to be added to system.
Instructions for this are provided by IBM and can be found in the “z/OS Security Server RACF Command Language Reference” manual under the section “RACDCERT ADD (Add certificate)”
A customer can select to add the certificate(s) to either:
- ID(<certificate-owner>)
- SITE
- CERTAUTH
The certificate(s) should be marked “TRUST” when added.
With the certificate added, a token can be created. Instructions for this are provided by IBM and can be found in the IBM manual, “z/OS Security Server RACF Command Language Reference” under the heading “RACDCERT ADDTOKEN (Add token).”
Once the token is created, the certificate(s) need to be bound to the token. Instructions for this are provided by IBM and can be found in the IBM manual,“z/OS Security Server RACF Command Language Reference” under the heading “RACDCERT BIND (Bind certificate to token).”