I'm developing on Windows 11 and can't reach NuGet's public API endpoint. Opening https://api.nuget.org/v3/index.json in a browser returns ERR_SSL_VERSION_OR_CIPHER_MISMATCH instead of JSON or an HTTP error.
SSL Labs and PowerShell's Get-TlsCipherSuite both show support for compatible suites, including TLS_AES_256_GCM_SHA384 and TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384. The Schannel protocol registry path under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols has no protocol subkeys, although Windows 11 should support TLS 1.2 and 1.3 by default.
Event Viewer repeatedly logs Schannel errors such as "A fatal error occurred while creating a TLS client credential," with internal error state 10013. The errors affect multiple processes, including OneDrive. A work or school account associated with my Azure Marketplace account also keeps appearing automatically under Windows account settings, so I'm wondering whether a policy, security product, proxy, or TLS inspection setting is being applied.
What should I check on this machine or network to determine what is breaking the TLS connection and restore access to NuGet?
2 Answers
This may be TLS inspection rather than a simple cipher mismatch. Security products and managed-account policies can intercept HTTPS and create their own TLS connection, which can break services such as NuGet. Check Windows proxy settings, installed endpoint or VPN software, trusted root certificates, and any configuration associated with the work or school account. If traffic is being inspected upstream, the relevant domain may need to be excluded from inspection by whoever manages that network.
Test the endpoint while explicitly restricting the client to TLS 1.2: curl -IL --tlsv1.2 --tls-max 1.2 https://api.nuget.org/v3/index.json. A healthy connection should return HTTP 200 and the JSON endpoint’s headers. If curl fails with a Schannel handshake error too, the problem is below the application layer—likely local Schannel configuration, a proxy or inspection layer, endpoint security software, or the network path—not a NuGet client setting.
The TLS 1.2 curl test also fails with Schannel error SEC_E_ILLEGAL_MESSAGE (0x80090326), although Event Viewer doesn’t add a new entry immediately afterward. That suggests the failure is happening during the handshake rather than because of the NuGet application itself.
I’m self-employed, so there isn’t an employer-managed network that I know of. The work account was added automatically, though, and I’m trying to determine whether it installed a policy or security component that could be affecting Schannel.