I'm developing on Windows 11 and can't reach the public NuGet API endpoint at https://api.nuget.org/v3/index.json. Opening it in a browser produces ERR_SSL_VERSION_OR_CIPHER_MISMATCH instead of JSON or an HTTP error. SSL Labs and PowerShell's Get-TlsCipherSuite show that both ends support compatible suites, including TLS_AES_256_GCM_SHA384 and TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384. The SCHANNEL protocol registry path has no protocol subkeys, although Windows 11 should support TLS 1.2 and TLS 1.3 by default. Event Viewer repeatedly logs SCHANNEL errors stating that a fatal error occurred while creating a TLS client credential, with internal error state 10013. The problem affects multiple processes, including OneDrive. I also noticed that an account associated with my Azure Marketplace work is being added automatically under Windows Accounts > Access work or school. Could that account be applying security policies or otherwise interfering with TLS? What should I check or disable to restore access?
3 Answers
The important test is whether the handshake succeeds when explicitly restricted to TLS 1.2. A command such as `curl -IL --tlsv1.2 --tls-max 1.2 https://api.nuget.org/v3/index.json` should return HTTP 200 on a normal connection. Since the same command fails with SCHANNEL `SEC_E_ILLEGAL_MESSAGE`, the problem is occurring during the Windows TLS handshake rather than after NuGet responds. Compare the result on another network and inspect the active proxy and VPN configuration.
This looks more like TLS interception or a security product acting as a proxy than a simple cipher mismatch. Corporate or endpoint-security tools can inspect HTTPS traffic and sometimes break services that use modern TLS. Check Windows proxy settings, VPN clients, antivirus or web-filtering features, and any security software installed with the work account. Temporarily disabling those components, or testing from a clean network such as a phone hotspot, can help identify whether the connection is being intercepted. If it is, the NuGet domain may need to be excluded from inspection.
The automatic work or school enrollment could matter if it installed device-management policies, certificates, a proxy, or endpoint protection. Review the connected account under Windows Settings and check whether the device is managed, but avoid deleting it blindly if it belongs to an organization. Also compare `netsh winhttp show proxy` with the normal Windows Internet proxy settings, and check installed root certificates and security software for HTTPS inspection. If the connection works after removing the device from that management or on an unmanaged machine, the enrollment policy is the likely cause.
The TLS 1.2 curl test fails with the same SCHANNEL handshake error, and no new Event Viewer entry appears. I’ll compare the result on another network and investigate the proxy, certificates, and management policies associated with the work account.