I am wondering if anyone has any workarounds to make a production ready setup where an XMS client can connect using TLS from a non-Windows platform where TLS client authentication is enabled on the SVRCONN channel. The background is that the client certificate lookup for XMS (actually inherited from the base class) uses dotnet's standard library methods (I can provide more info if required) using managed mode, and since dotnet on Linux does not support FriendlyName in the certificate stores, the IBM standard solution for targetting the certificate and private key based on this field does not work - and in fact is silently ignored (e.g. default value ibmwebspheremq<user>). The certificate (and private key) picked by the client is silently an arbitrary one (the first picked from the user account's personal dotnet certificate store). Therefore the only way for this to work it seems is to force there to be only a single keystore file under $HOME/.dotnet/corefx/cryptography/x509stores/my/. In any environment where there may be multiple keystores for various uses, the only option would seem to be to override $HOME value to some carefully constructed directory containing only the single required keystore - not really a recommended or robust option (especially given that some dotnet calls seems to cause auto-generation of a local self-signed certificate set).
IBM support have finally confirmed to me that adjusting this behaviour requires an RFE and, believe it or not, that it is currently working as designed (despite this not being documented).
------------------------------
Adam Burgess
------------------------------