Description
Starting around 10:00am US Eastern on 1/29/2022 we started seeing connection errors with all API calls. We are currently troubleshooting our environment to identify any changes that could account for it but also wanted to reach out to see if there are any connectivity issues that could be identified on the Zoom side.
Error
Unable to connect to the remote server.
A connection attempt failed because the connected party did not
properly respond after a period of time, or established connection failed because
connected host has failed to respond
Which App Type (OAuth / Chatbot / JWT / Webhook)?
JWT
The disruption in connectivity would seem to coincide with an update to our certificate on that server. The certificate expired on 1/29 and was renewed with a valid one that morning. I am still able to call the APIs with our integration in my local environment under http connections so it would appear to be an issue with the new certificate on that server.
Is the timeout error we’re seeing the expected response from Zoom API calls if there has been a lapse with a server certificate? Would that event flag something on the Zoom side that need to be cleared before calls would be successful again?
We’ve been having issues since Saturday morning central time as well. We only appear to be having issues with two IPs 170.114.10.84 and 170.114.10.85. On Saturday, we’d intermittently resolve to 52.202.62.238 and would have no problems with that IP. At some point over the weekend, it switched to where we are almost exclusively resolving api.zoom.us to 170.114.10.84 and 170.114.10.85. We currently are proxying traffic from one data center through another that seems to be unaffected.
I’ll take a look at our certs and see if we can see anything.
That was helpful thanks. Our server was attempting to call against 170.114.10.84 and 170.114.10.85 as well and we were able to get calls through again once we forced api.zoom.us to resolve to 52.202.62.238
I don’t think we want that to be our lasting solution though, so hopefully Zoom will have some feedback to help us better understand the behavior we’re seeing.
We found in our primary data center those IPs that Zoom transitioned to ended up being on their IPRM flagged as malicious. So, our data center was actually blocking traffic. It was fishy we weren’t even getting to certificate exchange. We are having an issue in another data center, so we are still trying to track that down.
What I’m seeing this morning is that we are able to make calls against those .84 and .85 IPs again in our environment. I’m a little hesitant to remove our workaround for the time being though.