Office 0x80072F0D: TLS inspection is breaking Office licensing calls

Fix it now

0x80072F0D is WinINet 12045, ERROR_INTERNET_INVALID_CA: the client does not recognise the certificate authority behind the certificate it was handed. On a corporate network that is almost always an inspecting gateway presenting its own certificate. Your subscription is fine and no purchase changes it.

netsh winhttp show proxy
certutil -store root

1. Browse to https://login.microsoftonline.com in Edge, open the padlock and read the certificate issuer. If it names your firewall, proxy or endpoint-security vendor rather than a public authority, inspection is in the path and that is your cause.
2. Compare the machine trust store you just listed with the user’s: certutil -store -user root. A root present only in the user store fixes browsing and nothing else, because background components read the machine store.
3. Ask whoever runs the gateway to bypass the Microsoft 365 domains from TLS decryption and deep packet inspection, matching on hostname or TLS SNI rather than on IP ranges.
4. Close every Office application and confirm no winword.exe, excel.exe or outlook.exe process survives in Task Manager, then reopen Word and check File, then Account.
5. If it still fails, sign out under File, then Account, and sign back in so the licence is fetched from scratch.

No reboot is needed for a gateway change. Closing the Office processes is, because a running client keeps its existing connection state.

If Product Information names your subscription with no activation banner, you are done. If not, the next section separates a certificate rejection from a proxy refusal, which look identical from the user’s chair.

Why it happens

Subscription Office holds no key on disk. It authenticates the signed-in identity, asks Microsoft’s licensing service what that identity is entitled to, and caches the answer in the user profile. Every step is HTTPS, and the client validates the certificate chain before it sends anything. If the chain does not end in an authority the machine trusts, the connection is abandoned before the licensing conversation starts.

The 0x80072Fxx codes are WinINet errors wrapped as HRESULTs, and the low word is the WinINet number, which makes this family unusually easy to read: Microsoft publishes a meaning for every one of them, and the reference table below sets them out. 12045, the one in the title, is ERROR_INTERNET_INVALID_CA – the function is unfamiliar with the certificate authority that generated the server’s certificate. That is precisely what an inspecting proxy produces on a machine that does not trust the proxy’s root.

0x80190193 is the one that looks like it belongs and does not. It is in the HTTP facility that BITS uses, where Microsoft publishes 401 as 0x80190191, 404 as 0x80190194 and 503 as 0x801901F7. It does not publish a constant at 0x80190193, so the obvious reading – HTTP 403 – is arithmetic rather than documentation. What you can say safely is that it is an HTTP-layer refusal rather than a certificate validation failure, and that puts it in a different investigation: read the gateway log, not the certificate.

One asymmetry explains most of the confusion here. Browsers use the current user’s certificate store and proxy settings; Office background components and the Click-to-Run service read the machine store and the machine-level WinHTTP proxy. A gateway root deployed to users only breaks Office while leaving the browser perfectly happy.

Full reference

The certificate codes, with their published text

Because the low word is the WinINet code, any 0x80072Fxx you meet later can be looked up the same way rather than guessed at. That is a genuinely useful habit, and it is the reason this family is worth understanding rather than memorising.

Reading the symptom before you change anything

Building the bypass properly

Microsoft’s guidance is to bypass Microsoft 365 domains from TLS decryption, traffic interception, deep packet inspection, and network packet and content filtering, and to permit Microsoft 365 traffic without inspection at edge routers and firewalls. It also names TLS termination and deep packet inspection of Microsoft 365 domains as a known cause of connectivity problems. Take that to the security team as the vendor’s position rather than as a request to weaken the estate: the exemption is scoped to named domains, and everything else keeps being inspected.

The current documentation points at the Microsoft 365 endpoints web service, reachable through aka.ms/m365endpoints, as the primary source for allow-listing and connectivity configuration. Build the rule from that rather than from any list typed into an article, including this one.

Hosts that come up in Office licensing traffic

Treat that as an orientation for the conversation, not as the allow-list. Only the first is verifiable from the published identity endpoint set as written here; the rest are the hosts these calls are commonly seen against, and the endpoints web service is the authority on all of them.

When the bypass is in and it still fails

• Confirm the bypass matches the hostname the client actually requests, including any regional variant, and that it is applied to the client’s subnet.
• Re-check the machine root store after the change. A stale inspection root left behind can still be selected for some connections.
• Check for a second inspection point – an endpoint agent doing local interception as well as the gateway.
• Confirm the machine proxy is what you think it is; an automatic configuration script can return a different answer for these hosts than for everything else.
• Test with a machine on the same subnet that has never had the inspection root installed. If that one works, the problem is client state rather than the path.

Every code this article covers

Confirm the fix worked

1. Browse to https://login.microsoftonline.com and confirm the certificate chains to a public authority, or that the inspection root is present in the machine store.
2. certutil -store root lists the authority the gateway presents, if inspection is intentional and staying.
3. Open Word and check File, then Account: Product Information names the subscription with no activation banner.
4. Restart and open Outlook first. Licensing that survives a cold start has been cached rather than granted for one session.
5. Repeat on a second machine behind the same gateway to confirm the bypass, not one client, is what changed.

Questions people ask about this