Unable to ping arssockd / load

[jsquizz]

Hi Gang,

We're using CMOD V10.5/Redhat/Oracle. We are having issues issuing :

Code: [Select]

arssockd -I instanceName -P
arssload -I instanceName -g AppGroup -u user -p password -g AppGroup -nvf fileName
Its failing with connection cannot be established.

We're able to successfully ping arssockd via -I serverName / localhost -P. We can also load via the same. Also - ICN is configured to hit this library server with SSL, and I see a successful login using SSL.

When I turn off SSL, we can issue arssockd -P -I instanceName, as well as load fine, client, etc.

Has anyone ever seen this? We're on 10.5.0.7 with the latest GSK.

Thanks all!

[jsquizz]

1) With SSL Turned OFF, and LDAP turned ON -> Works as expected
2) With SSL Turned ON, and LDAP with SSL turned ON -> Connection cannot be established to <Instance>
3) With SSL Turned ON, and LDAP turned OFF -> Connection cannot be established to <Instance>
4) With SSL and LDAP OFF -> Works as expected
5) With SSL Turned ON, and LDAP Turned OFF -> Connection cannot be established to <Instance>

Based on this, the correct settings will be scenario 2, LDAP with SSL.

The error message in the trace for scenario 2 is:

ERROR arsgskod.c(3567)ArcGSKOD_Connect:socket_init ssl_rc=403 ssl_str=GSK_ERROR_NO_CERTIFICATE

I can connect to CMOD via ICN with SSL turned on.

[jsquizz]

So, we did resolve this.

IBM support was fantastic in helping us with this. Lots of troubleshooting.

We had to recreate the key database.

gsk8capicmd_64 -cert -create -db "ondemand.kdb" -stashed -label "cmodcert" -dn "CN=some11.domain.here" -size 2048 -sigalg SHA256_WITH_RSA

Within ars.cfg - We set ARS_LDAP_PORT=636, and bam. Resolved. We took said keys and moved them to the respective clients and that resolved our issues.

I am no security expert but if I understand what we were told, there were some changes to the algorithm with the hash made in 10.5.0.7

[Ed_Arnold]

Thanks for posting the resolution

Ed

[jsquizz]

Thanks for posting the resolution

Ed

One lesson learned. We are using the S3 API's to connect to EMC.

We had that working. Then we implemented LDAP/SSL.

Our LDAP/SSL changes, unfortunately broke something with the EMC connection. Lesson learned, do LDAP/SSL first. ALWAYS