Official documentation checked October 14, 2026.
A self-signed-certificate or untrusted-chain error means the client could not establish the required certificate trust. A corporate inspection proxy is one possible cause, but the error is not proof that every certificate shown should be trusted. Identify the Copilot product, client, and certificate issuer before changing a trust store.
1. Confirm the application and certificate source
Record whether the failure is in a Microsoft 365 app, a browser, or a GitHub Copilot editor extension. Collect the exact error, hostname, client version, and time. Compare with an IT-approved working device using the same network; do not bypass corporate network policy to test.
Ask the network team whether the presented issuer belongs to its approved inspection service. An unknown issuer, unexpected hostname, or invalid certificate period needs investigation. A self-signed root is normal in a trust hierarchy; the problem is whether the client has a valid chain to an explicitly trusted authority, not simply whether a certificate is self-signed. Microsoft’s certificate error definitions distinguish untrusted roots, name mismatches, and validity failures.
2. Decide whether inspection should be used for that connection
For Microsoft 365 traffic, Microsoft’s network-device guidance warns that decryption and protocol modification can affect supportability and operation. Installing a certificate does not guarantee that inspection is compatible with every Copilot feature.
The network-security team should compare the actual route with the current Copilot requirements, including required domains and secure WebSockets. If an approved inspection exception is needed, implement it centrally for the documented traffic. Do not improvise a registry bypass list or assume a short list of Graph and login hosts covers the product.
3. Deploy only a verified organizational trust chain
If the approved design requires a corporate CA and it is genuinely missing, obtain the public CA certificate through the organization’s authenticated IT channel. Independently confirm the expected fingerprint and purpose with the PKI owner. A root trust addition affects much more than Copilot; a certificate downloaded from the failing page is not sufficient evidence of authenticity.
On Windows, IT can inspect the local-computer stores with certlm.msc. Place approved root and intermediate certificates in their appropriate stores through the managed deployment process. Do not put a server’s leaf certificate or every intermediate into Trusted Root Certification Authorities to suppress a warning. Installing a public trust anchor does not require distributing the CA’s private key.
For domain-managed devices, the documented Group Policy path is Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies. Scope and test the policy on approved devices first. See Microsoft’s certificate-distribution guidance; have the PKI administrator choose the store and deployment method.
4. Handle client-specific trust without disabling validation
A working browser does not prove that an editor extension, packaged application, or service account sees the same trust store and proxy configuration. Identify where that client actually executes and which certificate mechanism its documentation supports. Restart the affected application after the approved change and collect fresh diagnostics.
For GitHub Copilot specifically, GitHub documents platform-dependent certificate discovery and proxy/certificate troubleshooting. Do not apply that implementation description to Microsoft 365 Copilot. Keep strict certificate checking enabled: suppressing TLS errors can conceal interception rather than repair trust.
5. Verify connectivity separately from access to work data
Repeat the same failing request with the same approved network path and validation enabled. Check that the expected certificate chain is presented and the original TLS error has gone. Then test the intended Copilot feature using non-sensitive content.
If Copilot connects but returns a generic answer, investigate the signed-in account, feature entitlement, grounding context, and source permissions separately. That symptom alone does not justify widening proxy exclusions or file permissions. Keep the client, issuer, policy change, and result in the support record; escalate remaining failures without exporting private keys or deleting unrelated certificates.