MQ to support seamless certificate re-issue for AMS on z/OS

Currently MQ requires all MQ traffic to cease before replacing a certificate which will cause significant disruption to 24x7 operation. MQ AMS should be enhanced such that it can handle all the following scenarios: • Message consumer’s digital cert expiry date is to be extended and its keypair remains unchanged • Message consumer’s digital cert is reissued with new expiry date and new keypair. • The CA certs that signed the message consumer’s digital cert is to be reissued with new expiry date and new keypair of new key type (eg. ECC instead of RSA), and as a result all the application server/client certs may need to have a new private-public keypair of new key type (eg. ECC instead of RSA). For example the intermediate approved CA-cert will expire soon on 04/12/2025. Results from the recent testing the cert renewal process have shown that z/OS MQ AMS could only retrieve the personal cert from the keyring using the “BY DEFAULT” method. That is it can retrieve only the one that is marked as the keyring’s DEFAULT certificate. During the test, we found that z/OS MQ AMS could not use both the expiring and the renewed certs “BY SUBJECTDN” method. Where the subjectDN of the expiring cert is Usre.ID1 and that of the renewed cert is User.ID1.V2 and both of these certs were connected to the same keyring as personal certs. Therefore, I would like to propose the following enhancements to z/OS MQ AMS as follows: Stage 1: Change at the message consumer’s side: This stage can only take place after both the message producer’s and message consumer’s sides are running with the latest enhanced version of MQ AMS: At the message producer’s side: 1. After encrypting the message with a symmetric key and use the public key of the message consumer’s expiring cert to encrypt the symmetric key, MQ AMS should also use it to encrypt a literal constant (eg. “MQAMS”) and included its encrypted value together with the encrypted symmetric key in the PKCS#7 envelop of the MQ message. At the message consumer’s side: 2. The mainframe security administrator is to add the message consumer’s renewed cert with as its cert label and connected to the keyring as a personal cert in RACF or ACF2. 3. Enable MQ AMS policy to have a new multiple-value keyword called: CERTLABELS(,). The first value is the cert label of the message consumer’s expiring cert. The second is that of the message consumer’s renewed cert. The second value is optional, that is it is only required during the transition from the expiring cert to the renewed cert. 4. Before the encrypted symmetric key is decrypted, MQ AMS should retrieve the message consumer’s expiring cert from the keyring by using the value . Then MQ AMS should use its private key to decrypt the encrypted literal constant. • If the decrypted value is the same as the known literal constant (eg. “MQAMS”), then use the same private key to decrypt the encrypted symmetric key, and then use the symmetric key to decrypt the MQ message and producing WARNING message to the job log indicating , MQchannel-id, queue-name, …. is still using the message consumer’s expiring cert. • If the decrypted value is different from the known literal constant, then MQ AMS should retrieve the message consumer’s renewed cert from the keyring by using the value . MQ AMS should use the private key of the renewed cert to decrypt the encrypted literal constant. If the decrypted value is the same as the known literal constant, then continue normal processing. Otherwise, MQ AMS should produce an error message and abort the process. Stage 2: Change at both message consumer’s side and message producer’s side: At the message producer’s side: 1. Once it is confirmed that the MQ subsystem at the message consumer side’s is ready to handle both expiring and renewing cert, the system administrator can replace the expiring public-key cert of the message consumer with the renewed one in its keyring. At the message consumer’s side: 2. After being confirmed that the expiring cert of the message consumer has already been replaced with the renewed one from all message producer’s siders and the WARNING messages are no longer produced, remove the from the CERTLABELS keyword of the MQ AMS policy. 3. The Mainframe Security administrator removes the expiring cert from ACF2/RACF keyring. Notes: • The subjectDN remains unchanged for the above enhancement. Changing of subjectDN should be avoided if the Message Consumer‘s cert is also used for accessing other server applications that do perform client cert logonid mapping function. • The change does not have take place on all sides at the same time. However, to reduce number of WARNING messages in the joblog, it could be done in a coordinated way according to the above order within a certain timeframe (eg. 2 or 3 hours). • The enhancement should be implemented in such a away that the enhanced MQ AMS version should be backward compatible with the old MQ AMS version. That is, o MQ AMS (the enhanced version) at the message producer’s side only check the encrypted literal constant if it is included in the PKCS#7 envelop. o MQ AMS (the old version) at the message produce’s side ignores the encrypted literal constant if it is included in the PKCS#7 envelop. o If the new keyword CERTLABELS is not specified in a MQ AMS policy, then MQ AMS should retrieve the personal cert from the keyring using the “BY DEFAULT” method.