Access denied message when browsing through WSS

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Users accessing WSS started seeing access denied message for all requests through WSS

User information may be present on blocked page, but block reason is related to not being member of group.

Impacts all access methods that are using Auth Connector for authentication or group retrieval

WSS Portal shows Auth connector status showing connection errors to a number of WSS pods

 

 

Environment

Component : Auth connector

Cause

Auth connector server is missing DigiCert Global Root G2 certificate, and cannot validate the SSL server certificate sent down from WSS.

WSS recently updated it's soon to be expiring certificate with one that will expire in 2028. Although issued by Digicert, any Windows servers running the Auth Connector that do not have the Digicert root and intermediates certificates required to validate the server certificate WSS sends down will fail to connect successfully.

Resolution

Apply all Windows updates on all Auth Connector servers so that Digicert certificate is added to the trusted certificate store - Windows Trusted Root Update package from July 2020 has the right certificate (https://docs.microsoft.com/en-us/security/trusted-root/2020/july2020)

An manual update can be applied too by 

- downloading the missing intermediate certificate from https://cacerts.digicert.com/DigiCertGlobalG2TLSRSASHA2562020CA1.crt

- adding it to the Trusted Root Certification Authority store on Auth connector server

- restarting the auth connector service.

Additional Information

Auth Connector needed to authenticate the users, or to retrieve user groups but connection into WSS pods fail

Auth connector server does not able to connect to all data pods and Auth connector's Windows application event logs show the following error multiple times

"The certificate chain was issued by an authority that is not trusted."

Due to the connection failing into WSS, the  proxy is not able to get information about users and groups mapping, and end up with group policy failures. Policies specifically referencing users (instead of groups) still work. When group based policies fail, the default block-all or allow-all policy gets executed. Tenants with default block-all policy experience almost no website accessible.

Debug logging for BCCA Auth Connector agent shows a successful connection to auth.threatpulse.com. But the connection to the various data pods (IP similar to: 148.64.3.xxx) fails with the above certificate error