The PKI server provides a certificate management package on z/OS. It provides a web interface for requesting and processing certificates, and updates LDAP if the certificates are revoked. I feel that there should be a command interface; but you can write your own using callable services.
I wanted to try this to generate certificates I could use with MQ, and check out the OCSP certificate validation in MQ.
Ultimately I was not able to get this working, as PKI depends on ICSF, which depends on some encryption technology which is not available on my zPDT system running z/OS on Ubuntu Linux. There were also bugs in the Web server files which initially stopped me from generating certificate requests.
I hope my experiences of my journey can help others who are trying to install it.
I’ve documented PKI and HTTPD server here.
Overall it took me a couple of days to get the PKI server up and working. If I had blindly used the product defaults – it might have been quicker, but more dangerous.
The documentation is more of a configure everything, then try to start it. I prefer baby steps, where you start small, get the smallest system working, then add more function to it. For example there are 15 pages of parameters for pkiserv.conf. I would rather be given a file of parameters you must have, and you gradually extend it.
You can have multiple PKI instances, for example if you have different CA authorities. There is a red book on this. I recommend you get the simple environment working first, then create the multi CA environment. This may mean you throw away the first configuration, but you will have had valuable experience of setting it up.
The PKI Server is documented in Cryptographic Services PKI Services Guide and Reference (SA23-2286-50)
Overview
- The PKI server is an application that runs as a started task.
- For the end user, you can have
- Apache HTTPD web server and Rexx execs,
- or WAS Liberty with Java Server Pages.
- or full function WAS.
- It stores information about certificates in VSAM files.
- It needs a Certificate Authority certificate, and a Registration Authority certificate. A registration authority (RA) is responsible for accepting requests for digital certificates and authenticating the entity making the request.
- The server needs to be able to issue commands as a surrogate – on behalf of other users.
- The PKI server stores information in LDAP.
Before I started I set up an LDAP server, and the HTTPD server, as it takes some time to set these up and get working (baby steps).
Setting up the RACF environment.
The IBM documentation is here.
There is a set-up script which can execute the RACF commands you need, or you can have the script display the commands (and not execute them).
I had problems with the definitions it was creating, so I took the list of commands, and modified them before executing them. It feels that you must customise the script. I think it look longer to change the script, run it, change it etc until it all worked, than it would if I had edited the JCL with the statements embedded.
The setup script does the following
- Creates some system wide profiles, some of which you may already have defined. Example profiles:
- RDEFINE FACILITY BPX.SERVER
- Enables Enhanced Generic Naming (EGN) which allows you to specify the generic character ** in datasets. This is most likely to be enabled anyway, but I did not want to enable this without proper consideration.
- Activates generic profile checking for CSFKEYS CSFSERV etc.
- Activates class CSFSERV and RACFLISTs it
- Creates a userid, and group
- You can specify a OMVS UID and GID, (or let them default). I changed it to use OMVS AUTOUID and AUTOGID.
- It sets up a dataset profile ADDSD ‘PKISRVD.**’ and gives the started task userid, and the PKI admin group access to this.
- Gives the started task userid access to IRR.DIGTCERT.LISTRING to be able to keyrings. I use the more specific RDATALIB, and give access to individual keyrings, rather than the more general IRR.DIGTCERT…. facility.
- Sets up the certificates and keyrings
- I prefer to use Elliptic Curve keys, rather than the default RSA. You can specify an option in IKYSETUP to pick which option(s) you want.
- I had an existing CA certificate I wanted to use. It had been distributed to my whole enterprise (my laptop). You can set an option to not generate a certificate.
- It has a naming scheme like SUBJECTSDN(OU(‘SSS’) O(‘Your Company’) C(‘GB’)), which does not match mine. My CA is CN=SSSCA,OU=CA,O=SSS, without the Country specification. You can change the Rexx exec to whatever you want. I would rather change the raw RACDCERT definitions, than change the Rexx, and rerun it (and keep rerunning it till it worked).
The configuration script IKYSETUP, has nearly 2000 lines, and you have to carefully read 1000 lines, and change some (perhaps 50) lines of Rexx (and fix them when you get them wrong).
When I ran it, I experienced problems like
- trying to allocate a data set IKYSETUP.LOG failed, because IKYSETUP is not a valid userid on my system. I had to put trace statements into the rexx to find out the problem. I edited the log_dsn=… statement to an acceptable name.
- It tried to allocate a log with the ca_domain as the HLQ. I set ca_domain = “” to prevent this.
- Rerunning the command did not always work, for example after I changed an adduser command, the second time the command failed because the userid already existed. I had to add a “delete user” command to get it to work.
- The userid running the script was not put into the PKIGRP group.
- The PKIGRP needs ALTER access to ‘PKISRVD.**’ – not just CONTROL.
- It uses RALTER PROGRAM * when RALTER PROGRAM ** is better. (if you use RLIST PROGRAM * – you get all definitions. If you use RLIST PROGRAM ** you get just those with **)
The RACF statements were written like
- Define a profile
- Give the ID access to the profile.
I think it is better to split these especially when there is a system wide resource. You create it in one file, and give access in other files.
If you add a user, then you may want to do a delete user before the add user command (or to do a list user followed by a delete user – in case you get it wrong).
Where the script has
RDEFINE FACILITY IRR.DIGTCERT.LISTRING
You do not want to just delete this, as the profile may be used by other applications.
I’ve been managing my certificates by RDATALIB rather than FACILITY, so I had to create my own definitions in a file. I was much more comfortable using the PDS members with the definitions in them.
I’ve put the files up on github.
- Review and run the SYSTEM files.
- Review and run the USER files
- Review and run the INSTANCE file.
- Connect your userid to the PKIGRP group. CONNECT IBMUSER GROUP(PKIGRP)
- To backup the certificate the userid issuing the command needs ALTER access to ‘PKISRVD.**’ The group PKIGRP is only given CONTROL.
- PERMIT ‘PKISRVD.**’ ID(PKIGRP ) ACCESS(ALTER )
- Optional Review the UNIX file which does RALTER PROGRAM **… for the CSF libraries (and others if needed).
My process of defining the server
I suggest you do the RACF configuration first, so you set up the High Level Qualifier, and RACF profile before you create the VSAM data sets, because you do not usually want to have the VSAM data sets cataloged in the master catalog.
You should use an existing HLQ, or define an alias for PKISRVD to point to an existing user catalog. See create an ALIAS, and create a user catalog if you do not have a user catalog.
If you have to move systems (for example upgrading your zPDT system) you just need to import the catalog, and rerun the define alias command, and all the datasets will be available on your new system (rather than have to re-catalog the individual data sets).
Create the VSAM files
This was easy,
- copy SYS1.SAMPLIB(IKYCVSAM) to your PDSE.
- change the job card
- change VOL(vvvvvv) to VOL(USER00)
- If you want to change the HLQ, change PKISRVD to the new HLQ
If you have to rerun the job, it deletes the datasets before recreating them (great!).
You might need to talk to your Storage Administrator about any other parameters you need, for example how often the data sets should be backed up, or migrated. The Storage Administrator may need to change the SMS profiles for the High Level Qualifier.
For production make sure these data sets are backed up regularly and taken off-site.
There is a lot of good information in the documentation on this.
You can display the contents of the VSAM datasets using the iclview shell command. I had to set up a shell script with
export PATH=/usr/lpp/pkiserv/bin/
export LIBPATH=/usr/lpp/pkiserv/lib
export NLSPATH=/usr/lpp/pkiserv/lib//usr/lpp/nls/msg/%L/%N
/usr/lpp/pkiserv/bin/iclview -d \’PKISRVD.VSAM.ICL\’
You need to escape the data set name.
During first set up (where I changed the CA I wanted to use) I got
Error 76677164 initializing ICL: The CA certificate in the ICL does not match the one in the keyring
I had to recreate the VSAM datasets.
This is documented here.
Check to see if the runtime instance directory exists, and if not, create it. You need one for each PKI Server. The documentation recommends /etc/pkiservd, but you can use another one.
ls -ltr /etc/pkiservd
mkdir /etc/pkiservd
Copy files from the supplied sample.
cp -r /usr/lpp/pkiserv/samples/* . /etc/pkiservd/
Edit pkiserv.conf
You need to change the LDAP information.
[LDAP]
NumServers=1
PostInterval=5m
Server1=127.0.0.1:389
AuthName1=cn=ibmuser, o=Your Company
AuthPwd1=password
Later you can change the file, and use a LDAPBIND profile, and remove the need to have the password stored in clear text.
Find KeyRing= and change (if necessary) the keyring value matches the value or the ring you created. ISPF may have upper cased it.
Check RALabel= for the one you created.
Edit pkiserv.envars and change _PKISERV_CONFIG_PATH= to the instance path.
Review the started task JCL PKISERVD
I changed the time zone. The JCL looked like
//PKISERVD PROC REGSIZE=256M,
// OUTCLASS='H',
// TZ='gmt0',
// FN='pkiserv.envars',
// DIR='/etc/pkiserv'
// STDO='1>DD:STDOUT',
// STDE='2>DD:STDERR'
Start it using S PKISERVD, and resolve any problems. You can stop it using P PKISERVD.
ColinPaice 