If that is the one that matches what was posted then yes. A cursory glance, those fingerprints match so I'd say yes that is one of the certificates with which we've narrowed issues down to.

I would think that a large company like voip, would have their certificate provider documented, and available to check when there is a significant issue, so when their customers report a problem and they say it isn't a match that's exactly what they mean.

Also, the only indicator of any of these issues which prompted all this, with any real explanation, is with the cert and by extension the secure tunnel which cannot be trusted. The issues extend to not just this one vendor, but several others as well across multiple devices and network connections. The translation issue appears only visible with this provider though due I suspect to their non-standard password policy, which appears contradictory at the edge in function.

Saying TLS is trustworthy, where things that shouldn't ever happen under TLS guarantees are happening, with no viable alternative explanation for the issues, where they have been troubleshooted over months at both ends, including all the way down to the raw physical level of the OSI level for traffic (at least at the edge)... that doesn't leave anyone with anywhere to go.

Still Trust TLS? If there were a reasonable alternative explanation that ties in and touches on all the issues both mentioned and unmentioned, I'd be the first to consider it.

Clearly there are objective issues where service cannot be relied upon for a business, let alone for anything less demanding. The issues are also not vendor specific and seem to be coupled loosely to geographical region. The only commonality are these Google Trust certificates.

Communications services fail silently across multiple providers, contact forms either fail to submit with weird HTTP error codes for large providers or submit with success only to have non-response with no verifiable record of submission after-the-fact, support chat's fail to load or load with a chatbot pretending to be a human with no record after-the-fact, emails disappear, and many other things that effectively rely upon only one thing in common when taken in aggregate.

When its one thing that happens in isolation at a single vendor sure I'd be more receptive to it being something else on the vendor side, but when every single path fails regularly in the same chaotic way in narrow time horizons, there's a significant issue, and one must question not only the guarantees, but the only common links.

Three or more path failures related to communication, within a short time horizon, all leading back to TLS guarantees, is beyond an astronomical bayes probability that something there is silently happening over those links that shouldn't be happening.

The TLS guarantees are to the edge of the infra of the vendor. If that vendor has decided to use infra providers that issue certs for them without their knowledge and they have not implemented CAA then the blame is not on TLS, it is on the vendor. A lot of what you mention can be explained by cloudflare issuing certs for customers without them knowing when using their DNS, an agressive WAF or other much more plausible things.