Backend certificate issues – an unknown error occurred processing the certificate.

A common issue with UAG is having your users receiving an error when trying to launch an application from UAG (such as OWA, for example). The error is “An unknown error occurred while processing the certificate”:

It’s important to realize that this means that UAG had an issue when trying to validate the certificate presented by the backend server that it’s publishing (for example, the Exchange or SharePoint server). When UAG needs to publish a backend server that is using SSL, UAG is configured by default to inspect that certificate using the standard mechanisms (validity, trust-chain, integrity and CRL). The error indicates that this failed for some reason.

It could be that the certificate itself has been damaged in some way, but the most common cause for this happening is a problem with the certificates CRL/CDP. The CRL is typically published automatically on the CA server that created the certificate, and the Certificate has a CDP (Certificate Distribution Point) list pointing to one or more CRL locations:

This means that the UAG needs to have access to at least one of these locations, to be able to download the CRL file, and verify the certificate has not been revoked. In organizations that have a tight control over what UAG has access to (with a DMZ firewall, for example), UAG may not have access and fail the certificate check. In some instances, a routing or DNS change on the internal network may cause the CRLs to become unavailable, causing the same problem.

Another common cause for this is an incorrect setup of the server name on the UAG applications’ Web Server tab:

When UAG needs to fetch information or pages from the backend server, it will resolve the hostname specified in the Addresses tab above, and contact that server. If, however, the certificate that server has contains a hostname that is different than this, UAG will not agree to continue and display an error such as mentioned above.

The ideal solution to the CRL problem is to adjust or fix the routing/DNS/Network/Firewall in a way that will provide UAG full access to verify the certificate. For a name-mismatch situation, the best thing to do is adjust the hostname specified in Addresses to one that matches the name on the certificate. These steps may not always be possible, or may involve a complex procedure and change-management hurdles, so there is another workaround. UAG has a configuration that tells it whether to validate the Certificate, and whether to validate the CRL locations. To overcome this problem, simply set UAG to not check these. The procedure is as follows:

1. On the UAG Server, open the Registry Editor

2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom\e-Gap\Von\URLFilter\Comm\SSL

3. To cancel the validation check in its entirety, modify the value of ValidateRwsCert from 1 to 0

4. To cancel just the CRL check, modify ValidateRwsCertCRL from 1 to 0

5. Close the Registry Editor

6. Activate the UAG configuration to make the change permanent (otherwise, a reboot will revert it)

7. If this is applied to a UAG array, the registry needs to be edited only on the array manager. The activation will push it to the other server/s

8. Restart the IIS service on the Forefront UAG server. If this is an array, this needs to be done on all members.

Naturally, this brings about the question whether this workaround is reasonable. Essentially, skipping the certificate check is less secure than letting UAG perform the check, so our official recommendation is to fix the cert access and not work around it. However, the real-life security risk is usually not very high. The purpose of this check is for UAG to verify that the server it is talking to is real, and a situation where it is not may occur only if an attacker points the UAG application towards a different internal server by using DNS poisoning, altering the HOSTS file on UAG or editing the UAG app. Naturally, to do this, the attacker will have to achieve a very high level of penetration, which would also allow him to change this registry key. In other words, the default setting will probably not protect your organization from any attacker who has been able to jeopardize the certificate trust.

If the problem described above still persists after applying the registry changes, then something else may be interrupting the SSL Handshake mechanism between UAG and the backend server. For example, the backend servers SCHANNEL mechanism may not be compatible with UAG for some reason. To investigate this, a UAG Server trace will be required, and possible an SCHANNEL trace as well. Here’s a list of various SSL related codes that might provide more info: