After I succeeded in getting TLS 1.3 to run on MQ midrange 9.2, I thought I would try it on z/OS. I had not used TLS on z/OS for about 10 years, so it was almost like coming to the topic with very rusty knowledge.
I searched the Knowledge centre and found no relevant hits – lots of hits which were not relevant. I eventually found an SSL related keyword, and this got me to the topic Working with SSL/TLS on z/OS. I think this is well documented. It covered all the things I had to do.
The remained of this post covers the bits not covered by the documentation.
Define SSLTASKS.
You need to define SSLTASKS to be able to use TLS on z/OS. See the comments here. I used
%CSQ9 ALTER QMGR SSLTASKS(5)
You need to restart the CHINIT if you change the value of SSLTASKS.
Set up the keyring for the queue manager.
See here. This post show how to create the keyring and import a CA from z/OS, and import a CA from a Linux system.
If you alter the keyring or certlabl you just need a refresh security type(SSL) command to pick up the changes.
Defining the channel
I tried to define the channel, as this failed for security reasons, I’ve given the RACF setup I had to do.
In this section I defined the specific commands for example DEFINE.CHANNEL. I could have defined DEFINE.* to allow all define commands.
I used a channel called TLS, and define the resource CSQ9.CHANNEL.TLS* to allow my ID to define TLS, TLS1 etc
The command %CSQ9 DEF CHL(TLS) CHLTYPE(SVRCONN) gave me
ICH408I USER(CSQOPR ) GROUP(SYS1 ) NAME(COLIN PAICE ) 167
CSQ9.DEFINE.CHANNEL CL(MQCMDS )
WARNING: INSUFFICIENT AUTHORITY – TEMPORARY ACCESS ALLOWED
ACCESS INTENT(ALTER ) ACCESS ALLOWED(NONE )
I used the RACF commands in a batch job.
/* RDELETE MQCMDS CSQ9.DEFINE.CHANNEL
RDEF MQCMDS CSQ9.DEFINE.CHANNEL UACC(NONE)
PERMIT CSQ9.DEFINE.CHANNEL CLASS(MQCMDS ) –
ID(COLIN,IBMUSER) ACCESS(ALTER )
I also set up CSQ9.DELETE.CHANNEL and CSQ9.ALTER.CHANNEL in a similar way, so my userid could maintain the channels.
I refreshed MQ security %CSQ9 refresh security to pick up the changes.
I reissued the command %CSQ9 DEF CHL(TLS ) CHLTYPE(SVRCONN) and got
ICH408I USER(COLIN ) GROUP(SYS1 ) NAME(COLIN PAICE )
CSQ9.CHANNEL.TLS CL(MQADMIN )
PROFILE NOT FOUND – REQUIRED FOR AUTHORITY CHECKING
ACCESS INTENT(ALTER ) ACCESS ALLOWED(NONE )
I used the RACF commands in a batch job.
/* RDELETE MQADMIN CSQ9.CHANNEL.TLS*
RDEF MQADMIN CSQ9.CHANNEL.TLS* UACC(NONE) WARNING
PERMIT CSQ9.CHANNEL.TLS* CLASS(MQADMIN) –
ID(COLIN,IBMUSER) ACCESS(ALTER )
SETROPTS RACLIST(MQADMIN) REFRESH
I issued the commands
%CSQ9 refresh security
%CSQ9 DEF CHL(TLS ) CHLTYPE(SVRCONN)
And successfully defined the channel.
I changed the cipher spec.
I selected a cipher spec from the list.
%CSQ9 alter chl(TLS) chltype(SVRCONN) SSLCIPH(ECDHE_RSA_AES_128_CBC_SHA256)
When I started the channel I got
CSQX631E … CSQXRESP Cipher specifications differ, channel TLS local=ECDHE_RSA_AES_128_CBC_SHA256 remote=TLS_RSA_WITH_AES_256_GCM_SHA384
connection 10.1.0.2 (10.1.0.2)
This was clear; I love clear messages.
I decided to change the z/OS end
%CSQ9 alter chl(TLS) chltype(SVRCONN) SSLCIPH(TLS_RSA_WITH_AES_256_GCM_SHA384 )
and the client connected successfully.
With MQ 9.2 I could (and did) change this to
%CSQ9 alter chl(TLS) chltype(SVRCONN) SSLCIPH(ANY_TLS12)
and the client worked successfully. The ANY_TLS12. provides a wide list of supported cipher specifications, includes TLS_RSA_WITH_AES_256_GCM_SHA384 and ECDHE_RSA_AES_128_CBC_SHA256.
When I am ready to support TLS 1.3 I will use ANY_TLS12_OR_HIGHER and ANY_TLS13_OR_HIGHER.
Connect a client to it!
I had had my client connect to a midrange queue manager, so I had working client environment. See here for the journey.
I created a .json file for the CCDT connection to z/OS. I specified
{ "channel": [{ "name": "TLS", "clientConnection": { "connection": [{ "host": "10.1.1.2", "port": 1414 }], "queueManager": "CSQ9" }, "transmissionSecurity": { "cipherSpecification": "ANY_TLS12", "certificateLabel": "rsaca256_client", "certificatePeerName": "" }, "type": "clientConnection" }] }
When it connected I got messages
+CSQX511I %CSQ9 CSQXRESP Channel TLS started connection 10.1.0.2
ICH408I USER(COLINPAI) GROUP( ) NAME(??? )
LOGON/JOB INITIATION – USER AT TERMINAL NOT RACF-DEFINED
IRR012I VERIFICATION FAILED. USER PROFILE NOT FOUND.
+CSQX512I %CSQ9 CSQXRESP Channel TLS no longer active connection 10.1.0.2
COLINPAI came from the userid on the Linux machine (colinpaice) upper cased and truncated. This id will be flowed and used as the MCAUSER if you don’t set it to anything else, using CHLAUTH for example (Thanks to Morag for this information).
Enable chlauth
To be able to map from the DN in a certificate to a z/OS userid you have to use MQ CHLAUTH. See Mapping a client user ID to an MCAUSER user ID.
Check it is enabled at the queue manager level and enable it it needed.
%CSQ9 DIS QMGR CHLAUTH
%CSQ9 ALTER QMGR CHLAUTH(ENABLED)
Define a mapping from certificate to userid
I used
//S1 EXEC PGM=CSQUTIL,PARM='CSQ9' //STEPLIB DD DSN=COLIN.MQ921.SCSQLOAD,DISP=SHR // DD DSN=COLIN.MQ921.SCSQANLE,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSIN DD * COMMAND DDNAME(COMMAND) //COMMAND DD * SET CHLAUTH('TLS') + TYPE(SSLPEERMAP) SSLPEER('O="cpwebuser"') + ACTION(REPLACE) + MCAUSER(ADCDD ) CHCKCLNT(ASQMGR) /*
This says for channel TLS, take the Organisation(O=..) from the certificate, and if it is cpwebuser then set the ID to ADCDD.
Check it works
Once the channel had started I used
%CSQ( DIS CHS(TLS)
it displayed the following, where I have removed lines which are not relevant to TLS and added some comments
- CHSTATUS(TLS)
- CHLTYPE(SVRCONN)
- …
- SECPROT(TLSV12) – this is the level of the protocol
- SSLCERTI(CN=SSCARSA1024,OU=CA,O=SSS,C=GB)- this is the DN of the issuer of the SSLPEER certificate (below)
- SSLCERTU(START1) – the IBM documentation says “The local user ID associated with the remote certificate.” I dont know where this comes from.. how to change it, or where it is used.
- SSLCIPH(TLS_RSA_WITH_AES_256_GCM_SHA384) – The negotiated cipher spec
- SSLRKEYS(0) -The number of successful TLS key resets.
- SSLKEYTI() -The time on which the previous successful TLS secret key was reset. The secret key has not been reset
- SSLKEYDA() -The date on which the previous successful TLS secret key was reset. The secret key has not been reset
- SSLPEER(SERIALNUMBER=01:90,CN=rsaca256,O=cpwebuser,C=GB, UNSTRUCTUREDNAME=openssl_ca_user_cnf.keyAgreement2, UNSTRUCTUREDNAME=localhost, UNSTRUCTUREDADDRESS=127.0.0.1) . This is information from the certificate at the remote end.
- …
- MCAUSER(ADCDD) – This is the userid (set by the CHLAUTH above) used by this channel.
- LOCLADDR(10.1.1.2(1414)) – This is the address the connection came in from. This value will be different it you have different IP stacks and different listener ports.
I suspect COLINPAI was a truncated (and uppercased) version of your client machine logged on user id? This will be flowed and used as the MCAUSER if you don’t set it to anything else using CHLAUTH for example.
LikeLike
Yes – you are right it is my ID. I’ll update my post – thank you
LikeLike