Official documentation checked October 14, 2026.
A TLS error around Copilot does not identify which machine needs a registry change. A browser, custom agent action, connector, gateway, reverse proxy, and backend API can each participate in different connections. Locate the failing connection before altering a shared server.
Microsoft has deprecated TLS 1.0 and 1.1 for Microsoft 365 and directs affected API clients toward TLS 1.2. See the Microsoft 365 TLS guidance. Do not re-enable obsolete protocols, disable certificate verification, or treat a TLS 1.2 frontend with a TLS 1.0 backend as a secure end-to-end fix.
Identify the caller, server, and actual error
- Record the app or agent action, failed hostname, time, operating system, runtime, and exact error. Do not include tokens, API keys, or confidential request bodies in a support report.
- Map the connection path. Determine whether failure is between the user’s device and Microsoft 365, a connector host and an on-premises service, or a custom action and its API. Use the relevant connector’s documented architecture rather than assuming Copilot directly queries an arbitrary on-premises server.
- Review logs at the failing hop. On a Windows component using Schannel, inspect existing Schannel entries in the Windows System event log around that time. A gateway or application using another TLS library requires its own diagnostics.
- Distinguish name resolution, TCP reachability, TLS negotiation, certificate validation, and an HTTP response. A TCP port check alone cannot prove a successful TLS handshake.
For an ordinary Microsoft 365 client network failure, use the organizational connectivity test and network team. Registry changes on an unrelated SharePoint server cannot repair that path.
Prefer supported upgrades and controlled protocol configuration
Update the affected application, operating system, runtime, and appliance to supported versions that meet both ends’ TLS requirements. Test the vendor-supported configuration in a representative nonproduction environment first. Back up the relevant configuration and agree a maintenance window and rollback before changing a shared service.
For Schannel, the Client and Server protocol settings affect different roles. An outbound connector needs the client side checked; an incoming HTTPS listener needs the server side checked. An absent registry override does not by itself mean TLS 1.2 is disabled. Windows defaults and the application’s own constraints matter.
Microsoft’s Schannel reference recommends managed tools where possible and warns about direct registry editing. It also states that these settings do not control third-party TLS implementations. Manage cipher suites through supported policy, MDM, or PowerShell mechanisms; do not add cipher-suite names under an invented Ciphers-key recipe.
Enabling TLS 1.2 is not equivalent to disabling every other protocol, and disabling TLS 1.0 alone does not disable TLS 1.1. Keep modern supported protocols available and validate the negotiated result after the approved change.
Check .NET and IIS settings without changing authentication
For a custom .NET Framework client, inspect its target framework and code for explicitly pinned obsolete protocols. Microsoft’s .NET Framework TLS guidance generally recommends allowing the operating system to select a supported protocol. Where ServicePointManager.SecurityProtocol must be set, SecurityProtocolType.SystemDefault follows that approach.
SchUseStrongCrypto affects outgoing .NET Framework connections; it is not a universal inbound web-server TLS switch. Registry changes can affect other applications on the machine, so the application owner must review the framework version, process architecture, and effective settings instead of copying a system-wide tweak blindly.
In IIS, Require SSL requires a secure connection; it does not select TLS 1.2. The Accept and Require client-certificate choices concern authentication. Do not change them merely to repair protocol negotiation. Microsoft’s IIS access-settings reference describes these distinct controls.
Verify TLS, then investigate any remaining application error
Retest through the actual caller or gateway, not only an administrator’s browser. Check the negotiated protocol, certificate hostname, validity period, chain, and trust at the component performing validation. Follow the specific connector or gateway’s certificate requirements; there is no universal Copilot “tenant trusted root store” that makes every private certificate work.
If a 403 response remains, identify which server or proxy returned it and inspect its detailed status. The IIS status reference distinguishes, for example, IP rejection, missing client certificates, and invalid client certificates. A generic 403 is not proof of an untrusted server certificate.
If the backend cannot support the required secure connection, pause that integration and escalate to its owner for upgrade or replacement. Any temporary legacy exception requires a documented security decision; do not silently insert a TLS 1.0 bridge. Close the issue only when the supported end-to-end path succeeds without disabling verification or weakening authentication.