viva.cloud.microsoft returns *.sharepoint.com certificate (CN mismatch) from dprodmgd105/108 farms

Question

viva.cloud.microsoft returns *.sharepoint.com certificate (CN mismatch) from dprodmgd105/108 farms

Missael Granados 0

Hello community, I’m here to ask for help with something that is currently happening.

Summary

Resolving the public hostname viva.cloud.microsoft intermittently ends on

SharePoint Online farm endpoints that present a TLS certificate for

CN=*.sharepoint.com when the connection uses SNI viva.cloud.microsoft.

The CN does not match the requested hostname, so the browser throws

NET::ERR_CERT_COMMON_NAME_INVALID, and because the site enforces HSTS there

is no way to bypass it. When the resolution lands on a different endpoint the

site loads perfectly, so the failure is intermittent.

Environment

- Enterprise recursive DNS resolvers hosted in Azure (US regions:
South Central US and East US).
- End users are located in Mexico and reach the resolvers over corporate VPN.
- The same site loads fine from outside the corporate network (e.g. a mobile
hotspot), which points to a resolution/steering difference, not the client.

The CNAME chain

viva.cloud.microsoft is a long CNAME chain ending in the Akamai/Microsoft GTM:

viva.cloud.microsoft

  -> ur-vivahomeprod.tm-rt.sharepoint.com

  -> ...gr.global.aa-rt.sharepoint.com

  -> ...farm.dprodmgd105 / dprodmgd108.aa-rt.sharepoint.com

  -> ...sharepointonline.com.akadns.net

  -> (sometimes) ...dual-spov-XXXX.spov-msedge.net

The final A record oscillates between two endpoint families (chain CNAME TTLs

are 15-60s, so it rotates quickly):

FAILS: 52.104.x.x (farms dprodmgd105/108) -> serves cert CN=*.sharepoint.com
WORKS: 13.107.137.10 / 13.107.139.10 (spov-msedge.net) -> serves cert CN=viva.cloud.microsoft

What we verified

A direct TLS handshake to one of the failing IPs on port 443, using SNI viva.cloud.microsoft, returns:
```
Subject: CN=*.sharepoint.com, O=Microsoft Corporation

Issuer:  Microsoft TLS G2 RSA CA
```
The certificate chains to Microsoft's own CA, which rules out any SSL inspection / MITM on our side — the mismatched cert is served by the Microsoft endpoint itself.
Public resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1) also return the failing 52.104.x endpoint at times, and the same resolver returns both the good and the bad endpoint at different moments — so this is upstream GTM/endpoint behavior, not a client-side DNS misconfiguration.
DNS query logs over a ~20 minute window showed the "good" msedge endpoint in under 20% of resolutions; the majority landed on the dprodmgd105/108 farms.

What we tried

A conditional forward zone for viva.cloud.microsoft to a public resolver (Use Forwarders Only). It worked briefly, then reverted to the sharepoint.com farms on its own, because the upstream GTM decides the final endpoint and the intermediate CNAMEs are re-resolved outside the forward zone.

Questions

Is this a known service-side issue — a certificate binding problem on the dprodmgd105/108 SharePoint Online farm endpoints for the viva.cloud.microsoft hostname?
Has anyone hit the same *.sharepoint.com cert on viva.cloud.microsoft and gotten it corrected? What was the path?
Is there any recommended enterprise-side guidance while the fix is deployed, given the endpoint rotation?

Thanks in advance

0 comments

1 answer

Your answer

Answer 1

Hello @Missael Granados

Thank you for providing such a thorough analysis and for documenting your troubleshooting steps in detail.

I tested the behavior from my side, but because my traffic is routed through a different region and edge infrastructure, I am unable to reproduce the same routing path to the dprodmgd105/dprodmgd108 endpoints you observed. In my testing, the site loads normally.

Based on the information you shared, the behavior does not appear to be related to a local DNS configuration, VPN configuration, or SSL inspection device. The certificate chain you captured is issued by Microsoft, and you have also observed similar behavior when testing through public DNS resolvers.

Given these observations, I would recommend opening a support case through the Microsoft 365 Admin Center and providing the DNS resolution samples, CNAME chain details, certificate information, affected timestamps, and any additional diagnostic data you have collected. This will allow the appropriate engineering team to review the behavior in greater detail and determine whether there are any service-side, routing, or endpoint-specific factors that require further investigation.

As this is a public community forum, we do not have access to the backend telemetry, traffic-steering data, or service configuration details needed to validate the behavior you are seeing or determine why certain endpoint paths may be presenting an unexpected certificate.

I understand this may not be the answer you were hoping for. However, given the level of investigation already performed and the diagnostic evidence you have gathered, a formal support case would be the most appropriate path forward to ensure the issue can be reviewed by the teams with access to the necessary backend data.

Thank you again for the detailed investigation and for sharing your findings with the community.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.