Anywhere you go, let me go too

關於部落格
對人海闊天空,做事仔細周密
----------------------
因為改了平台後...覺得不是很好用....所以有另外......(評估中)
http://blog.xuite.net/king119wang/myskills
  • 32543

    累積人氣

  • 2

    今日人氣

    0

    訂閱人氣

Adding SSL certificates to a mixed z/OS and Unix queue

Not all the steps may be required if you have existing certificates.

It extends the information held in http://www-1.ibm.com/support/docview.wss?uid=swg27006987, which covers SSL certificates from a purely z/OS perspective. It assumes that the reader is familiar with simple tasks in z/OS and Unix.

Content
This document contains the following sections
  1. Security Considerations
  2. Summary of SSL Certificate set up for Queue Managers
  3. Creating the certificates and Key Repository on z/OS
  4. Configuring the z/OS queue manager to use the certificate
  5. Transferring certificates to Unix
  6. Setting up IKEYMAN to administer SSL certificates on Unix
  7. Using the certificates on the Unix machine
  8. Configuring the Unix queue manager to use the certificate
  9. Extending the scenario to include another z/OS Queue Manager
  10. The secure way to gain an SSL certificate for your Production WMQ system
  11. Securely signing a certificate request from Unix using a z/OS CA certificate
  12. Some useful GSKIT commands
  13. Some useful RACF® commands
  14. Submitting RACF commands
  15. Background References


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:
  1. The personal certificate for that Queue Manager with the Private Key associated with that certificate.
  2. 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.
  3. A copy of the Certification Authority (CA) Certificate, used to sign its personal certificate.
  4. A copy of all CA certificates, used to sign all personal certificates (for all Queue Managers) that it will communicate with, using SSL. *
  5. 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-1.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-1.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 3 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:
  1. A key database (key.kdb) is a file that IKEYMAN uses to store one or more key pairs and certificates.
  2. A stash file is used by IKEYMAN to store encrypted database passwords.
  3. GSKIT is a set of programmable interfaces that allow an application to be SSL enabled.
  4. GSK7 is GSKIT version 7.
  5. 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.
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-1.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-1.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-1.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.
 
Related information
MQ SSL Certificates - Managing Secure Sockets Layer cer
 
 
 
 
其它參考URL:
Planning for SSL on the WebSphere MQ network

電子書WebSphere MQ Security (SC34-6588-01)

Connecting to external information sources with WebSphere MQ

HOW TO make certificates using
your own Certification Authority
and use them in WebSphere MQ


相簿設定
標籤設定
相簿狀態