| Author | 
		  Message
		 | 
		
		  | lfrestrepog | 
		  
		    
			  
				 Posted: Fri Jun 18, 2021 5:42 am    Post subject: rfhutil - connect using a channel with SSLPEERMAP | 
				     | 
			   
			 
		   | 
		
		
		   Novice
 
 Joined: 08 Jul 2014 Posts: 22
  
  | 
		  
		    
			  
				Hello, good day.
 
 
We have a few queue managers with server channels (SVRCONN) setup to require SSL authentication and using SSLPEERMAP authentication records. I'm trying to connect with rfhutil, so I filled the connection parameters according to the manual:
 
 
- Certificate Store Location: Path to my CMS keystore (just the stem)
 
- SSL: Check
 
- SSL Cipher Algorithm: TLS_RSA_WITH_AES_128_CBC_SHA256 (it matches my channel definition)
 
 
I did try a few other settings after the first failure to connect, anyway the error message is consistently:
 
   
	| Quote: | 
   
  
	| 18.03.51 2393 SSL unable to initialize - check SSL parms | 
   
 
 
 
On the queue manager error log we get the following:
 
 
   
	| Code: | 
   
  
	
 
06/03/21 12:07:15 - Process(32571694.3779) User(mqm) Program(amqrmppa)
 
                    Host(devhost) Installation(Installation3)
 
                    VRMF(9.2.0.0) QMgr(DEVQMGR)
 
                    Time(2021-06-03T17:07:15.941Z)
 
                    RemoteHost(10.18.140.175)
 
                    ArithInsert1(406)
 
                    CommentInsert1(????)
 
                    CommentInsert2(gsk_secure_soc_read)
 
 
AMQ9638E: SSL communications error for channel '????'.
 
 
EXPLANATION:
 
An unexpected SSL communications error occurred for a channel, as reported in
 
the preceding messages. The channel is '????'; in some cases its name cannot be
 
determined and so is shown as '????'. The channel did not start.
 
ACTION:
 
Investigate the problem reported in the preceding messages. Review the local
 
and remote console logs for reports of network errors. Correct the errors and
 
restart the channel.
 
----- amqccisa.c : 10873 ------------------------------------------------------
 
06/03/21 12:07:15 - Process(32571694.3779) User(mqm) Program(amqrmppa)
 
                    Host(devhost) Installation(Installation3)
 
                    VRMF(9.2.0.0) QMgr(DEVQMGR)
 
                    Time(2021-06-03T17:07:15.941Z)
 
                    CommentInsert1(????)
 
                    CommentInsert2(32571694)
 
                    CommentInsert3(10.18.140.175)
 
 
AMQ9999E: Channel '????' to host '10.18.140.175' ended abnormally.
 
 
EXPLANATION:
 
The channel program running under process ID 32571694 for channel '????' ended
 
abnormally. The host name is '10.18.140.175'; in some cases the host name
 
cannot be determined and so is shown as '????'.
 
ACTION:
 
Look at previous error messages for the channel program in the error logs to
 
determine the cause of the failure. Note that this message can be excluded
 
completely or suppressed by tuning the "ExcludeMessage" or "SuppressMessage"
 
attributes under the "QMErrorLog" stanza in qm.ini. Further information can be
 
found in the System Administration Guide.
 
 | 
   
 
 
 
