92.4 Certificate Verification

GroupWise uses certificate verification to make sure that the connection is made to the correct server. GroupWise clients and agents check to make sure the certificate has a date that is currently valid and that the Subject Alternative Name (SAN) match either the DNS or IP address that it is connected to.

To prevent issues with certificate verification, we recommend the following actions:

  • Create your certificates with the Fully Qualified Domain Name (FQDN) and not a short server name.

  • GroupWise Agents should be set up to use DNS instead of IP address.

    IMPORTANT:Ensure if you change the Agent host name from IP address to DNS that you check to verify the startup switches in the Agent (POA, MTA, GWIA) startup files are not overriding those changes.

  • Your DNS should be configured for reverse lookup. This means both nslookup and ping should resolve from FQDN to IP address. Wildcard certificates can be used if reverse lookup is configured properly.

IMPORTANT:If you are using GroupWise generated certificates, make sure they were created after GroupWise 2014.0. Certificates created in GW 2014.0 and earlier versions do not pass certificate verification.

Troubleshooting information is provided in the sections below:

92.4.1 Troubleshooting Certificates using openssl Commands

Below are some of the common errors you might discover using the openssl Command Line tool:

  • Certificate is not yet valid

  • Certificate has expired

  • Self-signed certificate is missing CA (This requires a bundle certificate)

  • Issuer certificate is not found locally

  • Subject and issuer mismatch

  • Invalid CA (certificate authority)

To use the openssl tool, first run the client connect command followed by the certificate inspect command.

Client connect command

Run the following command:

openssl s_client –connect <address:port> -CAfile <Path to CA file in PEM format>

This command should return the server certificate. Look for and verify errors in the results.

NOTE:You will not have a CA file if the certificate is self-signed. If you leave off the CAFile option, the default certificate bundle will be used. For example: /etc/ssl/ca-bundle.pem

Certificate inspect command

Run the following command:

openssl x509 –in <certificate> -noout –text

Look for the validity period and for Subject Alternate Names.

92.4.2 Common Issues with Certificate Verification

The following issues are the most common problems we have seen with certificate verification:

Certificates were created using a short server name

Example: server53 was used instead of server53.acme.com

Solution: Fix the network name for the server and regenerate or obtain new certificates.

Certificates were created using the shipped version of GroupWise 2014.0

Certificates are malformed. A fix to this was made available a few months after the initial release.

Solution: Regenerate your GroupWise generated certificates.

Certificates have expired

Solution: Regenerate or obtain new certificates.

Error 8931 is produced in the POA, MTA, or GW IA log file

Example: “Error: [8931] Site certificate hostname does not match connection (server7.acme.com)”

NOTE:When seeing this error, it is important to know what is the target server.

  • If the message is on the POA, the certificate on the target is invalid. Targets can include any of the following:

    • MTA

    • DVA

    • Calendar Publishing Host

    • GMS Server

    • The POA itself

    • Other POAs (during user moves)

  • If the message is on the MTA, the certificate on the target POAs, MTAs, or GWIAs is invalid.

  • If the message is on the GWIA, the certificate on the target is invalid on any of the following:

    • MTA

    • External target host sites

    • POA during the IMAP connection

Solution: Error 8931 indicates that the SSL certificate of the target server does not have the valid SAN (Subject Alternative Name). Regenerate or obtain new certificates using the valid SAN for the target server.

NOTE:The easiest immediate solution is to add the switch –sslCertErrorOverride on Linux or /sslCertErrorOverride on Windows in the agent’s startup file. With this switch, the agents will ignore the error and issue the warning messages. Administrators can then take the time to fix all the certificate problems.

Error 8935 is produced in the POA, MTA, or GWIA log file:

Example: “Error: [8935] Site certificate failed the validity criteria (server7.acme.com)”

NOTE:When seeing this error, it is important to know what is the target server.

  • If the message is on the POA, the certificate on the target is invalid. Targets can include any of the following:

    • MTA

    • DVA

    • Calendar Publishing Host

    • GMS Server

    • The POA itself

    • Other POAs (during user moves)

  • If the message is on the MTA, the certificate on the target POAs, MTAs, or GWIAs is invalid.

  • If the message is on the GWIA, the certificate on the target is invalid on any of the following:

    • MTA

    • External target host sites

    • POA during the IMAP connection

Solution: Error 8935 indicates that the certificate of the target server is either expired or it is not ready to be used. Regenerate or obtain new certificates with a valid date range and use the correct SAN.

