ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » .NET managed mode and CERTLABEL supported?

Post new topic  Reply to topic
 .NET managed mode and CERTLABEL supported? « View previous topic :: View next topic » 
Author Message
JosephGramig
PostPosted: Wed Dec 09, 2020 10:49 am    Post subject: .NET managed mode and CERTLABEL supported? Reply with quote

Grand Master

Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA

"Is an alternate queue manager certificate, specified on a SVRCONN CERTLABEL, supported when the connecting client is .NET using Managed mode?"

I'm not a .NET person but asking for them.
Back to top
View user's profile Send private message AIM Address
tczielke
PostPosted: Thu Dec 10, 2020 6:15 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

I would think it is supported based on this MQ manual doc.

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.2.0/com.ibm.mq.ref.con.doc/q113280_.htm

Quote:
Inbound channels (including RCVR, RQSTR, CLUSRCVR, unqualified SERVER, and SVRCONN channels) will only send the configured certificate if the IBM® MQ version of the remote peer fully supports certificate label configuration and the channel is using a TLS CipherSpec. If that is not the case, the queue manager CERTLABL attribute determines the certificate sent. This restriction is because the certificate label selection mechanism for inbound channels depends upon a TLS protocol extension that is not supported in all cases. In particular, Java™ clients, JMS clients, and all versions of IBM MQ prior to IBM MQ 8.0 do not support the required protocol extension and will only ever receive the certificate configured by the queue manager CERTLABL attribute, regardless of the channel-specific label setting.


Java clients do not support CERTLABL on the SVRCONN, but it does not mention .NET having this limitation. Probably best to confirm with IBM though.
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
JosephGramig
PostPosted: Fri Dec 11, 2020 9:16 am    Post subject: Reply with quote

Grand Master

Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA

Managed .NET clients cannot change the SNI which is how MQ specifies a per-channel certlabel.

While this article is titled "Connecting to a queue manager deployed in an OpenShift cluster" it discusses the SNI and managed .NET

The SNI is set to the Hostname if a hostname is supplied as the connection name, and the following conditions are met:

The .NET Client is in managed mode.

Note: I got this answer from somebody who knows.
Back to top
View user's profile Send private message AIM Address
fjb_saper
PostPosted: Mon Dec 14, 2020 4:45 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

in View of JEPS 114 https://openjdk.java.net/jeps/114 shouldn't IBM think of implementing it and removing that restriction from Java an JMS?


_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » .NET managed mode and CERTLABEL supported?
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.