Fixing "Copilot Can't Create a Trusted Connection" on a VPS

If you open Copilot on a Windows Server VPS and it stalls with a message like "unable to create a trusted connection", the assistant itself is rarely the problem. The error almost always means the request never completed a secure handshake with Microsoft's endpoints. On a rented VPS you reach over Remote Desktop, several things conspire to break that handshake: a hardened TLS configuration, clock drift, a missing root certificate, or an outbound proxy. This guide walks through the checks in the order that resolves the most cases first.

What "trusted connection" actually means

Copilot runs inside a WebView2 surface and talks to Microsoft services over HTTPS. A "trusted connection" is a successful TLS session: the client offers a modern protocol, the server presents a certificate, and the client validates that certificate against a trusted root. If any link in that chain fails, the UI can only tell you it could not establish trust. So the fix is to restore each link: protocol, time, certificates, and the network path.

Step 1: Confirm the server can reach the internet

Server editions are frequently locked down more than desktops. From a PowerShell session over RDP, test outbound HTTPS directly:

Test-NetConnection login.microsoftonline.com -Port 443
Invoke-WebRequest https://www.microsoft.com -UseBasicParsing | Select-Object StatusCode

If TcpTestSucceeded is False or the request times out, the issue is network reachability, not Copilot. Check your firewall rules and any provider-level security groups before going further.

Step 2: Fix the system clock

A clock that is off by more than a few minutes makes every certificate look invalid, because TLS validates the "not before" and "not after" dates. Virtual machines are especially prone to drift after a reboot or snapshot restore. Force a time sync:

w32tm /resync /force
w32tm /query /status

If the service is not configured, point it at a reliable source and restart it:

w32tm /config /manualpeerlist:"time.windows.com" /syncfromflags:manual /update
Restart-Service w32time

Confirm the time zone is correct too (Get-TimeZone) — an accurate UTC offset matters as much as the raw time.

Step 3: Enable modern TLS

Older or heavily hardened Windows Server builds sometimes still negotiate TLS 1.0/1.1 or have TLS 1.2 disabled in the registry. Microsoft endpoints require TLS 1.2 at minimum and increasingly prefer TLS 1.3. Make sure .NET and WinHTTP use strong protocols. For .NET, confirm the SystemDefaultTlsVersions keys are enabled:

$base = 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319'
Set-ItemProperty $base 'SystemDefaultTlsVersions' 1 -Type DWord
Set-ItemProperty $base 'SchUseStrongCrypto' 1 -Type DWord

Do the same under the Wow6432Node path for 32-bit components, then reboot so the schannel changes take effect. If a group policy or hardening script explicitly disabled TLS 1.2, re-enable the client protocol under the SCHANNEL registry branch.

Step 4: Update the root certificate store

Fresh server images and air-gapped builds often miss recent trusted roots, and by default Windows fetches them on demand. If outbound access to Microsoft's certificate CDN is blocked, validation fails. Trigger a refresh and review the store:

certutil -generateSSLCert
certutil -verifystore Root

If your environment blocks automatic root updates, download the current trusted root list on a connected machine and import it, or whitelist the certificate trust endpoints at your firewall.

Step 5: Account for proxies and inspection

Many hosted environments route outbound traffic through a proxy or a TLS-inspecting gateway. TLS inspection re-signs traffic with the proxy's own certificate; if that certificate is not in the server's Trusted Root Certification Authorities store, Copilot sees an untrusted connection. Check what WinHTTP is using:

netsh winhttp show proxy

If a proxy is set but credentials or the inspection root are missing, either import the proxy's root certificate into the Root store or add an exception for Microsoft's Copilot and sign-in domains. Note that per-user Internet Options proxy settings do not always apply to system components, which is why checking WinHTTP matters.

Step 6: Repair WebView2 and the host app

Because Copilot renders through WebView2, a stale or corrupted runtime produces the same symptom. Confirm it is installed and current:

Get-ChildItem 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\EdgeUpdate\Clients' |
  ForEach-Object { Get-ItemProperty $_.PSPath } | Select-Object name, pv

Reinstall the Evergreen WebView2 runtime if it is absent or outdated, then restart the Copilot host. Clearing the WebView2 user data cache for your profile also clears stale tokens that can block a new session.

Step 7: Sign-in and tenant checks

If the transport is healthy but sign-in still fails, the account may lack a Copilot license, or a conditional access policy may block logins from your VPS IP range. Test authentication reachability to login.microsoftonline.com as in Step 1, and confirm with your tenant administrator that the location and device are permitted.

Working methodically over RDP

Change one thing at a time and re-test, because several of these fixes — TLS registry edits, time sync, certificate imports — only take effect after a service restart or reboot, and over RDP it is easy to lose track of what you changed. Keep a short log of each command and its result. In practice, the clock and TLS steps resolve the large majority of "trusted connection" failures on freshly provisioned Windows Server instances; proxy and certificate issues account for most of the rest in locked-down environments.