Hi Markus,

I missed a bit that you try only client to server at the moment. This is
pretty straightforward. Here's a snippet from the dsmserv.opt of our
7.1.4 server:

TCPPort 1500
SSLTCPPORT 1502
TCPADMINPort 1501
SSLTCPADMINPort 1503
SSLTLS12 YES
ADMINONCLIENTPORT       NO

The dsm.sys for the corresponding client has:

  TCPPort            1502
  TCPAdminport       1503
  SSL                Yes

Besides, you just have to import the cert256.arm into the client's
keyring and you're ready to go.

Some of these settings are specific to our setup. If you don't use
'ADMINONCLIENTPORT NO', you don't need a 'TCPAdminport' setting on the
client.

And yes, I know that there is a bug in the TLS1.2 implementation, so the
'SSLTLS12 YES' setting should not be used in production environments at
the moment until IBM gets the GSKit error fixed. (We use it just in our
test environment.)

Regards,

    Bjoern


> Thanks David, Bjoern for the great hints!
> 
> We are testing the self-signed certificates created by the server instance,
> so at this stage, no third-party certificate is involved, using the dsmadmc
> native commandline (no hub-server, no oc, no server-to-server, all down to
> absolute basics. Using gskit and following the instructions, it works just
> fine with the 128bit certificate cert.arm, but will not connect with the
> cert256.arm. Test with TSM Server 6.3.3 on SUN shows the same behaviour. Am
> I maybe just missing some obvious settings on the TSM Server side?
> 
> Kind regards,
> Markus
> 


-- 
Björn Rackoll
Universität Hamburg
Regionales Rechenzentrum
Zentrale Dienste
Schlüterstr. 70
20146 Hamburg
Tel.: +49 (0)40 42838 - 63 11
Fax: +49 (0)40 42838 - 62 70
Mobil: +49 (0)172 427 0301
E-Mail: backup AT mailman.rrz.uni-hamburg DOT de