NOTE:The easiest immediate solution is to add the switch –sslCertErrorOverride on Linux or /sslCertErrorOverride on Windows in the agent’s startup file. With this switch, the agents will ignore the error and issue the warning messages. Administrators can then take the time to fix all the certificate problems.

The DVA shows as offline in web browser POA Configuration tab or you cannot access it via https://<DVA_server_name>:8301

If certificates were regenerated in your GroupWise system, you will need to make sure your DVA is pointing to the correct certificates. For example:

  1. Launch GroupWise Admin > System > Document Viewer Agents, and select the DVA. Verify that Enable SSL is selected.

  2. Edit your DVA startup file as follows:

    Make sure the following switches are enabled and are pointing to the correct certificate file and key. It is advisable to use double quotes (“”) around the path and filename for the certificate and key. For example: --sslCert "/opt/novell/groupwise/certificates/<system GUID>/certificate.crt"

    --httpssl
    --sslCert
    --sslKey
    --sslKeyPassword
    --httpuser
    --httppassword
  3. Restart the gwdva. For information, see Putting DVA Configuration Changes into Effect.

Login to GroupWise Admin fails

Solution: Recreate the Admin certificate using the following command:

gwadminutil certinst -a <admin name> -p <password> -ca <primary domain host name>:<admin port> -db <path to domain>

Wildcard certificate validation fails

Solution: Make sure the reverse DNS lookup and forward DNS lookup are enabled on the server's DNS. Wildcard host names are supported, but only the matching level. For example:

*.acme.com matches domain1.acme.com and lab.acme.com, but not subdomain.domain1.acme.com, nor acme.com

Windows Client user receiving a prompt asking if the certificate is trusted (new install)

Possible cause: A connection from the GroupWise Windows Client returned a name mismatch on the POA certificate. This is expected if an external C/S connection is configured to see a certificate host name that does not at all match the name that was used to request the connection.

Solution: In this situation, each Windows Client user should Accept the certificate trust.

Login to GroupWise Admin fails with Error “Domain server is not trusted. If you trust this server, add the server certificate to the trust store.”

Possible cause: The certificate is expired.

Solution: Check for errors in gwadmin-console.log and gwadmin-service.log. If necessary, regenerate or obtain new certificates.

Cannot Login to GroupWise Web when using Commercially Signed Certificates

Possible cause: Upstream certificate verify error.

Solution: See Knowledge Base article KM000009029.

GroupWise Monitor stops communicating with GroupWise agents

Possible cause: The target agent is using an invalid certificate.

Solution: If necessary, regenerate or obtain new certificates with a valid date range and which use the correct SAN (Subject Alternate Name).

GroupWise Calendar Publishing browsing stops working

Possible cause: The POA's certificate for the Default Post Office, as configured in the calhost.cfg file, is expired or does not match the correct SAN.

Errors are returned in the Calendar Publisher's log file.

For example:

  • <GWCAL>, -, Error, -, Site certificate date is not valid at 111.22.33.101

    Or

  • <GWCAL>, -, Error, -, Site certificate hostname does not match connection at 111.22.33.101

Solution: Check the calhost.cfg file for the value entered for “p.1.IPAddress”.

In the following example, "po.1.IPAddress=server5.acme.com" indicates that the certificate for the POA running at server5.acmecom is invalid and you must regenerate or obtain a new certificate.

# Default Post Office definitions
# po.1.Is.IPAddress.External = 1 means that po.1.IPAddress is the     external IP
# address configured for this POA.
# The default value is 0.
 ###############################################################################
po.1.IPAddress=server5.acme.com
po.1.port=7171
po.1.Is.IPAddress.External=0
Some users' calendars are not refreshing in GroupWise Calendar Publishing

Possible cause: The certificate is expired.

  1. The certificate at the user's POA could be the cause.

    Inspect the calhost.log to see if the user's POA is having the POA certificate errors.

    For example:

    • <GWCAL>, -, Error, -, Site certificate date is not valid at 111.22.33.101

      Or

    • <GWCAL>, -, Error, -, Site certificate hostname does not match connection at 111.22.33.101

  2. If there are no errors in the calhost.log file and if the POA detects a certificate error on the target Calhost server, the problem may be in the Calhost server's Apache server. In order for the POA to notify Calhost for any new calendar updates, the POA needs to initiate a new connection to the Calhost.

Solution: Regenerate or obtain new certificates.

  • (For possible cause 1) Fix the POA's certificate problem by regenerating the certificate or obtaining a new certificate. For a temporary solution, add the –sslCertErrorOverride switch to the POA.

  • (For possible cause 2) Fix the Apache server’s SSL POA’s certificate. For a temporary solution, add the –sslCertErrorOverride switch to the POA.