Sorry, I forgot to specify the PEM file we used was for a commercial certificate and not a GroupWise generated certificate.
We have to setup GroupWise MTA (adminservice) with LDAP/S
Reason is, we need for some people Outlook Clients to access GroupWise mails and they like to have an system addressbook.
The Outlook Clients connect without any problems to GMS.
We run GWise on 18.4.1, a build from July
The documentation is a little bit outdated from the view what is to to in Outlook
Outlook does only connect via LDAP/S with trusted CAs, so we use the same certificate bundle, that we use for GWise SMTP/IMAP/CalDAV etc., it is an Wildcard certificate.
LDAP/S does not com up with our first certificate format, so we try other
A bundled pem (public cert, intermediate CA cert, private key) or an pfx certificate with full chain let the LDAP service start.
But LDAP is then no longer working, some interesting errors in the gwldap.log
We test the LDAP connection with LDAP browsers (Apache Directory Studio), ldapserach, openssl to see the certificate.
We switch back to the GWise created certificates and all connections work, except Outlook.
The Outllok error message said only, could not connect to server, also the debug log file on windows told us nothing more.
GWise client LDAP Addressbook connects with the warning that the certificate is unknown.
We open an case and the support engineer get the same result.
gwadminservice has a problem with java ssl libraries, especialy TLS
He created an defect.
The work a round to solve this, you must install the GWise Ca certificate, the MTA certificate in the right place of the certificate store of the windows box.
It works only, when we copy the certificates (both) in the " Trusted Root Certification Authorities", "trusted publishers" of the computer and the user, also the MTA certificate under "other, also computer and user store.
That is not funny, if not every workstation is in an Endpoint management.
Hope we got an updated version of gwadminservices that can handle new commercial certificates.
We have configured an LDAP server using a PEM file containing the primary cert and intermediate cert and have been able to connect without any problems. The PEM file loads without any errors and I am able to use ldapsearch to make an LDAPS connection without any problems. In our case I assigned the certificate to the MTA and then configured the LDAP server to use the MTA's certificate but it would behave the same if I assigned the certificate to the LDAP server.
One other item that needs to be checked is that the correct password for the key file was set when the certificate was assigned to either the MTA or LDAP server. Please also verify the format of the PEM file and make sure it is correct.
I will keep looking into this to see if any other ideas to check come up.
I was contacted about the issue above and have been waiting for feedback to some questions. The logs for the LDAP service I was given show there were errors trying to load the PEM file so I was wondering how the PEM file was created. The errors indicated the PEM file was invalid. The standard libraries we use normally handle PEM files without any problems so there might be an issue with that specific PEM file. We are still testing with different certificates to try and duplicate this problem.