Setting up the Root CA environment
In this chapter, the process that is used to build the PKI Services environment for the ROOTCA is described.
2.1 Setting up PKI services rootca environment
Samples for setting up an environment are provided in this book as part of the installation process. Each sample is identified throughout the course of the book as and when it is needed.
We suggest that you set up a partitioned data set into which the samples can be copied and then, modify them as suggested or to meet your installation standards. For this book, the data set PKI.QUICK.SETUP is allocated. This data set is referred to as the SETUP data set throughout this paper.
The samples are copied under the same member name and modified where necessary to suit the controlled environment.
|
Note: Ensure that you read all the comments in the SAMPLIB members and complete the appropriate tasks.
|
2.1.1 Defining VSAM data sets
The VSAM data sets include the PKISRVD prefix. The data sets that include the object store (OST) qualifier are related to object store, which is used to store certificate requests. The data sets that include the issued certificate list (ICL) qualifier are related to the issued certificates list, which is used to store issued certificates.
VSAM data set configuration for ROOTCA
The root CA VSAM data sets are shown in Figure 2-1.
Figure 2-1 Rootca VSAM data sets
Defining the ROOTCA VSAM data sets
Copy member SYS1.SAMPLIB(IKYCVSAM) into your set up data set. Change the volume and the data set names. In our system, we change ‘vvvvvv’ to BH6ST5, and qualify the VSAM data set names with ROOTCA, as shown in Figure 2-1 on page 6.
The job features several steps that include the following commands:
•DELCLUST: Deletes clusters, paths, and alternative indexes, as shown in Figure 2-2.
|
DELETE -
PKISRVD.ROOTCA.VSAM.OST -
CLUSTER -
PURGE -
ERASE
IDC3012I ENTRY PKISRVD.ROOTCA.VSAM.OST NOT FOUND
IDC3009I ** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLA3-42
IDC0551I ** ENTRY PKISRVD.ROOTCA.VSAM.OST NOT DELETED
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8
DELETE -
PKISRVD.ROOTCA.VSAM.ICL -
CLUSTER -
PURGE -
ERASE
IDC3012I ENTRY PKISRVD.ROOTCA.VSAM.ICL NOT FOUND
IDC3009I ** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLA3-42
IDC0551I ** ENTRY PKISRVD.ROOTCA.VSAM.ICL NOT DELETED
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8
IF MAXCC LT 9 THEN SET MAXCC = 0
|
Figure 2-2 Step DELCLUST output
•DEFKSDS: Defines two VSAM clusters, as shown in Figure 2-3.
|
IDCAMS SYSTEM SERVICES
DEFINE CLUSTER -
(NAME(PKISRVD.ROOTCA.VSAM.OST) -
VOL(BH6ST5) -
RECSZ(1024 32756) -
INDEXED -
NOREUSE -
KEYS(4 0) -
SHR(2) -
CYL(3,1) -
LOG(NONE) -
OWNER(PKISRVD) ) -
DATA -
(NAME(PKISRVD.ROOTCA.VSAM.OST.DA) -
CISZ(4096) -
SPANNED) -
INDEX -
(NAME(PKISRVD.ROOTCA.VSAM.OST.IX))
IDC0508I DATA ALLOCATION STATUS FOR VOLUME BH6ST5 IS 0
IDC0509I INDEX ALLOCATION STATUS FOR VOLUME BH6ST5 IS 0
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
DEFINE CLUSTER -
(NAME(PKISRVD.ROOTCA.VSAM.ICL) -
VOL(BH6ST5) -
RECSZ(1024 32756) -
INDEXED -
NOREUSE -
KEYS(4 0) -
SHR(2) -
CYL(3,1) -
LOG(NONE) -
OWNER(PKISRVD) ) -
DATA -
(NAME(PKISRVD.ROOTCA.VSAM.ICL.DA) -
CISZ(4096) -
SPANNED) -
INDEX -
(NAME(PKISRVD.ROOTCA.VSAM.ICL.IX))
IDC0508I DATA ALLOCATION STATUS FOR VOLUME BH6ST5 IS 0
IDC0509I INDEX ALLOCATION STATUS FOR VOLUME BH6ST5 IS 0
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
IDCAMS SYSTEM SERVICES
IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0
|
Figure 2-3 Step DEFKSDS output
•MKZEROS: Uses IEBGENER to write a record of all binary zeros to a temporary file, as shown in Figure 2-4.
|
DATA SET UTILITY - GENERATE
GENERATE MAXFLDS=4,MAXLITS=80
RECORD FIELD=(20,X'0000000000000000000000000000000000000000',,1),
FIELD=(20,X'0000000000000000000000000000000000000000',,21),
FIELD=(20,X'0000000000000000000000000000000000000000',,41),
FIELD=(20,X'0000000000000000000000000000000000000000',,61)
PROCESSING ENDED AT EOD
|
Figure 2-4 Step MKZEROS output
•REPROKSD: Writes the temporary file into both VSAM dat sets, as shown in Figure 2-5.
|
IDCAMS SYSTEM SERVICES
REPRO INFILE(SYSDATA) -
OUTDATASET(PKISRVD.ROOTCA.VSAM.OST)
IDC0005I NUMBER OF RECORDS PROCESSED WAS 1
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
REPRO INFILE(SYSDATA) -
OUTDATASET(PKISRVD.ROOTCA.VSAM.ICL)
IDC0005I NUMBER OF RECORDS PROCESSED WAS 1
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0
|
Figure 2-5 Step REPROKSD output
|
IDCAMS SYSTEM SERVICES
DEFINE ALTERNATEINDEX -
(NAME(PKISRVD.ROOTCA.VSAM.OST.AIX) -
RELATE(PKISRVD.ROOTCA.VSAM.OST)-
VOL(BH6ST5) -
TRK(5,1) -
KEYS(24 44) ) -
DATA -
(NAME(PKISRVD.ROOTCA.VSAM.OST.AIX.DA)) -
INDEX -
(NAME(PKISRVD.ROOTCA.VSAM.OST.AIX.IX))
IDC0508I DATA ALLOCATION STATUS FOR VOLUME BH6ST5 IS 0
IDC0509I INDEX ALLOCATION STATUS FOR VOLUME BH6ST5 IS 0
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
DEFINE PATH -
(NAME(PKISRVD.ROOTCA.VSAM.OST.PATH) -
PATHENTRY(PKISRVD.ROOTCA.VSAM.OST.AIX))
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
DEFINE ALTERNATEINDEX -
(NAME(PKISRVD.ROOTCA.VSAM.OST.STATAIX) -
RELATE(PKISRVD.ROOTCA.VSAM.OST)-
VOL(BH6ST5) -
TRK(5,1) -
KEYS(40 4) ) -
DATA -
(NAME(PKISRVD.ROOTCA.VSAM.OST.STATAIX.DA)) -
INDEX -
(NAME(PKISRVD.ROOTCA.VSAM.OST.STATAIX.IX))
IDC0508I DATA ALLOCATION STATUS FOR VOLUME BH6ST5 IS 0
IDC0509I INDEX ALLOCATION STATUS FOR VOLUME BH6ST5 IS 0
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
DEFINE PATH -
(NAME(PKISRVD.ROOTCA.VSAM.OST.STATUS) -
PATHENTRY(PKISRVD.ROOTCA.VSAM.OST.STATAIX))
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
|
Figure 2-6 Step DEFALTDX output
|
DEFINE ALTERNATEINDEX -
(NAME(PKISRVD.ROOTCA.VSAM.ICL.STATAIX) -
RELATE(PKISRVD.ROOTCA.VSAM.ICL)-
VOL(BH6ST5) -
TRK(5,1) -
KEYS(40 4) ) -
DATA -
(NAME(PKISRVD.ROOTCA.VSAM.ICL.STATAIX.DA)) -
INDEX -
(NAME(PKISRVD.ROOTCA.VSAM.ICL.STATAIX.IX))
IDC0508I DATA ALLOCATION STATUS FOR VOLUME BH6ST5 IS 0
IDC0509I INDEX ALLOCATION STATUS FOR VOLUME BH6ST5 IS 0
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
DEFINE PATH -
(NAME(PKISRVD.ROOTCA.VSAM.ICL.STATUS) -
PATHENTRY(PKISRVD.ROOTCA.VSAM.ICL.STATAIX))
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
DEFINE ALTERNATEINDEX -
(NAME(PKISRVD.ROOTCA.VSAM.OST.REQAIX) -
RELATE(PKISRVD.ROOTCA.VSAM.OST)-
VOL(BH6ST5) -
TRK(5,1) -
KEYS(32 12) ) -
DATA -
(NAME(PKISRVD.ROOTCA.VSAM.OST.REQAIX.DA)) -
INDEX -
(NAME(PKISRVD.ROOTCA.VSAM.OST.REQAIX.IX))
IDC0508I DATA ALLOCATION STATUS FOR VOLUME BH6ST5 IS 0
IDC0509I INDEX ALLOCATION STATUS FOR VOLUME BH6ST5 IS 0
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
DEFINE PATH -
(NAME(PKISRVD.ROOTCA.VSAM.OST.REQUESTR) -
PATHENTRY(PKISRVD.ROOTCA.VSAM.OST.REQAIX))
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
DEFINE ALTERNATEINDEX -
IDCAMS SYSTEM SERVICES
(NAME(PKISRVD.ROOTCA.VSAM.ICL.REQAIX) -
RELATE(PKISRVD.ROOTCA.VSAM.ICL)-
VOL(BH6ST5) -
TRK(5,1) -
KEYS(32 12) ) -
DATA -
(NAME(PKISRVD.ROOTCA.VSAM.ICL.REQAIX.DA)) -
INDEX -
(NAME(PKISRVD.ROOTCA.VSAM.ICL.REQAIX.IX))
IDC0508I DATA ALLOCATION STATUS FOR VOLUME BH6ST5 IS 0
IDC0509I INDEX ALLOCATION STATUS FOR VOLUME BH6ST5 IS 0
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
DEFINE PATH -
(NAME(PKISRVD.ROOTCA.VSAM.ICL.REQUESTR) -
PATHENTRY(PKISRVD.ROOTCA.VSAM.ICL.REQAIX))
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
|
Figure 2-7 Step DEFALTDX output (continued)
•BLDINDEX: Builds the alternative indexes, as shown in Figure 2-8.
|
BLDINDEX INDATASET(PKISRVD.ROOTCA.VSAM.OST) -
OUTDATASET(PKISRVD.ROOTCA.VSAM.OST.AIX)
IDC0652I PKISRVD.ROOTCA.VSAM.OST.AIX SUCCESSFULLY BUILT
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
BLDINDEX INDATASET(PKISRVD.ROOTCA.VSAM.OST) -
OUTDATASET(PKISRVD.ROOTCA.VSAM.OST.STATAIX)
IDC0652I PKISRVD.ROOTCA.VSAM.OST.STATAIX SUCCESSFULLY BUILT
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
BLDINDEX INDATASET(PKISRVD.ROOTCA.VSAM.ICL) -
OUTDATASET(PKISRVD.ROOTCA.VSAM.ICL.STATAIX)
IDC0652I PKISRVD.ROOTCA.VSAM.ICL.STATAIX SUCCESSFULLY BUILT
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
BLDINDEX INDATASET(PKISRVD.ROOTCA.VSAM.OST) -
OUTDATASET(PKISRVD.ROOTCA.VSAM.OST.REQAIX)
IDC0652I PKISRVD.ROOTCA.VSAM.OST.REQAIX SUCCESSFULLY BUILT
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
BLDINDEX INDATASET(PKISRVD.ROOTCA.VSAM.ICL) -
OUTDATASET(PKISRVD.ROOTCA.VSAM.ICL.REQAIX)
IDC0652I PKISRVD.ROOTCA.VSAM.ICL.REQAIX SUCCESSFULLY BUILT
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
|
Figure 2-8 Step BLDINDEX output
•PRTCLUST: Prints the VSAM data set record, as shown in Figure 2-9.
|
PRINT -
INDATASET(PKISRVD.ROOTCA.VSAM.OST) CHAR
IDCAMS SYSTEM SERVICES
LISTING OF DATA SET -PKISRVD.ROOTCA.VSAM.OST
KEY OF RECORD - ....
..................................................................
IDC0005I NUMBER OF RECORDS PROCESSED WAS 1
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
IDCAMS SYSTEM SERVICES
PRINT -
INDATASET(PKISRVD.ROOTCA.VSAM.ICL) CHAR
IDCAMS SYSTEM SERVICES
LISTING OF DATA SET -PKISRVD.ROOTCA.VSAM.ICL
KEY OF RECORD - ....
..................................................................
IDC0005I NUMBER OF RECORDS PROCESSED WAS 1
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
IDCAMS SYSTEM SERVICES
IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0
|
Figure 2-9 Step PRTCLUST output
The captions in the step list show the SYSPRINT output from IKYCVSAM job. The VSAM object store and ICL set up is completed for ROOTCA.
2.1.2 Installing the HTTP Server - Powered by Apache
|
Note: For more information, see the “Installing and configuring IBM HTTP Server on the z/OS V2R2 system” section of Chapter 2 in IBM HTTP Server - Powered by Apache SC27-8417.
|
Installation process
Complete the following steps to set up the HTTP server in the environment:
1. Change the directory to /etc.
2. Create a directory that is named websrv1.
3. Change the permissions for the websrv1 directory.
4. Change the directory to /usr/lpp/ihsa_zos/bin.
5. Install the HTTP server into wersrv1 directory by using port 80.
6. It is possible that you created websrv1 with your ID, which makes you the owner. Change the owner of webrsrv1 conf and logs directories and their contents to websrv. The websrv user was set up as a user on our system.
|
Note: The websrv user ID should exist. Define this user if it was not yet created. Ensure that the home directory of websrv points to /etc/websrv1, as shown in Example 2-1.
|
Example 2-1 Display home directory of user websrv
tso lu websrv noracf omvs
USER=WEBSRV
OMVS INFORMATION
----------------
UID= 0000000345
HOME= /etc/websrv1
PROGRAM= /bin/sh
CPUTIMEMAX= NONE
ASSIZEMAX= NONE
FILEPROCMAX= NONE
PROCUSERMAX= NONE
THREADSMAX= NONE
MMAPAREAMAX= NONE
***
The commands that are used in the installation process are shown in Figure 2-10.
|
cd /etc
mkdir websrv1
chmod 770 websrv1
cd /usr/lpp/ihsa_zos/bin
install_ihs /etc/websrv1 80
KWRES01:/usr/lpp/ihsa_zos/bin: >install_ihs /etc/websrv1 80
Copying install directory and creating symlinks...
Updating install paths...
cmd: /usr/lpp/ihsa_zos/bin/postinst -i /etc/websrv1 -t install -v PORT=80 -v SERVERNAME=WTSC76.ITSO.IBM.COM
cd /etc/websrv1
chown -R websrv conf
chown -R websrv logs
|
Figure 2-10 Commands to install the HTTP server into websrv1 directory
Verification
Run the verification commands that are shown in Figure 2-11 to confirm that the installation was successful.
|
KWRES01:/SYSTEM/etc/websrv1/bin: >apachectl -v
Server version: IBM_HTTP_Server/9.0.0.0-PI54808 (Unix)
Server built: Jan 20 2016 17:19:40
KWRES01:/SYSTEM/etc/websrv1/bin: >apachectl configtest
Syntax OK
|
Figure 2-11 Verifying the installation
The base installation into websrv1 is now complete.
2.1.3 Using the set up script to create certificates and key rings
In this section, we describe using the set up script to create certificates and key rings for the PKI instance and web server and set up authorization in RACF.
The IKYSETUP REXX procedure creates the certificate, private key, and keyring that are needed for the ROOTCA certificate authority.
IKYSETUP functions
The IKYSETUP REXX performs the following steps:
1. Creates users and groups.
2. Allows administrators to access PKI VSAM databases.
3. Creates the CA certificate.
4. Backs up the CA certificate.
5. Marks the CA certificate as HIGHTRUST.
6. Saves the CA certificate to a data set.
7. Creates the RA certificate.
8. Backs up RA certificate.
9. Creates the PKI Services keyring.
10. Creates the Web server SSL certificate and keyring.
11. Saves the web server’s root CA certificate to a data set for OPUT.
12. Gives PKISRVD access to BPX.SERVER.
13. Allows the PKI Services daemon to act as a CA.
14. Allows the Web server to access its keyring.
15. Allows the Web server to switch identity to PKISERV.
16. Allows the PKI Services daemon to use ICSF.
17. Creates the STARTED class profile for the daemon.
18. Allows PKISERV to request certificate functions.
19. Creates the profile to protect PKI Admin functions.
Copy the SYS1.SAMPLIB(IKYSETUP) member into the SETUP data set. Modify the REXX procedure to reflect our environment.
Set up the Distinguished Name (DN) of our certificate authority that is defined in Figure 2-12 on page 16. The suffix of this DN must match the suffix that is set up for the LDAP directory (suffix value from the ds.profile file set up in step 2 of “Setting up the LDAP server” on page 31).
The first area to change in the IKYSETUP REXX relates to the CA content. Figure 2-12 shows the REXX procedures before and after the changes. Our changes are marked in bold.
|
Before the changes
ca_domain = "" /* @L4A*/
if LENGTH(ca_domain) > 8 then /* @L4A*/
ca_domain_trunc = LEFT(ca_domain,8) /* @L4A*/
else /* @L4A*/
ca_domain_trunc = ca_domain /* @L4A*/
OrgUnit = STRIP(ca_domain "Human Resources Certificate Authority")
/* @L4A*/
ca_dn= "OU('"||OrgUnit||"')",
"O('Your Company')",
"C('Your Country 2 Letter Abbreviation')" /* @L4C*/
ca_label = STRIP(ca_domain "Local PKI CA") /* Label for CA
certificate with the
CA Domain name
After the changes
ca_domain = "ROOTCA" /* @L4A*/
if LENGTH(ca_domain) > 8 then /* @L4A*/
ca_domain_trunc = LEFT(ca_domain,8) /* @L4A*/
else /* @L4A*/
ca_domain_trunc = ca_domain /* @L4A*/
OrgUnit = STRIP(ca_domain "IBM PKI RedBooks")
/* @L4A*/
ca_dn= "OU('"||OrgUnit||"')",
"O('IBM')",
"C('US')" /* @L4C*/
ca_label = STRIP(ca_domain "ROOTCA PKI CA") /* Label for CA
certificate with the
CA Domain name
|
Figure 2-12 CA content changes to IKYSETUP
The next change refers to the Registration Authority (RA). Figure 2-13 shows the before and after values.
|
Before the changes
ra_label = STRIP(ca_domain "Local PKI RA") /*Label for
RA Certificate @01C*/
After the changes
ra_label = STRIP(ca_domain “PKI RA") /*Label for
RA Certificate @01C*/
|
Figure 2-13 RA changes
The Web server DN was also changed. The before and after values are shown in Figure 2-14.
|
Before the changes
web_dn=,
"CN('www.YourCompany.com')",
"O('Your Company')",
"L('Your City')",
"SP('Your Full State or Province Name')",
"C('Your Country 2 Letter Abbreviation')"
After the changes
web_dn=,
"CN('wtsc76.itso.ibm.com')",
"O('IBM')",
"L('Poughkeepsie')",
"SP('New York')",
"C('US')"
|
Figure 2-14 Web dn changes
The sample web server protection directives that are supplied by PKI use SSLring for the web server’s SAF key ring. The value that is shown in Figure 2-15 is not changed. If the value is changed, the KeyFile directive in the samples/vhost443.conf and samples/vhost1443.conf files must be modified when the web server is configured.
|
web_ring = "SSLring" /* SAF keyring for web server */
|
Figure 2-15 SSLring for web server’s SAF keyring
Running the IKYSETUP REXX procedure
Before the IKYSETUP REXX procedure is run, the REXX procedure is reviewed to confirm that it performed as expected by using the RUN(NO) option. By using this option, we can see which commands and values are generated without running the commands. Enter the following command:
EX 'PKI.QUICK.SETUP(IKYSETUP)' 'RUN(NO)'
The IKYSETUP REXX writes to a log data set KWRES01.ROOTCA.IKYSETUP.LOG. Examine the contents to ensure that the generated commands are satisfactory. Enter the following command to run the REXX procedure:
EX 'PKI.QUICK.SETUP(IKYSETUP)' 'RUN(YES)'
During execution (with the NO or YES value set), IKYSETUP displays the prompt that is shown in Figure 2-16. A memorable passphrase is required, which is needed if the key must be restored. Enter the passphrase, press Enter, and the processing continues.
|
Creating the CA certificate ...
RACDCERT GENCERT CERTAUTH SUBJECTSDN(OU('ROOTCA IBM PKI RedBooks') O('IBM') C('US')) WITHLABEL('ROOTCA PKI CA') NOTAFTER(DATE(2036/08/15)) SIZE(2048)
Enter a passphrase to protect the key. You will need
this value later if you need to restore the key.
Attention, the value will be displayed in the screen:
|
Figure 2-16 IKYSETUP REXX passphrase prompt
The KWRES01.ROOTCA.IKYSETUP.LOG data set shows all of the generated RACF commands and their results. Near the end of the data set, a section is included that provides information that is needed for the PKI Services UNIX set up, as shown in Figure 2-17 on page 19. This information is used to customize the PKI Services UNIX files. The line that is indicated in bold requires an action.
|
-------------------------------------------------
Information needed for PKI Services UNIX set up:
-------------------------------------------------
The daemon user ID is:
PKISRVD
The VSAM high-level qualifier is:
PKISRVD
This is needed for the [ObjectStore] section in pkiserv.conf
The PKI Services' DER encoded certificate is in data set:
'PKISRVD.ROOTCA.CACERT.DERBIN'
The webserver's DER encoded root
CA certificate is in data set:
'PKISRVD.ROOTCA.WEBROOT.DERBIN'
This must be OPUT to /var/pkiserv/cacert.der with the BINARY option
The fully qualified PKI Services' SAF keyring is:
PKISRVD/CAring.ROOTCA
This is needed for the [SAF] section in pkiserv.conf
The label of the PKI Services' RA certificate is:
ROOTCA PKI RA
This is needed for the [SAF] section in pkiserv.conf
The PKI Services CA DN is:
OU=ROOTCA IBM PKI RedBooks,O=IBM,C=US
The suffix must match the LDAP suffix in slapd.conf
The PKI Services RA DN is:
CN=Registration Authority,OU=ROOTCA IBM PKI RedBooks,O=IBM,C=US
The suffix must match the LDAP suffix in slapd.conf
The recommended location for the pkiserv.conf and pkiserv.tmpl is:
/etc/pkiserv/ROOTCA
Set the following environment variables in pkiserv.envars:
_PKISERV_CA_DOMAIN=ROOTCA
_PKISERV_CONFIG_PATH=/etc/pkiserv/ROOTCA
Set the following environment variable in your virtual host files:
_PKISERV_CONFIG_PATH_ROOTCA =/etc/pkiserv/ROOTCA
The webserver's SAF keyring is:
SSLring
This is needed for the KeyFile directive in virtual host files
The Webserver's DN is:
CN=wtsc76.itso.ibm.com,O=IBM,L=Poughkeepsie,ST=New York,C=US
The left most RDN must be the webserver's fully qualified domain name
|
Figure 2-17 UNIX configuration information
The ROOTCA certificate is saved in the PKISRVD.ROOTCA.WEBROOT.DERBIN data set. The certificate is copied into the UNIX file directory /var/pkiserv for the web page user to download the CA certificate.
OPUT or the following command can be used:
cp “//’PKISRVD.ROOTCA.WEBROOT.DERBIN' " /var/pkiserv/cacert.der
|
Note: The /var/pkiserv directory is specified in the HTTP server configuration.
|
Configuring the PKI Services UNIX aspects
The sample files are under the sample directory where PKI Services is installed. In our system, the directory is /usr/lpp/pkiserv/samples. Each file’s role is listed in Table 2-1.
Table 2-1 UNIX PKI Services sample files
|
Data set
|
Description
|
|
pkiserv.conf
|
The configuration file that contains various settings and values.
|
|
pkiserv.envars
|
The environmental variables file.
|
|
pkiserv.tmpl
|
The certificate templates file that is used with REXX CGI executable files. It
contains HTML-style code that builds the web pages that are underlying certificate requests.
|
|
expiringmsg.form
|
The form for an email that is sent to a user when a certificate is going to expire.
|
|
pendingmsg.form
|
The form for an email that is sent to an administrator when requests are pending approval.
|
|
pendingmsg2.form
|
The form is your company sends an email notification to an administrator about requests that are approved with modifications.
|
|
readymsg.form
|
The form for an email that is sent to a user when the PKI Services administrator approves a certificate request and the certificate is ready for retrieval.
|
|
rejectmsg.form
|
The form for an email that is sent to a user when the PKI Services
administrator rejects a certificate request.
|
|
renewcertmsg.form
|
The form for an email that is sent to a user when PKI Services automatically renews an expiring certificate.
|
|
recoverymsg.form
|
The form for an email that is sent to a user who requested that PKI Services recover a certificate for which PKI Services generated the key pair.
|
The form data sets must be configured only if you intend to use them.
2.1.4 Configuring the PKI Services UNIX files
This section describes copying and customizing the supplied UNIX PKI Services files into a directory for our rootca.
Copying the sample files
Create a UNIX rootca directory by issuing the following command:
mkdir /etc/pkiserv/rootca
Copy the supplied PKI Services data sets by issuing the following commands:
•cp -p /usr/lpp/pkiserv/samples/pkiserv.conf /etc/pkiserv/rootca
•cp -p /usr/lpp/pkiserv/samples/pkiserv.tmpl /etc/pkiserv/rootca
•cp -p /usr/lpp/pkiserv/samples/pkiserv.envars /etc/pkiserv/rootca
•cp -p /usr/lpp/pkiserv/samples/*.form /etc/pkiserv/rootca
Customizing pkiserv.conf
Change the directory to the rootca and open the data set for edit by issuing the following command:
cd /etc/pkiserv/rootca
edit pkiserv.conf
Customize the VSAM data set names to those names that were defined with job IKYCVSAM by issuing the following command:
C VSAM ROOTCA.VSAM all
The update is shown in Figure 2-18.
|
# Data set name of the VSAM request (object store) base CLUSTER
#
ObjectDSN='pkisrvd.ROOTCA.VSAM.ost'
# Data set name of the VSAM object store PATH for the transaction ID
# (TID) alternate index.
#
ObjectTidDSN='pkisrvd.ROOTCA.VSAM.ost.path'
# Data set name of the VSAM object store PATH for the status alternate
# index
#
ObjectStatusDSN='pkisrvd.ROOTCA.VSAM.ost.status'
# Data set name of the VSAM object store PATH for the requestor
# alternate index
#
ObjectRequestorDSN='pkisrvd.ROOTCA.VSAM.ost.requestr'
# Data set name of the VSAM issued certificate list (ICL) base CLUSTER
#
ICLDSN='pkisrvd.ROOTCA.VSAM.icl'
# Data set name of the VSAM ICL PATH for the status alternate index
#
ICLStatusDSN='pkisrvd.ROOTCA.VSAM.icl.status'
# Data set name of the VSAM ICL PATH for the requestor alternate index
#
ICLRequestorDSN='pkisrvd.ROOTCA.VSAM.icl.requestr'
|
Figure 2-18 Updated pkiserv.conf VSAM specification
Change the location of where the messages (the .form data sets that were copied) are to be found by issuing the following command:
C /etc/pkiserv/ /etc/pkiserv/rootca all
The results are shown in Figure 2-19.
|
# full pathname or data set name containing the 'your certificate is
# ready to be retrieved' message form. Defaults to no message issued
ReadyMessageForm=/etc/pkiserv/rootca/readymsg.form
# full pathname or data set name containing the 'your certificate
# request has been rejected' message form. Defaults to no message issued
RejectMessageForm=/etc/pkiserv/rootca/rejectmsg.form
# full pathname or data set name containing the 'your certificate is
# about to expire' message form. Defaults to no message issued
ExpiringMessageForm=/etc/pkiserv/rootca/expiringmsg.form
# full pathname or data set name containing the request(s) pending for
# approval message form. Defaults to no notification sent.
AdminNotifyForm=/etc/pkiserv/rootca/pendingmsg.form
# full pathname or data set name containing the request(s) approved
# with modifications message form. Defaults to no notification sent.
AdminNotifyModForm=/etc/pkiserv/rootca/pendingmsg2.form
# full pathname or data set name containing the renewed certificate
# message form for automatic certificate renewal.
# If absent, automatic certificate renewal is disabled.
RenewCertForm=/etc/pkiserv/rootca/renewcertmsg.form
# full pathname or data set name containing information on
# the list of certificates that match the criteria specified
# to recover key generated certificates.
# If absent, recovery query results will not be sent.
RecoverForm=/etc/pkiserv/rootca/recoverymsg.form
|
Figure 2-19 Changed message locations
The CA Keyring, CA Token, and RA label were changed by issuing the following commands:
c CAring CAring.ROOTCA
c pkisrvd.PKIToken pkisrvd.rootca.PKIToken
c 'Local PKI RA' 'ROOTCA PKI RA'
The updates are shown in Figure 2-20 on page 23.
|
KeyRing=PKISRVD/CAring.ROOTCA
#TokenName=PKISRVD.rootca.PKIToken
# The Label name for the PKI RA certificate connected to the Key ring
# specified in the KeyRing value above
#
RALabel=ROOTCA PKI RA
|
Figure 2-20 Updated keyring, token, and RA label
Specify the LDAP server and the admin ID and password that must match the LDAP set up. The values are shown in Figure 2-21.
|
NumServers=1
PostInterval=5m
Server1=wtsc76.itso.ibm.com:390
AuthName1=CN=admin
AuthPwd1=secret
|
Figure 2-21 LPDA server details
|
Note: For the product system, you might not want to make the password available in the configuration file. You can make use of the LDAPBIND class profile. For more information, see the “Storing information for encrypted passwords for your LDAP servers” section of z/OS PKI Services Guide and Reference.
|
Save the /etc/pkiserv/rootca/pkiserv.conf updates and close the file.
Customizing pkiserv.envars
The next file that is updated is the environmental variables file. Ensure that you are still in the /etc/pkiserv/rootca: directory. Edit pkiserv.envars with the domain and path variables updates as shown in the following examples:
_PKISERV_CA_DOMAIN=ROOTCA
_PKISERV_CONFIG_PATH=/etc/pkiserv/rootca
The updated variables are shown in Figure 2-22.
|
# When running as a CA Domain, set the CA Domain name by assigning
# desired value to the _PKISERV_CA_DOMAIN variable.
# Note: The first eight characters must be unique.
#
# example: _PKISERV_CA_DOMAIN=WebAppCA
_PKISERV_CA_DOMAIN=ROOTCA
#
# Configuration File location and Message configuration Options
#
_PKISERV_CONFIG_PATH=/etc/pkiserv/rootca
|
Figure 2-22 Domain and Path information
Save the updates and close the file.
Customizing pkiserv.tmpl
Edit the sample pkiserv.tmpl file and make the following changes:
•<APPLICATION NAME=PKISERV>
is changed to
<APPLICATION NAME=ADMROOTCA>
•<FORM name=admform METHOD=GET ACTION="/PKIServ/ssl-cgi/auth/admmain.rexx ">
is changed to
<FORM name=admform METHOD=GET ACTION="/Rootca/ssl-cgi/auth/admmain.rexx ">
•<APPLICATION NAME=CUSTOMERS>
is changed to
<APPLICATION NAME=ROOTCA>
Then, change all occurrences of “Customers” to “Rootca”.
Review the pkiserv.tmpl file to learn more about the web application.
Customizing notification forms
All of the form files must be updated next to customize the messages. Use the following list command to identify the form files to be changed.
ls *.form
The response to the command is shown in Figure 2-23.
|
KWRES01:/SYSTEM/etc/pkiserv/rootca: >ls *.form
expiringmsg.form pendingmsg2.form recoverymsg.form renewcertmsg.form
pendingmsg.form readymsg.form rejectmsg.form
|
Figure 2-23 List of .form files
Edit all the *.form files to customize the domain information. Figure 2-24 on page 25 shows the updated expiringmsg.form with the updated values. The other forms should be similar. Use the following commands to customize the domain information:
c dime-o-cert 'IBM RB ROOTCA' all
c www.dimeocert.com wtsc76.itso.ibm.com all
c Customers Rootca
|
From:IBM RB ROOTCA PKI
Subject:Certificate Expiration
Attention - Please do not reply to this message as it was automatically sent by a service machine.
Dear %%requestor%%,
Thank you for choosing IBM RB ROOTCA PKI. The certificate you requested for
subject %%dn%% expires at %%notafter%% local time. If you want to renew
your certificate, please visit:
http://www.dimeocert.com wtsc76.itso.ibm.com/Rootca/public-cgi/camain.rexx
If this is a browser certificate, you must use the same workstation and browser that you used when you requested the original certificate. If this is a server
certificate, you will have to submit a PKCS#10 certificate request.
|
Figure 2-24 Updated expiration message
The web pages and web application are now updated to identify it as the ROOTCA application.
2.1.5 Customizing PKISERVD started task
The started task JCL was updated to reflect the rootca environment by completing the following tasks:
1. Copy the start procedure from SYS1.IBM.PROCLIB(PKISERVD) to SYS1.PROCLIB(PKISERVD).
2. Edit DIR='/etc/pkiserv/rootca'.
The updated procedure is shown in Figure 2-25.
|
//*********************************************************************
//* *
//* Licensed Materials - Property of IBM *
//* 5650-ZOS *
//* Copyright IBM Corp. 2001, 2013 *
//* Status=HKY7790 *
//* *
//*********************************************************************
//*********************************************************************
//* *
//* Procedure for starting the PKI Services Daemon *
//* *
//*********************************************************************
//PKISERVD PROC REGSIZE=256M, X
// OUTCLASS='A', X
// TZ='EST5EDT', X
// FN='pkiserv.envars', X
// DIR='/etc/pkiserv/rootca', X
// STDO='1>DD:STDOUT', X
// STDE='2>DD:STDERR'
//*--------------------------------------------------------------------
//GO EXEC PGM=IKYPKID,REGION=®SIZE,TIME=1440,
// PARM=('ENVAR("_CEE_ENVFILE=&DIR/&FN","TZ=&TZ") / &STDO &STDE')
//STDOUT DD SYSOUT=&OUTCLASS
//STDERR DD SYSOUT=&OUTCLASS
//SYSOUT DD SYSOUT=&OUTCLASS
//CEEDUMP DD SYSOUT=&OUTCLASS
|
Figure 2-25 PKI Services Daemon started task JCL
2.1.6 Configuring the HTTP server for PKI services
This section describes how the HTTP Server - powered by Apache was configured for PKI services.
|
Note: For more information, see Chapter 7 of Cryptographic Services PKI Services Guide and Reference SA23-2286.
|
In section “Installing the HTTP Server - Powered by Apache” on page 13, the process that is used to install the http server is described. The following configuration files are updated to include the PKI Services. PKI Services provides sample virtual host files for non-SSL requests, SSL requests, and SSL requests with client authentication on different ports:
•httpd.conf: This file is the main HTTP server configuration file.
•Virtual host files:
– vhost80.conf: This file is virtual host file for non-SLL requests.
– vhost443.conf: This file is the virtual host file for SSL requests with server authenticating.
– vhost143.conf: This file is the virtual host file for SSL requests with client authentication.
These files are used by the IP-based virtual hosting feature of the IBM HTTP Server. IP-based virtual hosting is a method to apply different directives that are based on the IP address and port on which a request is received.
Customizing httpd.conf, vhost80.conf, vhost443.conf, and vhost1443.conf files
The installation process put the httpd.conf file in /etc/websrv1/conf. The following commands were issued:
cd /etc/websrv1/conf
oedit httpd.conf
Updating httpd.conf
Complete the following steps:
1. Find and uncomment the four load modules as shown in Figure 2-26. Although shown together, they are in separate parts of the configuration file.
|
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule authnz_saf_module modules/mod_authnz_saf.so
LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
|
Figure 2-26 Four load modules to uncomment
2. Add the Addtype directives for PKI Services, as shown in Figure 2-27.
|
#
# AddType allows you to add to or override the MIME configuration
# file mime.types for specific file types.
#
#The following four types are for PKI Services
AddType application/x-x509-user-cert .cer
AddType application/x-x509-ca-cert .der
AddType application/octet-stream .msi
AddType application/pkix-crl .crl
|
Figure 2-27 Addtype directives for PKI Services
3. Add include statements to point to the virtual host files, as shown in Figure 2-28.
|
Include conf/vhost80.conf
Include conf/vhost443.conf
Include conf/vhost1443.conf
|
Figure 2-28 include the virtual host files
Updating vhost files
Copy the vhost files into the /etc/websrv1/conf directory by issuing the following command:
cp /usr/lpp/pkiserv/samples/vhost*.conf /etc/websrv1/conf
Add the following statements for each file as described in the figures’ caption:
•Change the <application-root> to the system installation directory. The directory is /usr/lpp/pkiserv in our system.
•SetEnv statements that are shown in Figure 2-29
|
Note: If you are not using the default ports 80 and 443, you must include the port number in the URL.
|
•AliasMatch statements that are shown in Figure 2-33 on page 29
|
Note: If your AliasMatch does not point to /var/pkiserv, you must add a corresponding DirectoryMatch section as with the section for /var/pkiserv.
|
•ScriptAlias statements that are shown in Figure 2-34 on page 30
•LocationMatch statements that are shown in Figure 2-35 on page 30
|
Note: We are setting up for all the 3 PKI instances, including ROOOTCA, SUBCA1, and SUBCA2 (not the ROOTCA only).
|
|
SetEnv _PKISERV_CONFIG_PATH_ROOTCA "/etc/pkiserv/rootca"
SetEnv _PKISERV_CONFIG_PATH_ADMROOTCA "/etc/pkiserv/rootca"
SetEnv _PKISERV_CONFIG_PATH_SUBCA1 "/etc/pkiserv/subca1"
SetEnv _PKISERV_CONFIG_PATH_ADMSUBCA1 "/etc/pkiserv/subca1"
SetEnv _PKISERV_CONFIG_PATH_SUBCA2 "/etc/pkiserv/subca2"
SetEnv _PKISERV_CONFIG_PATH_ADMSUBCA2 "/etc/pkiserv/subca2"
|
Figure 2-29 SETENV statements for vhost80, vhost443, vhost1443
|
RewriteRule ^/(AdmRootca|Rootca)/ssl-cgi/(.*) https://wtsc76.itso.ibm.com/$1/ssl-cgi-bin/$2 [R,NE]
RewriteRule ^/(AdmSubca1|Subca1)/ssl-cgi/(.*) https://wtsc76.itso.ibm.com/$1/ssl-cgi-bin/$2 [R,NE]
RewriteRule ^/(AdmSubca2|Subca2)/ssl-cgi/(.*) https://wtsc76.itso.ibm.com/$1/ssl-cgi-bin/$2 [R,NE]
RewriteRule ^/(AdmRootca|Rootca)/clientauth-cgi/(.*) https://wtsc76.itso.ibm.com:1443/$1/clientauth-cgi-bin/$2 [R,NE]
RewriteRule ^/(AdmSubca1|Subca1)/clientauth-cgi/(.*) https://wtsc76.itso.ibm.com:1443/$1/clientauth-cgi-bin/$2 [R,NE]
RewriteRule ^/(AdmSubca1|Subca2)/clientauth-cgi/(.*)
https://wtsc76.itso.ibm.com:1443/$1/clientauth-cgi-bin/$2 [R,NE]
|
Figure 2-30 RewriteRule statements for vhost80
|
RewriteRule ^/(AdmRootca|Rootca)/public-cgi/(.*) http://wtsc76.itso.ibm.com/$1/public-cgi/$2 [R,NE,L]
RewriteRule ^/(AdmSubca1|Subca1)/public-cgi/(.*) http://wtsc76.itso.ibm.com/$1/public-cgi/$2 [R,NE,L]
RewriteRule ^/(AdmSubca2|Subca2)/public-cgi/(.*) http://wtsc76.itso.ibm.com/$1/public-cgi/$2 [R,NE,L]
RewriteRule ^/(AdmRootca|Rootca)/ssl-cgi/(.*)
https://wtsc76.itso.ibm.com/$1/ssl-cgi-bin/$2 [R,NE]
RewriteRule ^/(AdmSubca1|Subca1)/ssl-cgi/(.*)
https://wtsc76.itso.ibm.com/$1/ssl-cgi-bin/$2 [R,NE]
RewriteRule ^/(AdmSubca2|Subca2)/ssl-cgi/(.*)
https://wtsc76.itso.ibm.com/$1/ssl-cgi-bin/$2 [R,NE]
RewriteRule ^/(AdmRootca|Rootca)/clientauth-cgi/(.*)
https://wtsc76.itso.ibm.com:1443/$1/clientauth-cgi-bin/$2 [R,NE,L]
RewriteRule ^/(AdmSubca1|Subca1)/clientauth-cgi/(.*)
https://wtsc76.itso.ibm.com:1443/$1/clientauth-cgi-bin/$2 [R,NE,L]
RewriteRule ^/(AdmSubca1|Subca2)/clientauth-cgi/(.*)
https://wtsc76.itso.ibm.com:1443/$1/clientauth-cgi-bin/$2 [R,NE,L]
|
Figure 2-31 RewriteRule statements for vhost443
|
RewriteRule ^/(AdmRootca|Rootca)/public-cgi/(.*)
http://wtsc76.itso.ibm.com/$1/public-cgi/$2 [R,NE,L]
RewriteRule ^/(AdmSubca1|Subca1)/public-cgi/(.*)
http://wtsc76.itso.ibm.com/$1/public-cgi/$2 [R,NE,L]
RewriteRule ^/(AdmSubca2|Subca2)/public-cgi/(.*)
http://wtsc76.itso.ibm.com/$1/public-cgi/$2 [R,NE,L]
RewriteRule ^/(AdmRootca|Rootca)/ssl-cgi/(.*)
https://wtsc76.itso.ibm.com/$1/ssl-cgi-bin/$2 [R,NE,L]
RewriteRule ^/(AdmSubca1|Subca1)/ssl-cgi/(.*)
https://wtsc76.itso.ibm.com/$1/ssl-cgi-bin/$2 [R,NE,L]
RewriteRule ^/(AdmSubca2|Subca2)/ssl-cgi/(.*)
https://wtsc76.itso.ibm.com/$1/ssl-cgi-bin/$2 [R,NE,L]
|
Figure 2-32 RewriteRule statements for vhost1443
vhost80
The AliasMatch statements are for the CRL, as shown in Figure 2-33.
|
AliasMatch /rootca/crls/(.*) /var/pkiserv/rootca/$1
AliasMatch /subca1/crls/(.*) /var/pkiserv/subca1/$1
AliasMatch /subca2/crls/(.*) /var/pkiserv/subca2/$1
|
Figure 2-33 AliasMatch to be added to vhost80 only
|
vhost80:
ScriptAliasMatch /(AdmRootca|AdmSubca1|AdmSubca2)/public-cgi/(.*) /usr/lpp/pkiserv/PKIServ/public-cgi/$2
ScriptAliasMatch /(Rootca|Subca1|Subca2)/public-cgi/(.*) /usr/lpp/pkiserv/PKIServ/public-cgi/$2
vhost443:
ScriptAliasMatch ^/(AdmRootca|Rootca)/(public-cgi|ssl-cgi-bin)/(.*) "/usr/lpp/pkiserv/PKIServ/$2/$3"
ScriptAliasMatch ^/(AdmSubca1|Subca1)/(public-cgi|ssl-cgi-bin)/(.*) "/usr/lpp/pkiserv/PKIServ/$2/$3"
ScriptAliasMatch ^/(AdmSubca2|Subca2)/(public-cgi|ssl-cgi-bin)/(.*) "/usr/lpp/pkiserv/PKIServ/$2/$3"
vhost1443:
ScriptAliasMatch ^/(AdmRootca|Rootca)/(clientauth-cgi|clientauth-cgi-bin)/(.*) "/usr/lpp/pkiserv/PKIServ/clientauth-cgi-bin/$3"
ScriptAliasMatch ^/(AdmSubca1|Subca1)/(clientauth-cgi|clientauth-cgi-bin)/(.*) "/usr/lpp/pkiserv/PKIServ/clientauth-cgi-bin/$3"
ScriptAliasMatch ^/(AdmSubca2|Subca2)/(clientauth-cgi|clientauth-cgi-bin)/(.*) "/usr/lpp/pkiserv/PKIServ/clientauth-cgi-bin/$3"
|
Figure 2-34 ScriptAliasMatch statements
LocationMatch statements are added for vhost443 and vhost1443 only, as shown in Figure 2-35.
|
vhost443:
<LocationMatch "^/(AdmRootca|Rootca)/ssl-cgi-bin(/(auth|surrogateauth) )?/cagetcert.rexx">
Charsetoptions TranslateAllMimeTypes
</LocationMatch>
<LocationMatch "^/(AdmSubca1|Subca1)/ssl-cgi-bin(/(auth|surrogateauth) )?/cagetcert.rexx">
Charsetoptions TranslateAllMimeTypes
</LocationMatch>
<LocationMatch "^/(AdmSubca2|Subca2)/ssl-cgi-bin(/(auth|surrogateauth) )?/cagetcert.rexx">
Charsetoptions TranslateAllMimeTypes
</LocationMatch>
vhost1443:
<LocationMatch "^/(AdmRootca|Rootca)/clientauth-cgi-bin/auth/pkicmp">
CharsetOptions NoTranslateRequestBodies
</LocationMatch>
<LocationMatch "^/(AdmSubca1|Subca1)/clientauth-cgi-bin/auth/pkicmp">
CharsetOptions NoTranslateRequestBodies
</LocationMatch>
<LocationMatch "^/(AdmSubca2|Subca2)/clientauth-cgi-bin/auth/pkicmp">
CharsetOptions NoTranslateRequestBodies
</LocationMatch>
|
Figure 2-35 LocationMatch statements for vhost443 and vhost1443
Customizing the IHSSRVER started task
Copy the HTTP server started procedure from the sample job in the HTTP samplib. Our procedure is in HAP.SHAPJCL3(HAPCPROC). Copy it to SYS1.PROCLIB(IHSSRVER).
Update the directory set up for web server, as shown in the following example:
DIR='/etc/websrv1',
The started task is shown in Figure 2-36.
|
//*---------------------------------------------------------
//IHSSRVER PROC ACTION='start',
// DIR='/etc/websrv1',
// CONF='conf/httpd.conf'
//*---------------------------------------------------------
//IHS EXEC PGM=BPXBATCH,
// PARM='SH &DIR/bin/apachectl -k &ACTION -f &CONF -DNO_DETACH',
// MEMLIMIT=512M
//STDOUT DD PATH='&DIR/logs/proc.output',
// PATHOPTS=(OWRONLY,OCREAT,OTRUNC),
// PATHMODE=(SIRUSR,SIWUSR,SIRGRP,SIWGRP)
//STDERR DD PATH='&DIR/logs/proc.errors',
// PATHOPTS=(OWRONLY,OCREAT,OTRUNC),
// PATHMODE=(SIRUSR,SIWUSR,SIRGRP,SIWGRP)
//* SYSMDUMP DD ...
// PEND
//* ================================================================ */
//* PROPRIETARY-STATEMENT: */
//* Licensed Material - Property of IBM */
//* */
//* 5724-I63, 5724-H88, 5655-N01, 5733-W61, 5655-M23 */
//* (C) Copyright IBM Corp. 2006 */
//* All Rights Reserved */
//* US Government Users Restricted Rights - Use, duplication or */
//* disclosure restricted by GSA ADP Schedule Contract with IBM Corp.*/
//* ================================================================ */
|
Figure 2-36 IHSSRVER started task procedure
Define the IHSSRV started task to RACF by issuing the following commands:
RDEFINE STARTED IHSSRV** STDATA(USER(WEBSRV))
SETROPTS RACLIST(STARTED) GENERIC(STARTED) REFRESH
2.1.7 Setting up the LDAP server
The LPAP is used to maintain information about PKI Services certificates in a centralized location. The z/OS LDAP server was configured by using LDBM (file-based backend). No IBM DB2® is required.
|
Note: For more information about setting up the LDAP server, see Chapter 3 of Cryptographic Services PKI Services Guide and Reference SA23-2286.
|
Complete the following steps to set up and configure the LDAP server:
1. Copy ds.profile from /usr/lpp/ldap/etc to the home directory by using the following command:
cp /usr/lpp/ldap/etc/ds.profile /u/kwres01/ds.profile
2. Update it after /usr/lpp/ldap/examples/sample_server/ds.README, with the following information:
LDBM_SUFFIX="c=us" (To enable the ROOTCA, SUBCA1, and SUBCA2 certificates to be posted because they were created by using country=us)
LDBM_SUFFIX="o=The Firm" (To enable the one year browser certificate be posted because it was created by using organization=The Firm)
OUTPUT_DATASET = LDAPCFG.GLD.CNFOUT
OUTPUT_DATASET_VOLUME = BH6CAT
LDBM_DATABASEDIRECTORY =/var/ldap/ldbm
SCHEMAPATH=/var/ldap/schema
ADMINDN=cn=Admin
ADMINPW=secret
PROG_SUFFIX = XX
APF_JOBCARD_1 = //LDAPAPF JOB MSGCLASS=H,NOTIFY=&SYSUID,
APF_JOBCARD_2 = // MSGLEVEL=(1,1),CLASS=A
PRGCTRL_JOBCARD_1 = //LDAPPC JOB MSGCLASS=H,NOTIFY=&SYSUID,
PRGCTRL_JOBCARD_2 = // MSGLEVEL=(1,1),CLASS=A
DB2_JOBCARD_1 =//LDAPDB2 JOB MSGCLASS=H,NOTIFY=&SYSUID,
DB2_JOBCARD_2 = // MSGLEVEL=(1,1),CLASS=A
RACF_JOBCARD_1 = //LDAPRACF JOB MSGCLASS=H,NOTIFY=&SYSUID,
RACF_JOBCARD_2 = // MSGLEVEL=(1,1),CLASS=A
3. Run the dsconfig utility under /usr/lpp/ldap/sbin by using the following command:
/usr/lpp/ldap/sbin/dsconfig -i /u/kwres01/ds.profile
4. Open the LDAPCFG.GLD.CNFOUT data set:
a. Submit the job in the RACF member. The job defines all of the RACF information for the LDAP server.
b. Submit the job in the APF member. A PROG member for the data sets to APF Authorize is in LDAPCFG.GLD.CNFOUT. Before submitting this job, this PROG member must be moved to the PARMLIB. To make the APF changes permanent, the PROG member must be added to the APF list that was created at IPL time.
5. Set up the started task by copying LDAPCFG.GLD.CNFOUT(GLDSRV) to SYS1.PROCLIB(GLDSRV).
6. Update LDAPCFG.GLD.CNFOUT(DSCONFIG) with listen ldap://:390.
7. Start the ldap server by using the - S GLDSRV command.
8. Add the schema that is needed by PKI by issuing the following commands:
ldapmodify -h wtsc76.itso.ibm.com -p 390 -D cn=admin -w secret -f /usr/lpp/ldap/etc/schema.user.ldif
ldapmodify -h wtsc76.itso.ibm.com -p 390 -D cn=admin -w secret -f /usr/lpp/ldap/etc/schema.IBM.ldif
9. Add a member to LDAPCFG.GLD.CNFOUT(SUFFIX), as shown in Figure 2-37.
|
dn: c=us
objectclass: top
objectclass: country
c: us
dn: o=The Firm
objectclass: top
objectclass: organization
o: The Firm
|
Figure 2-37 LDAPCFG.GLD.CNFOUT member SUFFIX
10. Run the ldapadd command to add the suffix by specifying the following information:
ldapadd -h wtsc76.itso.ibm.com -p 390 -D cn=admin -w secret -f "//'ldapcfg.gld.cnfout(suffix)'"
11. Verify that the suffix was added by specifying the following information:
ldapsearch -h wtsc76.itso.ibm.com -p 390 -D cn=admin -w secret -b "o=The Firm" "objectclass=*"
The response is shown in Figure 2-38.
|
o=The Firm
objectclass=top
objectclass=organization
o=The Firm
|
Figure 2-38 LDAP suffix verification
|
Note: For the production system, you might not want to make the LDAP password available in the configuration file after the initial setup.
For more information, see this website:
|
2.1.8 Preparing ROOTCA for use
Complete the following steps to prepare to start the rootca:
1. Start the rootca by using the following command:
s pkiservd,jobname=rootca,dir='/etc/pkiserv/rootca'
(or just s pkiservd,jobname=rootca)
2. Modify the ACL entry for CRL (which has critical attribute) so that any user can see the CRL:
|
dn: OU=ROOTCA ITSO PKI Redbooks,O=IBM,C=US
changetype: modify
aclentry: group:cn=anybody:normal:rsc:system:rsc:critical:rsc
|
Figure 2-39 ACL entry modifications
b. Issue the following command:
"ldapmodify -h wtsc76.itso.ibm.com -p 390 -D cn=admin -w secret -f changeacl.ldif
3. Start the HTTP server by specifying the S IHSSRVER command.
2.1.9 Enabling ROOTCA for use from the browser
Complete the following steps:
1. Enter the http://wtsc76.itso.ibm.com/Rootca/public-cgi/camain.rexx URL into a browser and the window that is shown in Figure 2-40 opens.
Figure 2-40 PKI Services Certificate Generation Application
2. Click Install Certificate to enable SSL sessions for PKI Services.
|
Note: You are accessing the rootca certificate that is in /var/pkiserv, which is specified in vhost80.conf.
|
3. The window that is shown in Figure 2-41 opens. The certificate must be installed in the Trusted Root certificate Authorities store. Select Install Certificate.
Figure 2-41 Certificate store
4. Follow the wizard through to completion.
The certificates are successfully placed in the Trusted Root Certification Authorities store.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.