You can try to add this part to your script " -e GWSOAP_SSL_VERIFY=off ". Maybe it helps ...

This will help ... in the way it disables SSL encryption.

The whole certificate management of GW is terrible. All internal connections should be SSL secured by default as default w/o a manual setting.

Hmm, it does not disable SSL but disables verification.

So it is just a bypass and there is some activity necessary in the background. GW SSL certs should contain the right IP address and DNS information.

Why do we have broken ssl information? Ip addresses have changed, server names have changed, certs have been created a long time ago. Enabling ssl within GW is really easy .. but some services need verification now. That's the tricky part ...

Have tried that Diethmar but get the same error.

I'm guessing the message is telling me there is an issue with the cert somewhere.  How would we go about starting to troubleshoot this?  I've tried with DNS names rather than IP addresses, have regenerated the certs for the MTA and POA, have rebooted etc but nothing helps.

@BM2EC - I agree, the documentation most certainly could be more comprehensive here......

Did you check the certificates in /opt/novell/certificates/<string>? openssl x509 -noout -text -in <certificate>.

First of all I would check ca.crt. It must be SHA256. Then all certs starting with admin*. Finally certs which have been configured via GW administration console.

Hi - after some searching found them in /opt/novell/groupwise/certificates.  How to determine the output though - looks like the ca.crt was generated by edirectory on this server but it does not say anything about SHA256?  Any more tips on this would be most helpful.

ah,  too old as it is clearly SHA1 on that last line.  time to rebuild that CA and all the certs under it.

As this is an OES server I'm guessing https://www.microfocus.com/documentation/open-enterprise-server/2023/oes_implement_lx/ipchange_edir-repair.html or is there more to it than that.  My past experience with certs tells me this is likely to be the start of a dive into a very long set of interconnected tasks!

Marcus Rhodes said:

My past experience with certs tells me this is likely to be the start of a dive into a very long set of interconnected tasks!

Welcome to Security,  oh so much fun

So step One:  why does your GroupWise need to be tied to anything but its own CA?  It can be self generated, and all the GW agents and bit only use it just fine for the most part.  Having any other ties are for external connections.

You should use the hostname (FQDN) instead of the IP number ( also set FQDN on the MTA in gwadmin),  this should be the same FQDN as the gwadmin/poa server has when "hostname -f" is done, also DNS must be setup correctly to have this hostname resolved to the right IP number of this server finaly the admin certificate for this gwadminservice and the POA certificate must have the same hostname and IP number in the SAN when you check the certificate. When all is matching and DNS is correct this will work.