Adding SSL certificates to a mixed z/OS and Unix queue manager environment - Middleware News
1. Security Considerations
IBM advises customers who are using SSL, that the most secure way to do this is to use recognized Certification Authorities to sign their certificates. Ensuring secure transfer of information is the main purpose of SSL. This integrity must be properly observed when setting up SSL. You should always be certain who has signed each of your SSL certificates, who has had and who continues to have access to them.
The first secure way to generate certificates is to generate a certificate request, on each system or machine that uses SSL. This request has to be signed by an external Certification Authority before it can be used. Getting certificate requests signed by a CA is secure, because during the signing process at no point do any files contain the certificate's Private Keys. This principle is vital to SSL security. Signing certificates in this way is covered by section 10. The secure way to add SSL certificates to your Production MQ system.
The second secure way that external Certificate Authorities commonly use is to supply a signed CA certificate for customers to sign their certificate requests. The Certificate Authorities usually supply other software for SSL certificate administration. This way is very similar to using a built in z/OS facility to sign your own requests that follows.
Within z/OS there is facility to sign SSL certificate requests using CA Certificates created by yourself. It is cheaper and the process is shown below. However there are downsides.
It will require the setting up of a certificate revocation system which will require administration. (This is to cover the eventuality that a certificate you issued should no longer be accepted as valid, perhaps because it has been compromised.)
All companies which use certificates generated in this way, must trust the company who administers the certificates. This should include audit controls.
Time spent signing certificate requests.
Using the z/OS built in function to sign your own certificate requests protects the Private Key in the same way as the first secure way. This alternative should only be used for large scale testing of SSL on internal systems. This is covered in section 11. Securely signing a certificate request from Unix using a z/OS CA certificate.
Sections 3 to 9 describe a slightly different strategy to set up Queue Managers to use SSL. The strategy is effective, but is not recommended in a production environment due to the potential to expose the Private Key. In the strategy described in Sections 3 to 9 the Private Key for Unix certificates is generated on the z/OS machine and is exported with the certificate in a file, which is encrypted and protected with a password. As the private key is created on one machine, and then moved to another, this method is considered less secure. The skills learned by following Sections 3 to 9 are applicable to using the more secure methods described in Sections 10 and 11 (which reference the other relevant sections).
2. Summary of SSL Certificate set up for Queue Managers
Each Queue Manager requires a Key Repository. On z/OS this is a RACF Key Ring and on Unix this is a set of files secured by operating system permissions.
The following sections describe how this Key Repository is created. A summary of the items this Key Repository must contain is provided as follows:
The personal certificate for that Queue Manager with the Private Key associated with that certificate.
The personal certificate should have a label that follows the following convention: On z/OS 'ibmWebSphereMQQMGR' where QMGR is the 4 byte Queue Manager name. For distributed Queue Managers the label should be 'ibmwebspheremqqmgrname' where qmgrname is the full Queue Manager name converting all upper case characters to lower case.
A copy of the Certification Authority (CA) Certificate, used to sign its personal certificate.
A copy of all CA certificates, used to sign all personal certificates (for all Queue Managers) that it will communicate with, using SSL. *
On z/OS the repository is RACF, on distributed systems, it is IKEYMAN
*In some cases a personal certificate has been signed by a CA certificate that has in turn been signed by another CA certificate (known as a certificate chain). Each of these CA certificates, up to the self signed CA certificate, must be included in each Key Repository.
3. Creating the certificates and Key Repository on z/OS
In the example below the z/OS queue manager is called MQ0A. MQ0A has a CHINIT with an associated user of TESTUSER. On Unix the queue manager is called QM_unix.
To understand how to submit RACF commands, see section 14. Submitting RACF commands
Create a Certification Authority on z/OS. See http://www.ibm.com/support/docview.wss?uid=swg27006987 for an explanation of a Certification Authority.
RACDCERT CERTAUTH GENCERT -
SUBJECTSDN(CN('CST CA SQ00') -
T('WMQ') -
OU('TEST') -
O('IBM') -
L('HURSLEY') -
SP('HAMPSHIRE') -
C('UK')) -
WITHLABEL('SQ00 CA')
Create a personal certificate for QMGR MQ0A on z/OS and sign it with the CA SQ00 CA defined above. See http://www.ibm.com/support/docview.wss?uid=swg27006987 for an explanation of a personal certificate.
Note: the case and value of the label is important in SSL certificates. On z/OS the label is mixed case, see below.
RACDCERT ID(TESTUSER) GENCERT -
SUBJECTSDN(CN('Personal Certificate for MQ0A') -
T('QMGR') -
OU('TEST') -
O('IBM') -
L('HURSLEY') -
SP('HAMPSHIRE') -
C('UK')) -
WITHLABEL('ibmWebSphereMQMQ0A') -
SIGNWITH(CERTAUTH LABEL('SQ00 CA'))
Create a personal certificate for the Unix Queue Manager called QM_unix and sign with the CA certificate above.
Note: for distributed Queue Managers the label must be only lower case regardless of the case of the queue manager names - see below.
RACDCERT ID(TESTUSER) GENCERT -
SUBJECTSDN(CN('Personal Cert for QM_unix') -
T('QMGR') -
OU('TEST') -
O('IBM') -
L('HURSLEY') -
SP('HAMPSHIRE') -
C('UK')) -
WITHLABEL('ibmwebspheremqqm_unix') -
SIGNWITH(CERTAUTH LABEL('SQ00 CA'))
Define a Key Ring (or Key Repository) for the z/OS Queue Manager. Where TESTUSER is the User ID associated with the CHINIT started task for Queue Manager MQ0A.
RACDCERT ID(TESTUSER) ADDRING(MQ0ARING)
Connect the CA certificate and MQ0A's personal certificate into the Key Ring.
RACDCERT ID(TESTUSER) CONNECT(CERTAUTH LABEL('SQ00 CA') RING(MQ0ARING))
RACDCERT ID(TESTUSER) -
CONNECT(ID(TESTUSER) LABEL('ibmWebSphereMQMQ0A') RING(MQ0ARING))
Export the personal certificate for QM_unix. This creates a file on z/OS and adds the certificate to the file.
This file will be transferred to the Unix machine.
PKCS12 is a standard format used by z/OS, Windows and Unix, which contains personal certificates and CA certificate information, as well as the Private Key associated with the personal certificate. Other formats do not include the Private Key.
When adding a Personal Certificate to RACF, the CA certificate is not automatically added. If the CA certificate is not already there, then you need to add the CA certificate in a separate step, from a separate file. The CA certificate is typically held in a file in DER format.
The PKCS12 file contains the Private Key of the certificate, which is what makes SSL secure. As a consequence, you need to set a password for the file, to prevent its misuse. This password will be required when the certificate is imported. The password must be kept secret on a need to know basis, otherwise the integrity of your security is compromised! This is why this method is less secure than that used in sections 10 and 11.
RACDCERT ID(TESTUSER) -
EXPORT (LABEL('ibmwebspheremqqm_unix')) -
DSN('MQ.RACD.DIGCERT.UNIX.PKCS12') -
FORMAT(PKCS12DER) -
PASSWORD('ZOSPASS')
The file will have characteristics like the following.
Data Set Name . . . : MQ.RACD.DIGCERT.UNIX.PKCS12
General Data Current Allocation
Volume serial . . . : SP6218 Allocated tracks . : 1
Device type . . . . : 3390 Allocated extents . : 1
Organization . . . : PS
Record format . . . : VB
Record length . . . : 84
Block size . . . . : 27998 Current Utilization
1st extent tracks . : 1 Used tracks . . . . : 1
Secondary tracks . : 5 Used extents . . . : 1
Creation date . . . : 2006/03/06
Referenced date . . : 2006/03/06
Expiration date . . : ***None***
The Signing Certificate must be added before adding the PKCS12 certificate.
So we export it from RACF in DER format.
RACDCERT CERTAUTH EXPORT (-
LABEL('SQ00 CA')) -
DSN('MQS.RACD.DIGCERT.SQ00CA.DER') -
FORMAT(CERTDER)
4. Configuring the z/OS queue manager to use the certificate
The Queue Manager must be altered to use SSL, using MQSC Commands. This adds a pointer to the Key Ring and specifies a number of SSL tasks to process SSL
ALTER QMGR SSLKEYR(MQ0ARING) SSLTASKS(10)
The CHINIT must be stopped and restarted for these changes to take effect.
STOP CHINIT
START CHINIT PARM(MQ0AXPRM)
To make use of SSL, the existing channel (SSLCHANNEL) needs to have an SSL Cipherspec added.
Hint: Before setting up a channel pair to use SSL, it is best to prove that your channel pairing is set up correctly before adding SSL.
ALTER CHANNEL(SSLCHANNEL) CHLTYPE(RCVR) SSLCIPH(RC4_MD5_EXPORT)
Where RC4_MD5_EXPORT is one of the cipher specifications available on all platforms. It defines the Hash Algorithm, the Encryption Algorithm and the number of bits used in encryption. The same value must be used at each end. See Table 1 in Specifying CipherSpecs in the IBM WebSphere MQ Help Center to see which cipherspecs are available and their characteristics. This completes the changes on the z/OS machine.
5. Transfer the certificates from z/OS to the Unix machine
FTP the file (in Binary mode) to the Unix box.
IBM recommends that you use directory /var/mqm/qmgrs/qmgrname/ssl to store your certificates, where qmgrname is your Queue Manager name. They will be left in this directory by subsequent uninstalls, installations and migrations of WMQ. For security reasons, PKCS12 files should only be copied to the directories of the Queue Managers that will use it. This will help you to secure it. DER files should also be kept in the same directory, though the security implications are much reduced.
From the Unix console, go to the directory where you want to place your certificates and FTP the file from z/OS.
cd /var/mqm/qmgrs/QM_unix/ssl
FTP ...
User Name: ....
Password: ********
bin
get 'MQ.RACD.DIGCERT.UNIX.PKCS12 ' unix.p12
get 'MQ.RACD.DIGCERT.SQ00CA.DER ' SQ00CA.der
bye
6. Setting up IKEYMAN to administer SSL certificates on Unix
IKEYMAN is the IBM key management utility for managing certificates on distributed platforms. It is installed (optionally) during WebSphere MQ installation. Although IKEYMAN has a GUI and a command line interface, this document only covers the command line format, as this enables administration from Telnet.
Terms used:
A key database (key.kdb) is a file that IKEYMAN uses to store one or more key pairs and certificates.
A stash file is used by IKEYMAN to store encrypted database passwords.
GSKIT is a set of programmable interfaces that allow an application to be SSL enabled.
GSK7 is GSKIT version 7.
Key Ring and Key Repository are interchangeable terms. Key Ring is used in association with RACF and Key Repository is used in association with Distributed Platforms.
See section 15. Background References below for further details on IKEYMAN & GSKIT.
It is important to use the right User ID to administer the certificates. Ensure that you use a User ID that is either the mqm user or in the mqm group. This will restrict the number of users able to access the certificates and increase your security.
Set the JAVA_HOME for GSK7. This is machine dependant. Note: this step is necessary to add the PKCS12 certificates into the key.kdb.Without this being set correctly, you will get a message indicating that the key.kdb is corrupted.
Two variations are shown below.
export JAVA_HOME=/var/mqm/ssl/jre
for AIX only
export JAVA_HOME=/opt/mqm/ssl/jre
for all other Unix platforms
Change to your chosen directory for Queue Manager QM_unix.
cd /var/mqm/qmgrs/QM_unix/ssl
Create a key.kdb and a stash file, if you do not already have one for the queue manager. The command puts an encrypted version of the password (set here to KEYPASS) in the stash file.
It is used to verify the authority of the GSKIT commands. The password is set to expire after 90 days.
gsk7cmd -keydb -create -db key -pw KEYPASS -type cms -expire 90 -stash
Enable all mqm users to read the key.kdb and the stash file.
If you perform WMQ administration as the 'mqm' user (preferred) then change ownership and permissions of the file as follows:
chown mqm:mqm key.*
chmod 600 key.*
Alternatively, you can grant update permissions to all users in the 'mqm' group as follows:
chown mqm:mqm key.*
chmod 660 key.*
7. Using the certificates on the Unix machine.
Import the DER file (FTP'd above) into key.kdb.
This action adds the Signing CA certificate "SQ00 CA" to the key.kdb. This step must precede the addition of the personal certificate.
gsk7cmd -cert -add -db key.kdb -pw KEYPASS -label "SQ00 CA" -format binary -trust enable -file SQ00CA.der
Import the PKCS12 file (FTP'd above) into key.kdb.
This action adds the personal certificate to the key.kdb.
gsk7cmd -cert -import -file unix.p12 -pw ZOSPASS -type pkcs12 -target key.kdb -target_pw KEYPASS -target_type cms
List all certificates in the key.kdb.
gsk7cmd -cert -list all -db key.kdb -pw KEYPASS -type cms
For this installation I have the following. The last two lines are the CA certificate for "SQ00 CA" (0cn=cst ca ...) and the personal certificate for the Queue Manager (ibmwebspheremq...).
Certificates in database: ./key.kdb
... Other supplied CA certificates
0cn=cst ca sq00, t=wmq, ou=cst, o=ibm, l=hursley, st=hampshire, c=uk
ibmwebspheremqqm_unix
8. Configuring the Unix queue manager to use the certificate.
Use runmqsc to alter the Queue Manager to use the KEY Repository for QM_unix (this is the key.kdb file created above).
runmqsc QM_unix
alter qmgr sslkeyr('/var/mqm/qmgrs/QM_unix/ssl/key')
Note: If you use the default location for key repositories (as above) this command is not necessary. If you store the IKEYMAN key database files in a different location, or use a different filename to 'key.kdb', the format of the SSLKEYR string is the full path of the .kdb file without the .kdb extension.
You do not have to shut down and restart the Queue Manager on WMQ V6 or later releases.
This is because of the MQSC command:
refresh security type(SSL)
Display the Key Repository information for the queue manager.
dis qmgr sslkeyr
dis QMGR sslkeyr
1 : dis QMGR sslkeyr
AMQ8408: Display Queue Manager details.
QMNAME(QM_unix)
SSLKEYR(/var/mqm/qmgrs/QM_unix/ssl/key)
The channel (SSLCHANNEL) needs to have the same SSL Cipherspec at both ends to make use of SSL. The z/OS channel was altered above.
ALTER CHANNEL(SSLCHANNEL) CHLTYPE(SDR) SSLCIPH(RC4_MD5_EXPORT)
Where RC4_MD5_EXPORT is the value used on the z/OS channel.
Start the channel, and show it is active.
START CHANNEL(SSLCHANNEL)
DISPLAY CHSTATUS(SSLCHANNEL)
It should have status RUNNING.
CHANNEL(SSLCHANNEL) CHLTYPE(SDR)
CONNAME(**********) CURRENT
RQMNAME(MQ0A) STATUS(RUNNING)
SUBSTATE(MQGET) XMITQ(***********)
9. Extending the scenario to include another z/OS Queue Manager.
The following actions are required to enable MQ0A and QM_unix to communicate, using SSL, with another z/OS Queue Manager MQ0M on system MV0M.
MQ0M has a CHINIT userid of TESTUSE2. It currently uses SSL and its personal certificate was signed by a CA with a label "SQ01 CA".
MQ0M needs the CA certificate used to sign the personal certificate for MQ0A (and QM_unix). MQ0A and QM_unix need the CA certificate used to sign the personal certificate for MQ0M. This will enable the three Queue Managers to communicate using SSL.
So "SQ00 CA" CA certificate is added into MQ0M's Key Ring and "SQ01 CA" CA certificate into MQ0A's Key Ring and "SQ01 CA" CA certificate is added into the key.kdb associated with QM_unix.
The CA certificates are transported in DER format, which contains the Public key, but not the Private Key associated with it.
The action of adding each CA certificate to the Key Ring, authorizes all personal certificates that it has signed.
This is why RACF gives a warning, during the addition of a CA certificate.
QM_unix uses the same CA certificate as MQ0A. This means there is only a need to include the MQ0A CA certificate and the CA certificate from MQ0M in each Key Repository. If QM_unix used a third CA certificate then that certificate would also be required in each Key Repository.
On MV0A, export the CA certificate created above to a dataset. MQ0M can then add this copy of the MQ0A CA into its Key Ring. This exported certificate contains enough information to verify the two personal certificates that it has signed above.
RACDCERT CERTAUTH EXPORT (-
LABEL('SQ00 CA')) -
DSN('MQ.RACD.DIGCERT.SQ00CA.DER') -
FORMAT(CERTDER)
FTP the file to MV0M as file MQ.RACD.DIGCERT.SQ00CA.DER.
The following actions take place on the MV0M z/OS system.
Add the CA certificate to the MV0M RACF database.
RACDCERT CERTAUTH -
ADD('MQ.RACD.DIGCERT.SQ00CA.DER') -
TRUST -
WITHLABEL('SQ00 CA')
Connect the CA certificate into MQ0M's Key Ring.
RACDCERT ID(TESTUSE2) CONNECT(CERTAUTH LABEL('SQ00 CA') RING(MQ0MRING))
Export the CA certificate used to sign MQ0M's personal certificate.
RACDCERT CERTAUTH EXPORT (-
LABEL('SQ01 CA')) -
DSN('MQ.RACD.DIGCERT.SQ01CA.DER') -
FORMAT(CERTDER)
FTP this file to MV0A z/OS system.
The next set of actions are on the MV0A z/OS system.
Add the CA certificate from MQ0M (label "SQ01 CA") in file MQ.RACD.DIGCERT.SQ01CA.DER to the RACF database for MQ0A.
RACDCERT CERTAUTH -
ADD('MQ.RACD.DIGCERT.SQ01CA.DER') -
TRUST -
WITHLABEL('SQ01 CA')
Connect the MV0M CA certificate into the Key Ring for MQ0A.
RACDCERT ID(TESTUSER) CONNECT(CERTAUTH LABEL('SQ01 CA') RING(MQ0ARING))
The next set of actions are on the Unix system.
Transfer the CA certificate to the Unix box, using the procedure above and continue on the Unix box. This culminates in the following get.
get 'MQ.RACD.DIGCERT.SQ01CA.DER ' SQ01CA.der
Add the MV0M CA certificate to the key.kdb.
gsk7cmd -cert -add -db key.kdb -pw KEYPASS -label "SQ01 CA" -format binary -trust enable -file SQ01CA.der
List all certificates in the key.kdb.
gsk7cmd -cert -list all -db key.kdb -pw KEYPASS -type cms
This now shows "SQ01 CA" added.
Certificates in database: ./key.kdb
SQ01 CA
... Other supplied CA certificates
0cn=cst ca sq00, t=wmq, ou=cst, o=ibm, l=hursley, st=hampshire, c=uk
ibmwebspheremqqm_unix
10. The secure way to gain an SSL certificate for a Production WMQ system.
This section describes how a Key Repository is created for z/OS and Unix queue managers, and a secure way in which a certificate can be requested for that queue manager, from a CA.
In the example below the z/OS queue manager is called MQ0P. MQ0P has a CHINIT with an associated user of PRODUSER. The Unix queue manager is called QM_unixP, and the logged in user is the WMQ administrator ID 'mqm' (or a member of the 'mqm' group).
On z/OS
To generate a request on z/OS use RACF. For details see section 14. Submitting RACF commands
Create a request for a personal certificate. See http://www.ibm.com/support/docview.wss?uid=swg27006987 for an explanation of a personal certificate.
Note: the case and value of the label is important in SSL certificates. On z/OS the label is mixed case, see below.
RACDCERT ID(PRODUSER) GENCERT -
SUBJECTSDN(CN('Personal Certificate for MQ0P') -
T('QMGR') -
OU('PRODN') -
O('IBM') -
L('HURSLEY') -
SP('HAMPSHIRE') -
C('UK')) -
WITHLABEL('ibmWebSphereMQMQ0P'))
This certificate request must be written to a file in order to be sent to a Certificate Authority to be signed. This is achieved by the following.
RACDCERT ID(PRODUSER) -
GENREQ(LABEL('ibmWebSphereMQMQ0P')) -
DSN('MQ.RACD.DIGCERT.CERTREQ.MQ0P.ARM')
This file will be in EBCDIC format and will look something like
-----BEGIN CERTIFICATE-----
MIIC3zCCAkigAwIBAgIBDTANBgkqhkiG9w0BAQUFADBzMQswCQYDVQQGEwJVSzES
MBAGA1UECBMJSEFNUFNISVJFMRAwDgYDVQQHEwdIVVJTTEVZMQwwCgYDVQQKEwNJ
Qk0xDDAKBgNVBAsTA0NTVDEMMAoGA1UEDBMDV01RMRQwEgYDVQQDEwtDU1QgQ0Eg
U1EwMjAeFw0wNjA1MTEwNDAwMDBaFw0wNzA1MTIwMzU5NTlaMHExCzAJBgNVBAYT
AlVLMRIwEAYDVQQIEwlIQU1QU0hJUkUxEDAOBgNVBAcTB0hVUlNMRVkxDDAKBgNV
BAoTA0lCTTENMAsGA1UECxMEVEVTVDENMAsGA1UEDBMEUU1HUjEQMA4GA1UEAwwH
UU1fTUpGNzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAn8oXMIsLZWZiO63x
XldHOILZe6XofqPCwP+aVpbWrjoEJGpDdyBbWQ73iwNrA7+wM4Yd1Q7Fc9ij5fwJ
qm4iCUCV/mqluXVLB2OAkt9rxJojzCB1SKvn9QnOuRF6BbaX0GyRBzKZS+ZaEmXO
44eYwXEUn1+ygi1tAeF/NAwDSNkCAwEAAaOBhDCBgTA/BglghkgBhvhCAQ0EMhMw
R2VuZXJhdGVkIGJ5IHRoZSBTZWN1cml0eSBTZXJ2ZXIgZm9yIHovT1MgKFJBQ0Yp
MB0GA1UdDgQWBBR/Xvs9fGGbpSzfVPLrT0rmjtMaZjAfBgNVHSMEGDAWgBRRwXFF
BnYdlTu/DZP3SAxymrvYrzANBgkqhkiG9w0BAQUFAAOBgQBrc1z1gf217aUCNBPE
dX6OHeEfmlSkiY88AXvrpalhPyCNWuZtZLQpeQiTRdvFbhTbTU/YVPUu3QH+4Vat
DyqOzUic/ra34BRR4xxKhIGi2kMwUNqNPjPsj22tzK1Djle0tsdHYcAUDFAead90
kiplHt2OFRwUfM+zEVfrMVqJlE==
-----END CERTIFICATE-----
This file is ready to be sent to a Certification Authority, by way of whichever email system you choose to use.
Note: If your email system uses ASCII you can use the default ftp setting of ASCII to transfer the file.
When you get your signed certificate returned, put it to a dataset on z/OS. It can then be added to RACF. You should check that the signed certificate looks similar to the above. There is a short part of section 11 that covers possible problems when using ftp to put files to z/OS.
The following RACF command will add the signed personal certificate to RACF.
RACDCERT ID(PRODUSER) -
ADD('MQ.RACD.DIGCERT.CERTREQ.MQ0P.CERTBR64') TRUST -
WITHLABEL('ibmWebSphereMQMQ0P')
Your CA should provide you with a CA certificate, or multiple CA certificates. Unless RACF already contains them, every certificate must be copied to datasets in z/OS and added to RACF.
The RACDCERT ADD command will look something like the following. Where "CA Label" is a label describing the CA certificate. The label you use is not important to WMQ.
RACDCERT CERTAUTH -
ADD('MQ.RACD.DIGCERT.CERTAUTH.DER') -
TRUST WITHLABEL('CA Label')
The private certificate, and all CA certificates, need to be added to a Key Ring (this is also defined in RACF). This Key Ring will become the Key Repository for MQ0P.
The following RACF command defines a Key Ring, where PRODUSER is the User ID associated with the CHINIT started task for Queue Manager MQ0P.
RACDCERT ID(PRODUSER) ADDRING(MQ0PRING)
Connect all CA certificates, and MQ0P's personal certificate into the Key Ring using RACF commands as follows.
RACDCERT ID(PRODUSER) -
CONNECT(CERTAUTH LABEL('CA label') RING(MQ0PRING))
RACDCERT ID(PRODUSER) -
CONNECT(ID(PRODUSER) LABEL('ibmWebSphereMQMQ0P') RING(MQ0PRING))
The remaining actions to enable MQ0P to use SSL are detailed in section 4.Configuring the z/OS queue manager to use the certificate.
Note: This Queue Manager is MQ0P whereas that section refers to MQ0A
On Unix
You must read and apply 6. Setting up IKEYMAN to administer SSL certificates on Unix for this machine and Queue Manager, before you can run the following commands.
Be careful when using the commands in that section to use the name of this Queue Manager (QM_unixP) rather than QM_unix.
Change your working directory to the directory which will contain the files for the queue manager's Key Repository. The following command changes to the default Key Repository directory for a queue manager called QM_unixP.
cd /var/mqm/qmgrs/QM_unixP/ssl
Create a Key Repository for the queue manager. The following command creates a Key Repository with the default name 'key.kdb'.
gsk7cmd -keydb -create -db key.kdb -pw KEYPASS -stash
It is important that the file permissions of the key.* files created allow the WMQ queue manager to read the files, while not giving read access to other users. For example the files can be given u+rw permissions only, if administered by the 'mqm' user, or u+rw,g+rw permissions if administered by other members of the 'mqm' group.
Generate a certificate request from IKEYMAN and put a copy of the (not yet signed) certificate into the certreq.arm file. The label must be of the correct format, as described in Section 2.
gsk7cmd -certreq -create -db key.kdb -pw KEYPASS -label ibmwebspheremqqm_unixp -dn "CN=Personal Certificate for QM_unixP,OU=PROD-N,O=IBM,C=UK" -size 1024 -file certreq.arm
The certreq.arm file is ready to be sent to a Certification Authority, by way of whichever email system you choose to use. The certificate authority will sign the certificate and return it, along with the CA certificates required for that certificate.
This request will not have any Private Keys contained in the file, which makes this method very secure.
Note: The files returned may be in binary or ASCII format. I have assumed it is in ASCII format and that you detached them to CAcert.der and unixp.certb64 in the above directory.
Your CA should provide you with a CA certificate, or multiple CA certificates. These must all be added to the Key Repository of the queue manager (starting with the root CA certificate and working down the chain). The command below will add a CA certificate to the key repository, where "CAcert.der" is the file sent by the CA and placed in the same directory as the Key Repository, and "CA label" is a label describing the certificate. The label you use is not important to WMQ.
gsk7cmd -cert -add -db key.kdb -pw KEYPASS -label "CA label" -format ascii -trust enable -file CAcert.der
Once all CA certificates have been added, you can receive the signed personal certificate for the Queue Manager back into the Key Repository (where the private key has been kept safe). The following command receives a signed certificate back into the Key Repository.
gsk7cmd -cert -receive -file unixp.certbr64 -db key.kdb -pw KEYPASS -format ascii -label ibmwebspheremqqm_unixp -default_cert yes
The remaining actions to enable QM_unixP to use SSL are detailed in section 8. Configuring the Unix queue manager to use the certificate.
Be careful when using the commands in that section to use the name of this Queue Manager (QM_unixP) rather than QM_unix.
From reading section 2. Summary of SSL Certificate set-up for Queue Managers, you will see that all CA certificates used to sign personal certificates must be added to all key repositories.
11. Securely signing a certificate request from Unix using a z/OS CA certificate
If you are looking to set up an internal system using SSL certificates, you may not want to involve the expense of using an external Certification Authority. This section shows how you can use RACF (on z/OS) to sign certificate requests that you generated for Unix Queue Managers using the steps in Section 10. The secure way to gain an SSL certificate for a Production WMQ system.
For instructions on how to host a CA on a Windows or Unix machine see:
http://www.ibm.com/support/docview.wss?uid=swg21233897 for
As all certificates in your environment are signed by the same CA, your queue managers will trust that CA to validate the identity of other queue managers in your environment.
In this example, we will enable QM_unixP to communicate with any Queue Manager that is set up with a certificate signed by the same CA certificate (in this example label 'SQ00 CA'). This includes any other Unix, Windows and z/OS Queue Managers.
On unixP
The following commands take place on a Unix machine that we will call unixP. This machine hosts Queue Manager QM_unixP.
You must read and action 6. Setting up IKEYMAN to administer SSL certificates on Unix for this machine and Queue Manager, before you can run the following commands.
Be careful when using the commands in that section to use the name of this Queue Manager (QM_unixP) rather than QM_unix.
In Section 10 we described how to create a Key Repository for a Unix queue manager, create a certificate request and send it to a CA to be signed. For this Section we will generate a certificate request from IKEYMAN as follows.
Change directory to the location of the Key Repository.
cd /var/mqm/qmgrs/QM_unixP/ssl
Generate a certificate request and put a copy of the certificate into the certreq.arm file.
gsk7cmd -certreq -create -db key.kdb -pw KEYPASS -label ibmwebspheremqqm_unixp -dn "CN=Personal Certificate for QM_unixP,OU=PROD-N,O=IBM,C=UK" -size 1024 -file certreq.arm
You can now ftp the certificate request (in ASCII mode) to z/OS.
FTP ...
User Name: ....
Password: ********
quote site recfm=vb
cd 'MQ.RACD.DIGCERT'
put certreq.arm UNIXP.ARM
bye
Note: RACF may have difficulty reading your request if you did not specify the SITE FTP command. This causes hex '0D' to be inserted at the end of each line. To correct this edit the file on z/OS with the command Hex on and overtype. It should look like the example in section 10. The secure way to gain an SSL certificate for a Production WMQ system.
The following actions take place on the z/OS system.
To understand how to submit RACF commands, see section 14. Submitting RACF commands
The Certification Authority certificate on z/OS is defined as follows. See http://www.ibm.com/support/docview.wss?uid=swg27006987 for an explanation of a Certification Authority.
RACDCERT CERTAUTH GENCERT -
SUBJECTSDN(CN('CST CA SQ00') -
T('WMQ') -
OU('TEST') -
O('IBM') -
L('HURSLEY') -
SP('HAMPSHIRE') -
C('UK')) -
WITHLABEL('SQ00 CA')
Sign the Certificate request from unixP using the CA certificate in RACF. The user ID used here, TESTUSER provides an intermediate place to store the signed public certificate before it is transferred back to the Unix system where it will be used.
RACDCERT ID(TESTUSER) GENCERT( 'MQ.RACD.DIGCERT.UNIXP.ARM ' ) -
WITHLABEL('ibmwebspheremqqm_unixp')) -
SIGNWITH( CERTAUTH LABEL('SQ00 CA'))
The certificate is now in RACF so Export the certificate you have just signed from the TESTUSER profile, to a file for transfer back to the Unix system.
RACDCERT ID(TESTUSER) EXPORT (-
LABEL('ibmwebspheremqqm_unixp')) -
DSN('MQ.RACD.DIGCERT.UNIXP.CERTB64') -
FORMAT(CERTB64)
Also Export the signing CA certificate. This creates a DER file
RACDCERT CERTAUTH EXPORT (-
LABEL('SQ00 CA')) -
DSN('MQ.RACD.DIGCERT.SQ00CA.DER') -
FORMAT(CERTDER)
The following takes place on the unixP system.
You can now ftp the signed certificate (in ASCII mode) and the CA certificate (in Binary mode) to Unix from the appropriate directory.
cd /var/mqm/qmgrs/QM_unixP/ssl
FTP ...
User Name: ....
Password: ********
cd 'MQ.RACD.DIGCERT'
get UNIXP.CERTB64 unixp.certb64
bin
get SQ00CA.DER SQ00CA.der
bye
Firstly add the CA certificate to the key repository.
gsk7cmd -cert -add -db key.kdb -pw KEYPASS -label "SQ00 CA" -format binary -trust enable -file SQ00CA.der
You can now add the signed personal certificate to the key.kdb database using a command like the following.
gsk7cmd -cert -receive -file unixp.certb64 -db key.kdb -pw KEYPASS -format ascii -default_cert yes
The remaining actions to get QM_unixP using SSL are detailed in section 8. Configuring the Unix queue manager to use the certificate.
Be careful when using the commands in that section, to use the name of this Queue Manager (QM_unixP) rather than QM_unix.
On z/OS
There is no need to generate certificate requests from z/OS Queue Managers in cases where they are signed by a CA certificate on the same system. Certificates used on z/OS as the equivalent of the above certificate can be generated and signed by the CA certificate in RACF on that same image in a single command.
Create a personal certificate for QMGR MQ0A on z/OS and sign it with the same CA certificate label SQ00 CA. See http://www.ibm.com/support/docview.wss?uid=swg27006987 for an explanation of a personal certificate.
Note: The case and value of the label is important in SSL certificates. On z/OS the label is mixed case, see below.
RACDCERT ID(TESTUSER) GENCERT -
SUBJECTSDN(CN('Personal Certificate for MQ0A') -
T('QMGR') -
OU('TEST') -
O('IBM') -
L('HURSLEY') -
SP('HAMPSHIRE') -
C('UK')) -
WITHLABEL('ibmWebSphereMQMQ0A') -
SIGNWITH(CERTAUTH LABEL('SQ00 CA'))
Define a Key Ring (or Key Repository) for the z/OS Queue Manager. Where TESTUSER is the User ID associated with the CHINIT started task for Queue Manager MQ0A.
RACDCERT ID(TESTUSER) ADDRING(MQ0ARING)
Connect the CA certificate and MQ0A's personal certificate into the Key Ring.
RACDCERT ID(TESTUSER) CONNECT(CERTAUTH LABEL('SQ00 CA') RING(MQ0ARING))
RACDCERT ID(TESTUSER) -
CONNECT(ID(TESTUSER) LABEL('ibmWebSphereMQMQ0A') RING(MQ0ARING))
You will need to read and apply section 4. Configuring the z/OS Queue Manager to use the certificate.
This example has shown how to enable two Queue Managers to communicate using SSL. To enable other Unix Queue Managers to communicate, simply repeat the process outlined above for Unix Queue Managers for a new Queue Manager. Section 9. Extending the scenario to include another z/OS Queue Manager shows how to extend to include another Queue Managers on another z/OS system.
12. Other useful GSK7 Commands.
The following command changes the password on the key.kdb and causes it to expire in 90 days. If the -expire option is omitted, the password will not expire.
gsk7cmd -keydb -changepw -db key.kdb -pw KEYPASS -new_pw new_password -expire 90 -stash
To delete a certificate from the key.kdb.
For example, if you wish to exclude all messages from Queue Managers using a given CA..
gsk7cmd -cert -delete -db key.kdb -pw KEYPASS -label "SQ00 CA"
To delete the key.kdb file to start again.
gsk7cmd -keydb -delete -db key.kdb -pw KEYPASS -type cms
In a production environment, deleting a personal certificate or a Key Repository is a significant action. In a secure environment, the Key Repository is the only place where the private key for a personal certificate exists. If this private key is deleted, then the personal certificate is rendered useless. The private key cannot be recreated. Due to this, care should be taken when deleting certificates or certificate repositories.
13. Some useful RACF commands.
To list the CA certificates have been defined.
RACDCERT CERTAUTH LIST
List the personal certificates have been defined to user TESTUSER.
RACDCERT ID(TESTUSER) LIST
List the personal certificates have been defined to user TESTUSER in Key Ring MQ0ARING.
RACDCERT ID(TESTUSER) LISTRING(MQ0ARING)
Delete a specified CA certificate. Here is one you want to be VERY careful about its use. When you submit this you render useless all personal certificates that it has signed!
RACDCERT CERTAUTH DELETE(LABEL('SQ00 CA'))
Delete a specified personal certificate. This renders the personal certificate useless, but allows you to start again.
RACDCERT ID(TESTUSER) DELETE(LABEL('ibmWebSphereMQMQ0A'))
Delete the Key Ring MQ0ARING associated with user ID TESTUSER.
RACDCERT ID(TESTUSER) DELRING(MQ0ARING)
Refresh the certificates in the RACF Database. You will be prompted for this on z/OS 1.9 if you require your changes to be effective immediately.
SETROPTS RACLIST(DIGTCERT) REFRESH
14. Submitting RACF commands.
Note: To create digital certificates you will need the appropriate authority to issue the RACDCERT command, from your RACF System Administrator.
The RACF command RACDCERT is used to generate and manipulate digital certificates on z/OS. You can issue these commands in batch, for example using the following JCL.
//RACDSUB EXEC PGM=IKJEFT01,DYNAMNBR=20
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
RACDCERT ...
From TSO you can also submit the commands from the ISPF Command Shell (usually =6)
You can submit commands by prefixing them with TSO from ISPF.
Tip: Keep a record of what you have done! The best way to do this is by keeping a copy of what you did in a JCL library.
15. Background References.
For a more detailed explanation of what SSL is, click here http://www-306.ibm.com/software/webservers/httpservers/doc/v1319/9atssl.htm
For further details on how to use IKEYMAN, its' commands and platform specifics for platforms other than HP UX & AIX see the following site: http://www-306.ibm.com/software/webservers/httpservers/doc/v1319/9atikeyu.htm#HDRKMUEXPG.
GSKIT is a set of programmable interfaces that allow an application to be SSL enabled. Seehttp://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/rzab6/rzab6cgskit.htm for further details on using this API.
1. Security Considerations
IBM advises customers who are using SSL, that the most secure way to do this is to use recognized Certification Authorities to sign their certificates. Ensuring secure transfer of information is the main purpose of SSL. This integrity must be properly observed when setting up SSL. You should always be certain who has signed each of your SSL certificates, who has had and who continues to have access to them.
The first secure way to generate certificates is to generate a certificate request, on each system or machine that uses SSL. This request has to be signed by an external Certification Authority before it can be used. Getting certificate requests signed by a CA is secure, because during the signing process at no point do any files contain the certificate's Private Keys. This principle is vital to SSL security. Signing certificates in this way is covered by section 10. The secure way to add SSL certificates to your Production MQ system.
The second secure way that external Certificate Authorities commonly use is to supply a signed CA certificate for customers to sign their certificate requests. The Certificate Authorities usually supply other software for SSL certificate administration. This way is very similar to using a built in z/OS facility to sign your own requests that follows.
Within z/OS there is facility to sign SSL certificate requests using CA Certificates created by yourself. It is cheaper and the process is shown below. However there are downsides.
It will require the setting up of a certificate revocation system which will require administration. (This is to cover the eventuality that a certificate you issued should no longer be accepted as valid, perhaps because it has been compromised.)
All companies which use certificates generated in this way, must trust the company who administers the certificates. This should include audit controls.
Time spent signing certificate requests.
Using the z/OS built in function to sign your own certificate requests protects the Private Key in the same way as the first secure way. This alternative should only be used for large scale testing of SSL on internal systems. This is covered in section 11. Securely signing a certificate request from Unix using a z/OS CA certificate.
Sections 3 to 9 describe a slightly different strategy to set up Queue Managers to use SSL. The strategy is effective, but is not recommended in a production environment due to the potential to expose the Private Key. In the strategy described in Sections 3 to 9 the Private Key for Unix certificates is generated on the z/OS machine and is exported with the certificate in a file, which is encrypted and protected with a password. As the private key is created on one machine, and then moved to another, this method is considered less secure. The skills learned by following Sections 3 to 9 are applicable to using the more secure methods described in Sections 10 and 11 (which reference the other relevant sections).
2. Summary of SSL Certificate set up for Queue Managers
Each Queue Manager requires a Key Repository. On z/OS this is a RACF Key Ring and on Unix this is a set of files secured by operating system permissions.
The following sections describe how this Key Repository is created. A summary of the items this Key Repository must contain is provided as follows:
The personal certificate for that Queue Manager with the Private Key associated with that certificate.
The personal certificate should have a label that follows the following convention: On z/OS 'ibmWebSphereMQQMGR' where QMGR is the 4 byte Queue Manager name. For distributed Queue Managers the label should be 'ibmwebspheremqqmgrname' where qmgrname is the full Queue Manager name converting all upper case characters to lower case.
A copy of the Certification Authority (CA) Certificate, used to sign its personal certificate.
A copy of all CA certificates, used to sign all personal certificates (for all Queue Managers) that it will communicate with, using SSL. *
On z/OS the repository is RACF, on distributed systems, it is IKEYMAN
*In some cases a personal certificate has been signed by a CA certificate that has in turn been signed by another CA certificate (known as a certificate chain). Each of these CA certificates, up to the self signed CA certificate, must be included in each Key Repository.
3. Creating the certificates and Key Repository on z/OS
In the example below the z/OS queue manager is called MQ0A. MQ0A has a CHINIT with an associated user of TESTUSER. On Unix the queue manager is called QM_unix.
To understand how to submit RACF commands, see section 14. Submitting RACF commands
Create a Certification Authority on z/OS. See http://www.ibm.com/support/docview.wss?uid=swg27006987 for an explanation of a Certification Authority.
RACDCERT CERTAUTH GENCERT -
SUBJECTSDN(CN('CST CA SQ00') -
T('WMQ') -
OU('TEST') -
O('IBM') -
L('HURSLEY') -
SP('HAMPSHIRE') -
C('UK')) -
WITHLABEL('SQ00 CA')
Create a personal certificate for QMGR MQ0A on z/OS and sign it with the CA SQ00 CA defined above. See http://www.ibm.com/support/docview.wss?uid=swg27006987 for an explanation of a personal certificate.
Note: the case and value of the label is important in SSL certificates. On z/OS the label is mixed case, see below.
RACDCERT ID(TESTUSER) GENCERT -
SUBJECTSDN(CN('Personal Certificate for MQ0A') -
T('QMGR') -
OU('TEST') -
O('IBM') -
L('HURSLEY') -
SP('HAMPSHIRE') -
C('UK')) -
WITHLABEL('ibmWebSphereMQMQ0A') -
SIGNWITH(CERTAUTH LABEL('SQ00 CA'))
Create a personal certificate for the Unix Queue Manager called QM_unix and sign with the CA certificate above.
Note: for distributed Queue Managers the label must be only lower case regardless of the case of the queue manager names - see below.
RACDCERT ID(TESTUSER) GENCERT -
SUBJECTSDN(CN('Personal Cert for QM_unix') -
T('QMGR') -
OU('TEST') -
O('IBM') -
L('HURSLEY') -
SP('HAMPSHIRE') -
C('UK')) -
WITHLABEL('ibmwebspheremqqm_unix') -
SIGNWITH(CERTAUTH LABEL('SQ00 CA'))
Define a Key Ring (or Key Repository) for the z/OS Queue Manager. Where TESTUSER is the User ID associated with the CHINIT started task for Queue Manager MQ0A.
RACDCERT ID(TESTUSER) ADDRING(MQ0ARING)
Connect the CA certificate and MQ0A's personal certificate into the Key Ring.
RACDCERT ID(TESTUSER) CONNECT(CERTAUTH LABEL('SQ00 CA') RING(MQ0ARING))
RACDCERT ID(TESTUSER) -
CONNECT(ID(TESTUSER) LABEL('ibmWebSphereMQMQ0A') RING(MQ0ARING))
Export the personal certificate for QM_unix. This creates a file on z/OS and adds the certificate to the file.
This file will be transferred to the Unix machine.
PKCS12 is a standard format used by z/OS, Windows and Unix, which contains personal certificates and CA certificate information, as well as the Private Key associated with the personal certificate. Other formats do not include the Private Key.
When adding a Personal Certificate to RACF, the CA certificate is not automatically added. If the CA certificate is not already there, then you need to add the CA certificate in a separate step, from a separate file. The CA certificate is typically held in a file in DER format.
The PKCS12 file contains the Private Key of the certificate, which is what makes SSL secure. As a consequence, you need to set a password for the file, to prevent its misuse. This password will be required when the certificate is imported. The password must be kept secret on a need to know basis, otherwise the integrity of your security is compromised! This is why this method is less secure than that used in sections 10 and 11.
RACDCERT ID(TESTUSER) -
EXPORT (LABEL('ibmwebspheremqqm_unix')) -
DSN('MQ.RACD.DIGCERT.UNIX.PKCS12') -
FORMAT(PKCS12DER) -
PASSWORD('ZOSPASS')
The file will have characteristics like the following.
Data Set Name . . . : MQ.RACD.DIGCERT.UNIX.PKCS12
General Data Current Allocation
Volume serial . . . : SP6218 Allocated tracks . : 1
Device type . . . . : 3390 Allocated extents . : 1
Organization . . . : PS
Record format . . . : VB
Record length . . . : 84
Block size . . . . : 27998 Current Utilization
1st extent tracks . : 1 Used tracks . . . . : 1
Secondary tracks . : 5 Used extents . . . : 1
Creation date . . . : 2006/03/06
Referenced date . . : 2006/03/06
Expiration date . . : ***None***
The Signing Certificate must be added before adding the PKCS12 certificate.
So we export it from RACF in DER format.
RACDCERT CERTAUTH EXPORT (-
LABEL('SQ00 CA')) -
DSN('MQS.RACD.DIGCERT.SQ00CA.DER') -
FORMAT(CERTDER)
4. Configuring the z/OS queue manager to use the certificate
The Queue Manager must be altered to use SSL, using MQSC Commands. This adds a pointer to the Key Ring and specifies a number of SSL tasks to process SSL
ALTER QMGR SSLKEYR(MQ0ARING) SSLTASKS(10)
The CHINIT must be stopped and restarted for these changes to take effect.
STOP CHINIT
START CHINIT PARM(MQ0AXPRM)
To make use of SSL, the existing channel (SSLCHANNEL) needs to have an SSL Cipherspec added.
Hint: Before setting up a channel pair to use SSL, it is best to prove that your channel pairing is set up correctly before adding SSL.
ALTER CHANNEL(SSLCHANNEL) CHLTYPE(RCVR) SSLCIPH(RC4_MD5_EXPORT)
Where RC4_MD5_EXPORT is one of the cipher specifications available on all platforms. It defines the Hash Algorithm, the Encryption Algorithm and the number of bits used in encryption. The same value must be used at each end. See Table 1 in Specifying CipherSpecs in the IBM WebSphere MQ Help Center to see which cipherspecs are available and their characteristics. This completes the changes on the z/OS machine.
5. Transfer the certificates from z/OS to the Unix machine
FTP the file (in Binary mode) to the Unix box.
IBM recommends that you use directory /var/mqm/qmgrs/qmgrname/ssl to store your certificates, where qmgrname is your Queue Manager name. They will be left in this directory by subsequent uninstalls, installations and migrations of WMQ. For security reasons, PKCS12 files should only be copied to the directories of the Queue Managers that will use it. This will help you to secure it. DER files should also be kept in the same directory, though the security implications are much reduced.
From the Unix console, go to the directory where you want to place your certificates and FTP the file from z/OS.
cd /var/mqm/qmgrs/QM_unix/ssl
FTP ...
User Name: ....
Password: ********
bin
get 'MQ.RACD.DIGCERT.UNIX.PKCS12 ' unix.p12
get 'MQ.RACD.DIGCERT.SQ00CA.DER ' SQ00CA.der
bye
6. Setting up IKEYMAN to administer SSL certificates on Unix
IKEYMAN is the IBM key management utility for managing certificates on distributed platforms. It is installed (optionally) during WebSphere MQ installation. Although IKEYMAN has a GUI and a command line interface, this document only covers the command line format, as this enables administration from Telnet.
Terms used:
A key database (key.kdb) is a file that IKEYMAN uses to store one or more key pairs and certificates.
A stash file is used by IKEYMAN to store encrypted database passwords.
GSKIT is a set of programmable interfaces that allow an application to be SSL enabled.
GSK7 is GSKIT version 7.
Key Ring and Key Repository are interchangeable terms. Key Ring is used in association with RACF and Key Repository is used in association with Distributed Platforms.
See section 15. Background References below for further details on IKEYMAN & GSKIT.
It is important to use the right User ID to administer the certificates. Ensure that you use a User ID that is either the mqm user or in the mqm group. This will restrict the number of users able to access the certificates and increase your security.
Set the JAVA_HOME for GSK7. This is machine dependant. Note: this step is necessary to add the PKCS12 certificates into the key.kdb.Without this being set correctly, you will get a message indicating that the key.kdb is corrupted.
Two variations are shown below.
export JAVA_HOME=/var/mqm/ssl/jre
for AIX only
export JAVA_HOME=/opt/mqm/ssl/jre
for all other Unix platforms
Change to your chosen directory for Queue Manager QM_unix.
cd /var/mqm/qmgrs/QM_unix/ssl
Create a key.kdb and a stash file, if you do not already have one for the queue manager. The command puts an encrypted version of the password (set here to KEYPASS) in the stash file.
It is used to verify the authority of the GSKIT commands. The password is set to expire after 90 days.
gsk7cmd -keydb -create -db key -pw KEYPASS -type cms -expire 90 -stash
Enable all mqm users to read the key.kdb and the stash file.
If you perform WMQ administration as the 'mqm' user (preferred) then change ownership and permissions of the file as follows:
chown mqm:mqm key.*
chmod 600 key.*
Alternatively, you can grant update permissions to all users in the 'mqm' group as follows:
chown mqm:mqm key.*
chmod 660 key.*
7. Using the certificates on the Unix machine.
Import the DER file (FTP'd above) into key.kdb.
This action adds the Signing CA certificate "SQ00 CA" to the key.kdb. This step must precede the addition of the personal certificate.
gsk7cmd -cert -add -db key.kdb -pw KEYPASS -label "SQ00 CA" -format binary -trust enable -file SQ00CA.der
Import the PKCS12 file (FTP'd above) into key.kdb.
This action adds the personal certificate to the key.kdb.
gsk7cmd -cert -import -file unix.p12 -pw ZOSPASS -type pkcs12 -target key.kdb -target_pw KEYPASS -target_type cms
List all certificates in the key.kdb.
gsk7cmd -cert -list all -db key.kdb -pw KEYPASS -type cms
For this installation I have the following. The last two lines are the CA certificate for "SQ00 CA" (0cn=cst ca ...) and the personal certificate for the Queue Manager (ibmwebspheremq...).
Certificates in database: ./key.kdb
... Other supplied CA certificates
0cn=cst ca sq00, t=wmq, ou=cst, o=ibm, l=hursley, st=hampshire, c=uk
ibmwebspheremqqm_unix
8. Configuring the Unix queue manager to use the certificate.
Use runmqsc to alter the Queue Manager to use the KEY Repository for QM_unix (this is the key.kdb file created above).
runmqsc QM_unix
alter qmgr sslkeyr('/var/mqm/qmgrs/QM_unix/ssl/key')
Note: If you use the default location for key repositories (as above) this command is not necessary. If you store the IKEYMAN key database files in a different location, or use a different filename to 'key.kdb', the format of the SSLKEYR string is the full path of the .kdb file without the .kdb extension.
You do not have to shut down and restart the Queue Manager on WMQ V6 or later releases.
This is because of the MQSC command:
refresh security type(SSL)
Display the Key Repository information for the queue manager.
dis qmgr sslkeyr
dis QMGR sslkeyr
1 : dis QMGR sslkeyr
AMQ8408: Display Queue Manager details.
QMNAME(QM_unix)
SSLKEYR(/var/mqm/qmgrs/QM_unix/ssl/key)
The channel (SSLCHANNEL) needs to have the same SSL Cipherspec at both ends to make use of SSL. The z/OS channel was altered above.
ALTER CHANNEL(SSLCHANNEL) CHLTYPE(SDR) SSLCIPH(RC4_MD5_EXPORT)
Where RC4_MD5_EXPORT is the value used on the z/OS channel.
Start the channel, and show it is active.
START CHANNEL(SSLCHANNEL)
DISPLAY CHSTATUS(SSLCHANNEL)
It should have status RUNNING.
CHANNEL(SSLCHANNEL) CHLTYPE(SDR)
CONNAME(**********) CURRENT
RQMNAME(MQ0A) STATUS(RUNNING)
SUBSTATE(MQGET) XMITQ(***********)
9. Extending the scenario to include another z/OS Queue Manager.
The following actions are required to enable MQ0A and QM_unix to communicate, using SSL, with another z/OS Queue Manager MQ0M on system MV0M.
MQ0M has a CHINIT userid of TESTUSE2. It currently uses SSL and its personal certificate was signed by a CA with a label "SQ01 CA".
MQ0M needs the CA certificate used to sign the personal certificate for MQ0A (and QM_unix). MQ0A and QM_unix need the CA certificate used to sign the personal certificate for MQ0M. This will enable the three Queue Managers to communicate using SSL.
So "SQ00 CA" CA certificate is added into MQ0M's Key Ring and "SQ01 CA" CA certificate into MQ0A's Key Ring and "SQ01 CA" CA certificate is added into the key.kdb associated with QM_unix.
The CA certificates are transported in DER format, which contains the Public key, but not the Private Key associated with it.
The action of adding each CA certificate to the Key Ring, authorizes all personal certificates that it has signed.
This is why RACF gives a warning, during the addition of a CA certificate.
QM_unix uses the same CA certificate as MQ0A. This means there is only a need to include the MQ0A CA certificate and the CA certificate from MQ0M in each Key Repository. If QM_unix used a third CA certificate then that certificate would also be required in each Key Repository.
On MV0A, export the CA certificate created above to a dataset. MQ0M can then add this copy of the MQ0A CA into its Key Ring. This exported certificate contains enough information to verify the two personal certificates that it has signed above.
RACDCERT CERTAUTH EXPORT (-
LABEL('SQ00 CA')) -
DSN('MQ.RACD.DIGCERT.SQ00CA.DER') -
FORMAT(CERTDER)
FTP the file to MV0M as file MQ.RACD.DIGCERT.SQ00CA.DER.
The following actions take place on the MV0M z/OS system.
Add the CA certificate to the MV0M RACF database.
RACDCERT CERTAUTH -
ADD('MQ.RACD.DIGCERT.SQ00CA.DER') -
TRUST -
WITHLABEL('SQ00 CA')
Connect the CA certificate into MQ0M's Key Ring.
RACDCERT ID(TESTUSE2) CONNECT(CERTAUTH LABEL('SQ00 CA') RING(MQ0MRING))
Export the CA certificate used to sign MQ0M's personal certificate.
RACDCERT CERTAUTH EXPORT (-
LABEL('SQ01 CA')) -
DSN('MQ.RACD.DIGCERT.SQ01CA.DER') -
FORMAT(CERTDER)
FTP this file to MV0A z/OS system.
The next set of actions are on the MV0A z/OS system.
Add the CA certificate from MQ0M (label "SQ01 CA") in file MQ.RACD.DIGCERT.SQ01CA.DER to the RACF database for MQ0A.
RACDCERT CERTAUTH -
ADD('MQ.RACD.DIGCERT.SQ01CA.DER') -
TRUST -
WITHLABEL('SQ01 CA')
Connect the MV0M CA certificate into the Key Ring for MQ0A.
RACDCERT ID(TESTUSER) CONNECT(CERTAUTH LABEL('SQ01 CA') RING(MQ0ARING))
The next set of actions are on the Unix system.
Transfer the CA certificate to the Unix box, using the procedure above and continue on the Unix box. This culminates in the following get.
get 'MQ.RACD.DIGCERT.SQ01CA.DER ' SQ01CA.der
Add the MV0M CA certificate to the key.kdb.
gsk7cmd -cert -add -db key.kdb -pw KEYPASS -label "SQ01 CA" -format binary -trust enable -file SQ01CA.der
List all certificates in the key.kdb.
gsk7cmd -cert -list all -db key.kdb -pw KEYPASS -type cms
This now shows "SQ01 CA" added.
Certificates in database: ./key.kdb
SQ01 CA
... Other supplied CA certificates
0cn=cst ca sq00, t=wmq, ou=cst, o=ibm, l=hursley, st=hampshire, c=uk
ibmwebspheremqqm_unix
10. The secure way to gain an SSL certificate for a Production WMQ system.
This section describes how a Key Repository is created for z/OS and Unix queue managers, and a secure way in which a certificate can be requested for that queue manager, from a CA.
In the example below the z/OS queue manager is called MQ0P. MQ0P has a CHINIT with an associated user of PRODUSER. The Unix queue manager is called QM_unixP, and the logged in user is the WMQ administrator ID 'mqm' (or a member of the 'mqm' group).
On z/OS
To generate a request on z/OS use RACF. For details see section 14. Submitting RACF commands
Create a request for a personal certificate. See http://www.ibm.com/support/docview.wss?uid=swg27006987 for an explanation of a personal certificate.
Note: the case and value of the label is important in SSL certificates. On z/OS the label is mixed case, see below.
RACDCERT ID(PRODUSER) GENCERT -
SUBJECTSDN(CN('Personal Certificate for MQ0P') -
T('QMGR') -
OU('PRODN') -
O('IBM') -
L('HURSLEY') -
SP('HAMPSHIRE') -
C('UK')) -
WITHLABEL('ibmWebSphereMQMQ0P'))
This certificate request must be written to a file in order to be sent to a Certificate Authority to be signed. This is achieved by the following.
RACDCERT ID(PRODUSER) -
GENREQ(LABEL('ibmWebSphereMQMQ0P')) -
DSN('MQ.RACD.DIGCERT.CERTREQ.MQ0P.ARM')
This file will be in EBCDIC format and will look something like
-----BEGIN CERTIFICATE-----
MIIC3zCCAkigAwIBAgIBDTANBgkqhkiG9w0BAQUFADBzMQswCQYDVQQGEwJVSzES
MBAGA1UECBMJSEFNUFNISVJFMRAwDgYDVQQHEwdIVVJTTEVZMQwwCgYDVQQKEwNJ
Qk0xDDAKBgNVBAsTA0NTVDEMMAoGA1UEDBMDV01RMRQwEgYDVQQDEwtDU1QgQ0Eg
U1EwMjAeFw0wNjA1MTEwNDAwMDBaFw0wNzA1MTIwMzU5NTlaMHExCzAJBgNVBAYT
AlVLMRIwEAYDVQQIEwlIQU1QU0hJUkUxEDAOBgNVBAcTB0hVUlNMRVkxDDAKBgNV
BAoTA0lCTTENMAsGA1UECxMEVEVTVDENMAsGA1UEDBMEUU1HUjEQMA4GA1UEAwwH
UU1fTUpGNzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAn8oXMIsLZWZiO63x
XldHOILZe6XofqPCwP+aVpbWrjoEJGpDdyBbWQ73iwNrA7+wM4Yd1Q7Fc9ij5fwJ
qm4iCUCV/mqluXVLB2OAkt9rxJojzCB1SKvn9QnOuRF6BbaX0GyRBzKZS+ZaEmXO
44eYwXEUn1+ygi1tAeF/NAwDSNkCAwEAAaOBhDCBgTA/BglghkgBhvhCAQ0EMhMw
R2VuZXJhdGVkIGJ5IHRoZSBTZWN1cml0eSBTZXJ2ZXIgZm9yIHovT1MgKFJBQ0Yp
MB0GA1UdDgQWBBR/Xvs9fGGbpSzfVPLrT0rmjtMaZjAfBgNVHSMEGDAWgBRRwXFF
BnYdlTu/DZP3SAxymrvYrzANBgkqhkiG9w0BAQUFAAOBgQBrc1z1gf217aUCNBPE
dX6OHeEfmlSkiY88AXvrpalhPyCNWuZtZLQpeQiTRdvFbhTbTU/YVPUu3QH+4Vat
DyqOzUic/ra34BRR4xxKhIGi2kMwUNqNPjPsj22tzK1Djle0tsdHYcAUDFAead90
kiplHt2OFRwUfM+zEVfrMVqJlE==
-----END CERTIFICATE-----
This file is ready to be sent to a Certification Authority, by way of whichever email system you choose to use.
Note: If your email system uses ASCII you can use the default ftp setting of ASCII to transfer the file.
When you get your signed certificate returned, put it to a dataset on z/OS. It can then be added to RACF. You should check that the signed certificate looks similar to the above. There is a short part of section 11 that covers possible problems when using ftp to put files to z/OS.
The following RACF command will add the signed personal certificate to RACF.
RACDCERT ID(PRODUSER) -
ADD('MQ.RACD.DIGCERT.CERTREQ.MQ0P.CERTBR64') TRUST -
WITHLABEL('ibmWebSphereMQMQ0P')
Your CA should provide you with a CA certificate, or multiple CA certificates. Unless RACF already contains them, every certificate must be copied to datasets in z/OS and added to RACF.
The RACDCERT ADD command will look something like the following. Where "CA Label" is a label describing the CA certificate. The label you use is not important to WMQ.
RACDCERT CERTAUTH -
ADD('MQ.RACD.DIGCERT.CERTAUTH.DER') -
TRUST WITHLABEL('CA Label')
The private certificate, and all CA certificates, need to be added to a Key Ring (this is also defined in RACF). This Key Ring will become the Key Repository for MQ0P.
The following RACF command defines a Key Ring, where PRODUSER is the User ID associated with the CHINIT started task for Queue Manager MQ0P.
RACDCERT ID(PRODUSER) ADDRING(MQ0PRING)
Connect all CA certificates, and MQ0P's personal certificate into the Key Ring using RACF commands as follows.
RACDCERT ID(PRODUSER) -
CONNECT(CERTAUTH LABEL('CA label') RING(MQ0PRING))
RACDCERT ID(PRODUSER) -
CONNECT(ID(PRODUSER) LABEL('ibmWebSphereMQMQ0P') RING(MQ0PRING))
The remaining actions to enable MQ0P to use SSL are detailed in section 4.Configuring the z/OS queue manager to use the certificate.
Note: This Queue Manager is MQ0P whereas that section refers to MQ0A
On Unix
You must read and apply 6. Setting up IKEYMAN to administer SSL certificates on Unix for this machine and Queue Manager, before you can run the following commands.
Be careful when using the commands in that section to use the name of this Queue Manager (QM_unixP) rather than QM_unix.
Change your working directory to the directory which will contain the files for the queue manager's Key Repository. The following command changes to the default Key Repository directory for a queue manager called QM_unixP.
cd /var/mqm/qmgrs/QM_unixP/ssl
Create a Key Repository for the queue manager. The following command creates a Key Repository with the default name 'key.kdb'.
gsk7cmd -keydb -create -db key.kdb -pw KEYPASS -stash
It is important that the file permissions of the key.* files created allow the WMQ queue manager to read the files, while not giving read access to other users. For example the files can be given u+rw permissions only, if administered by the 'mqm' user, or u+rw,g+rw permissions if administered by other members of the 'mqm' group.
Generate a certificate request from IKEYMAN and put a copy of the (not yet signed) certificate into the certreq.arm file. The label must be of the correct format, as described in Section 2.
gsk7cmd -certreq -create -db key.kdb -pw KEYPASS -label ibmwebspheremqqm_unixp -dn "CN=Personal Certificate for QM_unixP,OU=PROD-N,O=IBM,C=UK" -size 1024 -file certreq.arm
The certreq.arm file is ready to be sent to a Certification Authority, by way of whichever email system you choose to use. The certificate authority will sign the certificate and return it, along with the CA certificates required for that certificate.
This request will not have any Private Keys contained in the file, which makes this method very secure.
Note: The files returned may be in binary or ASCII format. I have assumed it is in ASCII format and that you detached them to CAcert.der and unixp.certb64 in the above directory.
Your CA should provide you with a CA certificate, or multiple CA certificates. These must all be added to the Key Repository of the queue manager (starting with the root CA certificate and working down the chain). The command below will add a CA certificate to the key repository, where "CAcert.der" is the file sent by the CA and placed in the same directory as the Key Repository, and "CA label" is a label describing the certificate. The label you use is not important to WMQ.
gsk7cmd -cert -add -db key.kdb -pw KEYPASS -label "CA label" -format ascii -trust enable -file CAcert.der
Once all CA certificates have been added, you can receive the signed personal certificate for the Queue Manager back into the Key Repository (where the private key has been kept safe). The following command receives a signed certificate back into the Key Repository.
gsk7cmd -cert -receive -file unixp.certbr64 -db key.kdb -pw KEYPASS -format ascii -label ibmwebspheremqqm_unixp -default_cert yes
The remaining actions to enable QM_unixP to use SSL are detailed in section 8. Configuring the Unix queue manager to use the certificate.
Be careful when using the commands in that section to use the name of this Queue Manager (QM_unixP) rather than QM_unix.
From reading section 2. Summary of SSL Certificate set-up for Queue Managers, you will see that all CA certificates used to sign personal certificates must be added to all key repositories.
11. Securely signing a certificate request from Unix using a z/OS CA certificate
If you are looking to set up an internal system using SSL certificates, you may not want to involve the expense of using an external Certification Authority. This section shows how you can use RACF (on z/OS) to sign certificate requests that you generated for Unix Queue Managers using the steps in Section 10. The secure way to gain an SSL certificate for a Production WMQ system.
For instructions on how to host a CA on a Windows or Unix machine see:
http://www.ibm.com/support/docview.wss?uid=swg21233897 for
As all certificates in your environment are signed by the same CA, your queue managers will trust that CA to validate the identity of other queue managers in your environment.
In this example, we will enable QM_unixP to communicate with any Queue Manager that is set up with a certificate signed by the same CA certificate (in this example label 'SQ00 CA'). This includes any other Unix, Windows and z/OS Queue Managers.
On unixP
The following commands take place on a Unix machine that we will call unixP. This machine hosts Queue Manager QM_unixP.
You must read and action 6. Setting up IKEYMAN to administer SSL certificates on Unix for this machine and Queue Manager, before you can run the following commands.
Be careful when using the commands in that section to use the name of this Queue Manager (QM_unixP) rather than QM_unix.
In Section 10 we described how to create a Key Repository for a Unix queue manager, create a certificate request and send it to a CA to be signed. For this Section we will generate a certificate request from IKEYMAN as follows.
Change directory to the location of the Key Repository.
cd /var/mqm/qmgrs/QM_unixP/ssl
Generate a certificate request and put a copy of the certificate into the certreq.arm file.
gsk7cmd -certreq -create -db key.kdb -pw KEYPASS -label ibmwebspheremqqm_unixp -dn "CN=Personal Certificate for QM_unixP,OU=PROD-N,O=IBM,C=UK" -size 1024 -file certreq.arm
You can now ftp the certificate request (in ASCII mode) to z/OS.
FTP ...
User Name: ....
Password: ********
quote site recfm=vb
cd 'MQ.RACD.DIGCERT'
put certreq.arm UNIXP.ARM
bye
Note: RACF may have difficulty reading your request if you did not specify the SITE FTP command. This causes hex '0D' to be inserted at the end of each line. To correct this edit the file on z/OS with the command Hex on and overtype. It should look like the example in section 10. The secure way to gain an SSL certificate for a Production WMQ system.
The following actions take place on the z/OS system.
To understand how to submit RACF commands, see section 14. Submitting RACF commands
The Certification Authority certificate on z/OS is defined as follows. See http://www.ibm.com/support/docview.wss?uid=swg27006987 for an explanation of a Certification Authority.
RACDCERT CERTAUTH GENCERT -
SUBJECTSDN(CN('CST CA SQ00') -
T('WMQ') -
OU('TEST') -
O('IBM') -
L('HURSLEY') -
SP('HAMPSHIRE') -
C('UK')) -
WITHLABEL('SQ00 CA')
Sign the Certificate request from unixP using the CA certificate in RACF. The user ID used here, TESTUSER provides an intermediate place to store the signed public certificate before it is transferred back to the Unix system where it will be used.
RACDCERT ID(TESTUSER) GENCERT( 'MQ.RACD.DIGCERT.UNIXP.ARM ' ) -
WITHLABEL('ibmwebspheremqqm_unixp')) -
SIGNWITH( CERTAUTH LABEL('SQ00 CA'))
The certificate is now in RACF so Export the certificate you have just signed from the TESTUSER profile, to a file for transfer back to the Unix system.
RACDCERT ID(TESTUSER) EXPORT (-
LABEL('ibmwebspheremqqm_unixp')) -
DSN('MQ.RACD.DIGCERT.UNIXP.CERTB64') -
FORMAT(CERTB64)
Also Export the signing CA certificate. This creates a DER file
RACDCERT CERTAUTH EXPORT (-
LABEL('SQ00 CA')) -
DSN('MQ.RACD.DIGCERT.SQ00CA.DER') -
FORMAT(CERTDER)
The following takes place on the unixP system.
You can now ftp the signed certificate (in ASCII mode) and the CA certificate (in Binary mode) to Unix from the appropriate directory.
cd /var/mqm/qmgrs/QM_unixP/ssl
FTP ...
User Name: ....
Password: ********
cd 'MQ.RACD.DIGCERT'
get UNIXP.CERTB64 unixp.certb64
bin
get SQ00CA.DER SQ00CA.der
bye
Firstly add the CA certificate to the key repository.
gsk7cmd -cert -add -db key.kdb -pw KEYPASS -label "SQ00 CA" -format binary -trust enable -file SQ00CA.der
You can now add the signed personal certificate to the key.kdb database using a command like the following.
gsk7cmd -cert -receive -file unixp.certb64 -db key.kdb -pw KEYPASS -format ascii -default_cert yes
The remaining actions to get QM_unixP using SSL are detailed in section 8. Configuring the Unix queue manager to use the certificate.
Be careful when using the commands in that section, to use the name of this Queue Manager (QM_unixP) rather than QM_unix.
On z/OS
There is no need to generate certificate requests from z/OS Queue Managers in cases where they are signed by a CA certificate on the same system. Certificates used on z/OS as the equivalent of the above certificate can be generated and signed by the CA certificate in RACF on that same image in a single command.
Create a personal certificate for QMGR MQ0A on z/OS and sign it with the same CA certificate label SQ00 CA. See http://www.ibm.com/support/docview.wss?uid=swg27006987 for an explanation of a personal certificate.
Note: The case and value of the label is important in SSL certificates. On z/OS the label is mixed case, see below.
RACDCERT ID(TESTUSER) GENCERT -
SUBJECTSDN(CN('Personal Certificate for MQ0A') -
T('QMGR') -
OU('TEST') -
O('IBM') -
L('HURSLEY') -
SP('HAMPSHIRE') -
C('UK')) -
WITHLABEL('ibmWebSphereMQMQ0A') -
SIGNWITH(CERTAUTH LABEL('SQ00 CA'))
Define a Key Ring (or Key Repository) for the z/OS Queue Manager. Where TESTUSER is the User ID associated with the CHINIT started task for Queue Manager MQ0A.
RACDCERT ID(TESTUSER) ADDRING(MQ0ARING)
Connect the CA certificate and MQ0A's personal certificate into the Key Ring.
RACDCERT ID(TESTUSER) CONNECT(CERTAUTH LABEL('SQ00 CA') RING(MQ0ARING))
RACDCERT ID(TESTUSER) -
CONNECT(ID(TESTUSER) LABEL('ibmWebSphereMQMQ0A') RING(MQ0ARING))
You will need to read and apply section 4. Configuring the z/OS Queue Manager to use the certificate.
This example has shown how to enable two Queue Managers to communicate using SSL. To enable other Unix Queue Managers to communicate, simply repeat the process outlined above for Unix Queue Managers for a new Queue Manager. Section 9. Extending the scenario to include another z/OS Queue Manager shows how to extend to include another Queue Managers on another z/OS system.
12. Other useful GSK7 Commands.
The following command changes the password on the key.kdb and causes it to expire in 90 days. If the -expire option is omitted, the password will not expire.
gsk7cmd -keydb -changepw -db key.kdb -pw KEYPASS -new_pw new_password -expire 90 -stash
To delete a certificate from the key.kdb.
For example, if you wish to exclude all messages from Queue Managers using a given CA..
gsk7cmd -cert -delete -db key.kdb -pw KEYPASS -label "SQ00 CA"
To delete the key.kdb file to start again.
gsk7cmd -keydb -delete -db key.kdb -pw KEYPASS -type cms
In a production environment, deleting a personal certificate or a Key Repository is a significant action. In a secure environment, the Key Repository is the only place where the private key for a personal certificate exists. If this private key is deleted, then the personal certificate is rendered useless. The private key cannot be recreated. Due to this, care should be taken when deleting certificates or certificate repositories.
13. Some useful RACF commands.
To list the CA certificates have been defined.
RACDCERT CERTAUTH LIST
List the personal certificates have been defined to user TESTUSER.
RACDCERT ID(TESTUSER) LIST
List the personal certificates have been defined to user TESTUSER in Key Ring MQ0ARING.
RACDCERT ID(TESTUSER) LISTRING(MQ0ARING)
Delete a specified CA certificate. Here is one you want to be VERY careful about its use. When you submit this you render useless all personal certificates that it has signed!
RACDCERT CERTAUTH DELETE(LABEL('SQ00 CA'))
Delete a specified personal certificate. This renders the personal certificate useless, but allows you to start again.
RACDCERT ID(TESTUSER) DELETE(LABEL('ibmWebSphereMQMQ0A'))
Delete the Key Ring MQ0ARING associated with user ID TESTUSER.
RACDCERT ID(TESTUSER) DELRING(MQ0ARING)
Refresh the certificates in the RACF Database. You will be prompted for this on z/OS 1.9 if you require your changes to be effective immediately.
SETROPTS RACLIST(DIGTCERT) REFRESH
14. Submitting RACF commands.
Note: To create digital certificates you will need the appropriate authority to issue the RACDCERT command, from your RACF System Administrator.
The RACF command RACDCERT is used to generate and manipulate digital certificates on z/OS. You can issue these commands in batch, for example using the following JCL.
//RACDSUB EXEC PGM=IKJEFT01,DYNAMNBR=20
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
RACDCERT ...
From TSO you can also submit the commands from the ISPF Command Shell (usually =6)
You can submit commands by prefixing them with TSO from ISPF.
Tip: Keep a record of what you have done! The best way to do this is by keeping a copy of what you did in a JCL library.
15. Background References.
For a more detailed explanation of what SSL is, click here http://www-306.ibm.com/software/webservers/httpservers/doc/v1319/9atssl.htm
For further details on how to use IKEYMAN, its' commands and platform specifics for platforms other than HP UX & AIX see the following site: http://www-306.ibm.com/software/webservers/httpservers/doc/v1319/9atikeyu.htm#HDRKMUEXPG.
GSKIT is a set of programmable interfaces that allow an application to be SSL enabled. Seehttp://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/rzab6/rzab6cgskit.htm for further details on using this API.
Thanks for sharing this informative blog. Those who want to become a certified unix professional reach FITA, Which offers best Unix Training Chennai with years of experienced professionals.
ReplyDeleteReally you have done great job,There are may person searching about that now they will find enough resources by your post
ReplyDeleteData Science Training in Chennai
Data science training in bangalore
Data science online training
Data science training in pune
Data science training in kalyan nagar
Data science training in Bangalore
Data science training in tambaram
Thank you a lot for providing individuals with a very spectacular possibility to read critical reviews from this site.
ReplyDeleteccna training in chennai
ccna training in bangalore
ccna training in pune
Well done! Pleasant post! This truly helps me to discover the solutions for my inquiry. Trusting, that you will keep posting articles having heaps of valuable data. You're the best!
ReplyDeletejava training in chennai | java training in bangalore
java online training | java training in pune
selenium training in chennai
selenium training in bangalore
This comment has been removed by the author.
ReplyDelete
ReplyDeleteThanks for your informative article, Your post helped me to understand the future and career prospects & Keep on updating your blog with such awesome article.
angularjs Training in bangalore
angularjs Training in electronic-city
angularjs Training in online
angularjs Training in marathahalli
ReplyDeleteHey, would you mind if I share your blog with my twitter group? There’s a lot of folks that I think would enjoy your content. Please let me know. Thank you.
AWS Training in Chennai |Best Amazon Web Services Training in Chennai
AWS Training in Rajaji Nagar | Amazon Web Services Training in Rajaji Nagar
Amazon Web Services Training in OMR , Chennai | Best AWS Training in OMR,Chennai
Selenium Training in Chennai | Best Selenium Training in Chennai
Selenium Training in Bangalore | Best Selenium Training in Bangalore
Thanks for splitting your comprehension with us. It’s really useful to me & I hope it helps the people who in need of this vital information.
ReplyDeletepython training in tambaram
python training in annanagar
python training in jayanagar
Great Article… I love to read your articles because your writing style is too good, its is very very helpful for all of us and I never get bored while reading your article because, they are becomes a more and more interesting from the starting lines until the end.
ReplyDeleteselenium training in electronic city | selenium training in electronic city | Selenium Training in Chennai | Selenium online Training | Selenium Training in Pune | Selenium Training in Bangalore
Very nice post here and thanks for it .I always like and such a super contents of these post.Excellent and very cool idea and great content of different kinds of the valuable information's.
ReplyDeleteangularjs Training in chennai
angularjs-Training in tambaram
angularjs-Training in sholinganallur
angularjs-Training in velachery
angularjs Training in bangalore
angularjs Training in bangalore
ReplyDeleteI have read so many articles and definitely this one is the best I have read. Thanks for uploading.
Selenium Training in Chennai
software testing selenium training
ios developer course in chennai
Digital Marketing Course in Chennai
Big Data Training in Chennai
French Classes in Chennai
Wonderful blog.
ReplyDeleteccna Training in Chennai
ccna certification in Chennai
ccna Training in Velachery
ccna course in Chennai
ccna Training institute in Chennai
ccna institute in Chennai
This is an excellant blog. Thanks for taking time to share this information. Waiting for more updates.
ReplyDeleteIELTS Tambaram
IELTS Coaching in Chennai Tambaram
IELTS Classes near me
IELTS Velachery
IELTS Training in Chennai Velachery
IELTS Training in Velachery
IELTS Coaching Centre in Velachery
Very nice topic thanks for posting
ReplyDeleteCCNA training in chennai
This is exceedingly helpful information, very good work. Thanks for sharing and let me wait for further updates.
ReplyDeleteData Science Course in Chennai
Data Science Training in Chennai
DevOps certification in Chennai
DevOps Training in Chennai
AWS Training in Chennai
AWS course in Chennai
Data Science Training in Velachery
Data Science Training in Tambaram
A good blog for the people who really needs information about this. Good work keep it up.
ReplyDeletefrenchtraining
Guest posting sites
calculatordemon
ReplyDeleteog youtube
ReplyDelete안전토토사이트
ReplyDeletehttps://vodafonecustomercarenumber.hatenablog.com
ReplyDeletehttps://vodafonecustomercarenumber.hatenablog.com
https://mpcustomercareno.blogspot.com
https://mpcustomercareno.blogspot.com
https://myairtelcustomercarenumber.blogspot.com
https://myairtelcustomercarenumber.blogspot.com
nice information....!
ReplyDeleteinplant training in chennai
inplant training in chennai
inplant training in chennai for it
brunei darussalam web hosting
costa rica web hosting
costa rica web hosting
hong kong web hosting
jordan web hosting
turkey web hosting
gibraltar web hosting
Really i appreciate the effort you made to share the knowledge. The topic here i found was really effective...
ReplyDeleteLooking for Training Institute in Bangalore , India. Softgen Infotech is the best one to offers 85+ computer training courses including IT software course in Bangalore, India. Also it provides placement assistance service in Bangalore for IT.
Best Software Training Institute in Bangalore
Thank you for sharing such a nice post!
ReplyDeleteStart your journey with Training Institute in Bangaloreand get hands-on Experience with 100% Placement assistance from Expert Trainers with 8+ Years of experience @eTechno Soft Solutions Located in BTM Layout Bangalore.
SAP Training in Bangalore
It’s really great information Thanks for sharing.
ReplyDeleteBest Training Institute in Bangalore BTM. My Class Training Bangalore training center for certified course, learning on Software Training Course by expert faculties, also provides job placement for fresher, experience job seekers.
Software Training Institute in Bangalore
very good post...!
ReplyDeleteinternship in chennai for ece students
internships in chennai for cse students 2019
Inplant training in chennai
internship for eee students
free internship in chennai
eee internship in chennai
internship for ece students in chennai
inplant training in bangalore for cse
inplant training in bangalore
ccna training in chennai
ReplyDeleteI'm looking for a few bugs in my post. But I think I should have someone look and point out it. DevOps Training in Bangalore | Certification | Online Course Training | DevOps Training in Hyderabad | Certification | Online Course Training | DevOps Training in Coimbatore | Certification | Online Course Training | DevOps Training in Online | Certification | Online Course Training
I have recently started a blog, the info you provide on this site has helped me greatly. Thanks for all of your time & work ExcelR Data Analytics Course
ReplyDeleteYou can't imagine what I am going to tell you. Our institution is offering you a CS executive classes and a free of cost CSEET classes and many more to explore. So please contact us or visit our website at https://uniqueacademyforcommerce.com/
ReplyDeleteAwesome blog. Thanks for sharing such a worthy information....
ReplyDeleteDevops Strategy
Why Devops is Important
Really nice blog. thanks for sharing
ReplyDeletepython training centre in chennai
best python institute in chennai
Great post. keep sharing such a worthy information
ReplyDeleteGerman Classes in Chennai
German Classes in Bangalore
German Classes in Coimbatore
Awesome blog. Thanks for sharing such a worthy information....
ReplyDeleteDigital Marketing Courses in Bangalore
Digital Marketing Course in Pune
This post is so interactive and informative.keep update more information...
ReplyDeleteAWS Training in Tambaram
AWS Training in Chennai
I would also motivate just about every person to save this web page for any favorite assistance to assist posted the appearance.
ReplyDeletebusiness analytics course in hyderabad
Great post. Thanks for sharing such a useful blog.
ReplyDeleteArtificial Intelligence Course in Velachery
Artificial Intelligence Course in Chennai
I read that Post and got it fine and informative. Please share more like that...
ReplyDeletefull stack developer course
Data Science course is for smart people. Make the smart choice and reach the apex of your career. Learn the latest trends and techniques from the experts.
ReplyDeletedata science course
Thanks for sharing the informative data. Keep sharing…
ReplyDeleteSwift Developer Certification Training in Chennai
Swift Online Course
Swift Developer Course in Bangalore
aqualudo
ReplyDelete