That’s a user-agent string — Windows Server 2022 and the Azure Cosmos DB .NET SDK. It has no relationship to the domain, the project, or anything in the stack. It looks like an unrelated value is being rendered into that field.
The real cause was a DNS misconfiguration, which was fine once found — but the error text sent me looking in entirely the wrong direction first.
Worth fixing, and worth having that field state the actual reason instead.
Good catch. That definitely looks like a diagnostics/UI bug rather than an actionable domain error.
If the real issue was DNS misconfiguration, then showing a value like:
Windows/10.0.20348 cosmos-netstandard-sdk/3.18.0
is pretty misleading, because it sends people toward their app/runtime stack instead of the actual domain/certificate checks.
For anyone else landing here, I would not treat that kind of string as the cause of the cert failure. I’d still debug the domain normally: live A/CNAME, no conflicting AAAA, CAA records, and whether the HTTP validation path can reach Vercel cleanly.
The useful bug report details here are probably the exact domain status shown in the dashboard, the misleading error text, approximate timestamp, and confirmation that fixing DNS resolved the certificate issue. That should make it easier for Vercel to trace where the wrong field is being rendered.
