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 do not pass certificate verification.
Troubleshooting information is provided in the sections below:
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.
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
Run the following command:
openssl x509 –in <certificate> -noout –text
Look for the validity period and for Subject Alternate Names.
The following issues are the most common problems we have seen with certificate verification:
Certificates were created using the shipped version of GroupWise 2014.0
Windows Client user receiving a prompt asking if the certificate is trusted (new install)
Cannot Login to GroupWise Web when using Commercially Signed Certificates
Some users' calendars are not refreshing in GroupWise Calendar Publishing
Example: server53 was used instead of server53.acme.com
Solution: Fix the network name for the server and regenerate or obtain new certificates.
Certificates are malformed. A fix to this was made available a few months after the initial release.
Solution: Regenerate your GroupWise generated certificates.
Solution: Regenerate or obtain new certificates.
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.
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.
If certificates were regenerated in your GroupWise system, you will need to make sure your DVA is pointing to the correct certificates. For example:
Launch GroupWise Admin > System > Document Viewer Agents, and select the DVA. Verify that Enable SSL is selected.
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
Restart the gwdva. For information, see Putting DVA Configuration Changes into Effect.
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>
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
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.
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.
Possible cause: Upstream certificate verify error.
Solution: See Knowledge Base article KM000009029.
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).
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
Possible cause: The certificate is expired.
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
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.