I also use MQ Explorer with the same certificates and it works, so I believe the configuration on the queue manager is fine. I also believe my keystore is fine, because I can list the certificates using gsk8capicmd_64 (with -stashed option).
 
 
We have IBM MQ v9.2 on AIX (if that's relevant at all).
 
 
Any hints of what else to check or try would be very appreciated.
 
 
Thanks. _________________ --
 
Luis Fernando Restrepo Gutiérrez | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | exerk | 
		  
		    
			  
				 Posted: Fri Jun 18, 2021 5:53 am    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		    Jedi Council
 
 Joined: 02 Nov 2006 Posts: 6339
  
  | 
		  
		    
			  
				rfhutil, or rfhutilc? _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | lfrestrepog | 
		  
		    
			  
				 Posted: Fri Jun 18, 2021 6:01 am    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		   Novice
 
 Joined: 08 Jul 2014 Posts: 22
  
  | 
		  
		    
			  
				right, I meant rfhutilc.
 
 
(although I did try rfhutil out of desperation, with environment variable MQ_CONNECT_TYPE=CLIENT) _________________ --
 
Luis Fernando Restrepo Gutiérrez | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | exerk | 
		  
		    
			  
				 Posted: Fri Jun 18, 2021 6:51 am    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		    Jedi Council
 
 Joined: 02 Nov 2006 Posts: 6339
  
  | 
		  
		    
			  
				How are you specifying the connection details to rfhutilc? _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | markt | 
		  
		    
			  
				 Posted: Fri Jun 18, 2021 7:40 am    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		    Knight
 
 Joined: 14 May 2002 Posts: 512
  
  | 
		  
		    
			  
				I'd expect something to be in the client-side error logs too. 
 
 
And I'd not be surprised to find you've not got the CA certs associated with the qmgr's cert installed in the kdb.
 
 
Explorer working is useful to know that the qmgr is ok, but it uses a different keystore on the client side. so you can't verify anything about the kdb contents. | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | exerk | 
		  
		    
			  
				 Posted: Fri Jun 18, 2021 8:15 am    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		    Jedi Council
 
 Joined: 02 Nov 2006 Posts: 6339
  
  | 
		  
		    
			  
				
   
	| markt wrote: | 
   
  
	I'd expect something to be in the client-side error logs too. 
 
 
And I'd not be surprised to find you've not got the CA certs associated with the qmgr's cert installed in the kdb.
 
 
Explorer working is useful to know that the qmgr is ok, but it uses a different keystore on the client side. so you can't verify anything about the kdb contents. | 
   
 
 
Not one of my finest moments - forgetting that MQ Explorer uses a jks key store and not a kdb    _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | lfrestrepog | 
		  
		    
			  
				 Posted: Fri Jun 18, 2021 9:14 am    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		   Novice
 
 Joined: 08 Jul 2014 Posts: 22
  
  | 
		  
		    
			  
				About the CMS keystore, I imported all keys from my working JKS store following this guide: https://www.ibm.com/docs/en/ibm-mq/9.2?topic=wsalw-importing-personal-certificate-into-key-repository-aix-linux-windows
 
 
So I would expect all server certificates to be present in my CMS store (or have my connection fail with the JKS store too). Anyway, I did list the certificates in my store (using 
   
	| Code: | 
   
  
	| gsk8capicmd_64 -cert -list all -db "d:\workspace\ssl mq\mq_qa.kdb" -stashed | 
   
 
) and I see all the required certificates there (didn't check any of their fingerprints or details though).
 
 
There are certificate related errors in the client logs:
 
 
   
	| Code: | 
   
  
	
 
18/06/2021 11:53:28 - Process(5276.1) User(lfrgutie) Program(rfhutilc.exe)
 
                      Host(dev) Installation(Installation1)
 
                      VRMF(9.2.0.2)
 
                      Time(2021-06-18T16:53:28.396Z)
 
                      CommentInsert1(Windows 10 Enterprise x64 Edition, Build 9200 (MQ Windows (x64 platform) 32-bit))
 
                      CommentInsert2(C:\Program Files\IBM\MQ (Installation1))
 
                      CommentInsert3(9.2.0.2 (p920-002-210312))
 
                     
 
AMQ6287I: IBM MQ V9.2.0.2 (p920-002-210312).
 
 
EXPLICACIÓN:
 
Información del sistema IBM MQ: 
 
Información de host:- Windows 10 Enterprise x64 Edition, Build 9200 (MQ Windows
 
(x64 platform) 32-bit) 
 
Instalación        :- C:\Program Files\IBM\MQ (Installation1) 
 
Versión            :- 9.2.0.2 (p920-002-210312)
 
ACCIÓN:
 
Ninguna. 
 
----- amqxeida.c : 6604 -------------------------------------------------------
 
18/06/2021 11:53:28 - Process(5276.1) User(lfrgutie) Program(rfhutilc.exe)
 
                      Host(dev) Installation(Installation1)
 
                      VRMF(9.2.0.2)
 
                      Time(2021-06-18T16:53:28.388Z)
 
                      CommentInsert1([Class=]GSKVALMethod::X509[Issuer=]CN=CORPROOTCABC[#=]4c0000000259cd3d3487110e56000000000002[Subject=]CN=CORPISSUINGCABC,DC=AMBIENTESBC,DC=LAB[Class=]GSKVALMethod::X509[Issuer=]CN=CORPISSUINGCABC,DC=AMBIENTESBC,DC=LAB[#=]1b00021e86f04)
 
                      CommentInsert2(gsk_attribute_get_buffer - GSK_UNKNOWNREVOCATIONSTATUS_SUBJECT)
 
                      CommentInsert3(ADMINS.SVRCONN)
 
                     
 
AMQ9716E: La comprobación del estado de revocación del certificado SSL remoto
 
ha fallado para el canal 'ADMINS.SVRCONN'.
 
 
EXPLICACIÓN:
 
IBM MQ no ha podido determinar el estado de revocación del certificado SSL
 
remoto por uno de los motivos siguientes: 
 
(a) El canal no ha podido contactar con ninguno de lo servidores CRL o
 
  programas de respuesta OCSP para el certificado. 
 
(b) Ninguno de los programas de respuesta OCSP contactados conoce el estado de
 
  revocación del certificado. 
 
(c) Se ha recibido una respuesta OCSP, pero la firma digital de la respuesta no
 
  se ha podido comprobar. 
 
 
Los detalles del certificado en cuestión son
 
'[Class=]GSKVALMethod::X509[Issuer=]CN=CORPROOTCABC[#=]4c0000000259cd3d3487110e56000000000002[Subject=]CN=CORPISSUINGCABC,DC=AMBIENTESBC,DC=LAB[Class=]GSKVALMethod::X509[Issuer=]CN=CORPISSUINGCABC,DC=AMBIENTESBC,DC=LAB[#=]1b00021e86f04'.
 
 
 
El nombre del canal es 'ADMINS.SVRCONN'. En algunos casos, el nombre de canal
 
no se puede determinar y, por lo tanto, se muestra como '????'. El canal no se
 
ha iniciado. 
 
 
IBM MQ no permite que el canal empiece a menos que se pueda determinar el
 
estado de revocación del certificado.
 
ACCIÓN:
 
Si el certificado contiene una extensión AuthorityInfoAccess, asegúrese de que
 
el servidor OCSP nombrado en la extensión de certificado esté disponible y bien
 
configurado. 
 
 
Si el certificado contiene una extensión CrlDistributionPoint, asegúrese de que
 
el servidor CRL nombrado en la extensión de certificado esté disponible y bien
 
configurado. 
 
 
Si ha especificado servidores CRL o OCSP en IBM MQ, compruebe que dichos
 
servidores estén disponibles y bien configurados. 
 
 
Asegúrese de que el depósito de claves locales tenga los certificados SSL
 
necesarios para verificar la firma digital de la respuesta del servidor OCSP. 
 
----- amqccisa.c : 9109 -------------------------------------------------------
 
 | 
   
 
 
 
I also tried to disable OCSP/CRL checking, adding the following to my mqclient.ini
 
 
   
	| Code: | 
   
  
	
 
SSL:
 
   AllowTLSV13=TRUE
 
   OCSPAuthentication=OPTIONAL
 
   OCSPCheckExtensions=NO
 
   CDPCheckExtensions=NO
 
 | 
   
 
 
 
But the connection still fails with same error messages    
 
 
Any ideas or hints are much appreciated.
 
 
Thanks. _________________ --
 
Luis Fernando Restrepo Gutiérrez | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | exerk | 
		  
		    
			  
				 Posted: Fri Jun 18, 2021 9:28 am    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		    Jedi Council
 
 Joined: 02 Nov 2006 Posts: 6339
  
  | 
		  
		    
			  
				So you are setting the location of the key store using the MQSSLKEYR environment variable? Why not set it in the SSLKeyRepository stanza of mqclient.ini file?
 
 
I'm assuming you're using a CCDT, and if so have you tried using amqsputc to cut-out test whether you can connect? _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | lfrestrepog | 
		  
		    
			  
				 Posted: Fri Jun 18, 2021 10:44 am    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		   Novice
 
 Joined: 08 Jul 2014 Posts: 22
  
  | 
		  
		    
			  
				So, I just tried amqsputc as suggested by exerk and it did work fine. I'm using the following environment variables: MQCHLTAB, MQCHLLIB, MQ_CONNECT_TYPE, MQSSLKEYR and MQCERTLABL.
 
 
But I'm not sure how to set my connection up in rfhutil (or rfhutilc) to use a CCDT, is there any reference manual?
 
 
Anyway, that test with amqsputc shows that the CMS store is fine, and the problem is now narrowed down to my lack of expertise with rfhutil  
 
 
Thanks. _________________ --
 
Luis Fernando Restrepo Gutiérrez | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | lfrestrepog | 
		  
		    
			  
				 Posted: Fri Jun 18, 2021 11:23 am    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		   Novice
 
 Joined: 08 Jul 2014 Posts: 22
  
  | 
		  
		    
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | RimRim | 
		  
		    
			  
				 Posted: Wed Jan 18, 2023 3:56 am    Post subject:  | 
				     | 
			   
			 
		   | 
		
		
		   Newbie
 
 Joined: 18 Jan 2023 Posts: 5
  
  | 
		  
		    
			  
				| Did u find it resolved. Am facing the exact same issue while trying to connect via rfhutilc | 
			   
			 
		   | 
		
		
		  | Back to top | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | 
		    
		   |