WebEx "Whoops! We didn't get the security certificate we expected."

[Robert Schulz]

We are running WebEx on 30+ devices under MS Windows 10 Pro (10.0.19044 Build 19044).

When running the WebEx Desktop App some of the users receive the message: "Whoops! We didn't get the security certificate we expected.", while some don't. For some the problem occurs only under VPN, others do not have any problem. 

The Health check result of the "critical" machines are: "One or more critical services are inaccessible".

I was also able to login on a "critical" machine, which was not mine and got a a totally different "health check result" and was able to work. My guess is: It is somehow related to the user settings in Webex, but I have no clue, what it could be.

[StephanieNash]

It could be the Root CA's were changed in your environment or on those computers. I've ran into this error before and had to manually add the QuoVadis Root CA 2 certificate onto the user's desktop to get it working again. I know the following domains should be allowed for Certificate Validation:

• *.identrust.com
• *.quovadisglobal.com
• *.digicert.com
• *.godaddy.com
• *.lencr.org
• *.intel.com

You could also double check with your security team to make sure *.wbx2.com is not being blocked somewhere in the environment. We've had issues before where traffic is being blocked on one side of the network and not the other. Or a certificate was not added correctly on one side and not the other.

I do agree with Jonathan, this is not a Webex issue and more than likely certificate validation or the *.wbx2.com domain is being blocked somewhere. If you have Change Control Management you could also review past changes to see if any may have impacted your Webex traffic.

[karen.wang]

I have compared working log with not working log on same machine in the same network environment.

The diffenren I can see is:

[]HttpRequestManager.cpp:2115 network::HttpRequestManager::httpRestRequest:CF #0 (default):{"id":"Making HTTP request","uri":"https://metrics-a.wbx2.com/","method":"POST","action":"/metrics/api/v1/bootstrap_metrics/tls-proxy-failure","defaultUrl":"https://metrics-a.wbx2.com","currentUrl":"https://metrics-a.wbx2.com/","retryable":false,"trackingId":

It didn't have this action untill one day after auto upgrade and restart, the error message pop out.

We got a lot users have this issue hapened on different versions. I'd like to know what change on Webex app can cause this?

[Jonathan Schulenberg]

Sounds like a proxy or equivalent (eg Zscaler) that may be performing TLS break-in on the connection. Does the problem follow the afflicted user to another computer that works fine for another user? If yes, does it disappear on a computer outside the purview of that security infrastructure?

[Robert Schulz]

Thank you for your answer. It does not appear outside our infrastructure. 
But the behaviour within our infrastructure does not make any sense. Example:
User A on notebook X has no problems to work with WebEx.
User B on notebook Y can not properly connect to WebEx.

If user A logs into WebEx in notebook Y (even under the same Windows user) it works for him/her.

[Jonathan Schulenberg]

You might be able to see what's happening by comparing a packet capture of the working and non-working machine, focusing closely on the TLS handshake and what certificates are offered to the client. If you're lucky the device performing TLS break-in will be obvious based on the cert presented. That's the only decent idea I have at the moment. This isn't a Webex user setting issue.

[Robert Schulz]

Thank you, there was not much to do on our side. I've opened a case at Cisco and they took care of the problem. 

[StephanieNash]

What was the fix as I'm getting the error now too?

[Robert Schulz]

I am sorry to hear.

I could not do anything on our side. I've opened a ticket at the support of Cisco and they#ve took care of the problem.