Failed When Searching Source MSStore an Unexpected Error Occurred While Executing the Command 0x8a15005e the Server Certificate Did Not Match Any of the Expected Values: Fixing the Winget Store Certificate Mismatch

That error string comes from WinGet, Windows' built-in package manager, when it fetches the Microsoft Store source manifest over HTTPS and the certificate the server presents doesn't match the certificate thumbprint pinned in your local source configuration. The fix is to inspect and re-register the msstore source with the current certificate. Nothing is wrong with your PC's security, and nothing needs to be reinstalled.

You'll see the failure most often when you run something like winget install --source msstore or winget source update. WinGet contacts https://storeedgefd.dsx.mp.microsoft.com/v9.0, checks the TLS certificate against an expected value baked into the source definition, and aborts with 0x8a15005e when the two don't line up. The cause is almost always a stale local source registration, a proxy or antivirus intercepting TLS, or a Winget version that predates a certificate rotation Microsoft performed on its end.

The number itself is a WinGet-specific HRESULT, not a Windows Update or Store error. 0x8A15 is the WinGet facility code, and 005e identifies the certificate-mismatch condition inside it. Microsoft documents these APPINSTALLER codes in its WinGet troubleshooting reference, but it doesn't publish a per-code remediation guide, which is why most searches dead-end. Treat the code as a signal that the trust handshake between WinGet and the Store endpoint failed, not as evidence of malware or a corrupted Windows install.

One boundary matters before you start. If your machine sits behind a corporate TLS-inspecting proxy, the certificate WinGet sees genuinely won't match what Microsoft signed, and no amount of source re-registration will change that. In that case the fix belongs with your IT team (adding the proxy root CA to WinGet's expected certificate list, or bypassing inspection for the Store endpoint), not with the steps below. The guide assumes a normal home or small-office network without TLS interception.

What 0x8a15005e Actually Checks When WinGet Contacts the Store

WinGet stores each source as a named entry with a type, an argument (the endpoint URL), and a data field that includes the expected certificate thumbprint. When you run a search or install against msstore, WinGet opens an HTTPS connection, retrieves the server certificate, and compares its SHA-256 thumbprint to the one recorded in that source entry. A mismatch produces 0x8a15005e and stops the command before any package metadata is downloaded.

The check exists because the Store source is a remote catalog, and WinGet wants to be sure it's talking to Microsoft's real endpoint rather than an impostor. That's a sound design, but it means any change to the certificate on Microsoft's side, any local caching of an old thumbprint, or any intermediary that re-signs the connection will trip the comparison. The failure is a trust mismatch, not a network outage and not a permission problem.

Winget's source configuration lives in a settings file under your user profile, and the msstore entry is created automatically the first time Winget runs. If that entry was written by an older Winget build and Microsoft later rotated the certificate, the stored thumbprint goes stale. The endpoint still works in a browser, which is why people get confused: the website loads fine, but winget refuses. The browser trusts the new certificate through the normal CA chain; Winget compares against a pinned value that hasn't updated.

There's a second, quieter trigger. Some third-party security suites and DNS filtering services perform TLS inspection on outbound traffic and present their own certificate. WinGet sees that substituted certificate, compares it to Microsoft's pinned thumbprint, and fails the same way. If the error appeared right after you installed a new antivirus or changed DNS providers, that's the likely culprit, and the diagnostic step is to check the certificate chain your machine actually receives.

Confirm the Cause in Three Commands Before Changing Anything

Run these in order in an elevated PowerShell or Command Prompt. They tell you whether the problem is a stale source, a proxy, or a Winget version that needs updating. Don't skip to the reset until you've seen what the first two commands report.

1: winget --version — note the exact version string. If it's older than the current release listed on Microsoft's WinGet GitHub releases page, update first with winget upgrade Microsoft.AppInstaller or by installing the latest App Installer from the Microsoft Store. 2: winget source list — confirm msstore appears and note its argument, which should read https://storeedgefd.dsx.mp.microsoft.com/v9.0. If the entry is missing entirely, the source was never registered and that alone explains the failure. 3: winget source update --name msstore — this forces WinGet to re-fetch the source definition. If it succeeds, the error is cleared. If it fails with the same code, the pinned thumbprint is stale and you'll need the reset in the next section.

If all three commands behave, but the error returns only when you're on a particular network (a hotel Wi-Fi, a school connection, a VPN), the cause is the network's TLS handling, not your machine. Test by tethering to a phone's mobile hotspot and repeating the install. A success on the hotspot and a failure on the original network points squarely at interception, and the honest answer is that you need the network administrator to allow the Store endpoint through without inspection.

One more check if you use a proxy: run netsh winhttp show proxy and compare it to the proxy configured in Windows Settings under Network & Internet. WinGet honors the system proxy, and a proxy that terminates TLS will reproduce this exact error even on a clean Winget install. If a proxy is set and you don't need it, removing it and retrying is faster than any source surgery.

Reset the msstore Source to Clear a Stale Certificate Thumbprint

This is the fix that resolves most cases. Removing and re-adding the source forces WinGet to write a fresh entry with the current certificate thumbprint, which clears the mismatch. Run each command and wait for it to finish before the next.

1: winget source remove --name msstore — removes the stale registration. If Winget protests that the source is in use, close any other terminal windows running Winget and retry. 2: winget source reset --force — clears the cached source data. This is the step people skip, and it's the one that actually discards the old certificate data. 3: winget source add --name msstore https://storeedgefd.dsx.mp.microsoft.com/v9.0 — re-registers the Store source against the current endpoint. 4: winget source update — refreshes all sources, including the newly added one. 5: winget search --source msstore notepad — a harmless test query. A list of results means the certificate check now passes.

If step 3 refuses the URL or reports an invalid source, your Winget build is too old to accept the current endpoint format. Update App Installer first, then repeat the sequence. Microsoft's WinGet documentation notes that source commands require an elevated session on some builds, so if you get an access-denied message, reopen the terminal as administrator and rerun from step 1.

Expect the whole sequence to take under two minutes on a normal connection. The only real failure mode is a proxy or security product re-signing the connection, in which case the new source entry will store the correct thumbprint but the live connection will still present the wrong certificate, and the error returns on the next search. If that happens, you've confirmed interception and should move to the network-level fixes rather than repeating the reset.

When a Proxy or Antivirus Is Re-Signing the Connection

TLS inspection works by having a local security product intercept the outbound connection, terminate it, and open a new connection to Microsoft using its own certificate. Your browser trusts that certificate because the product installed its root CA into the Windows certificate store. Winget doesn't consult the Windows trust store for this check; it compares against the pinned thumbprint in the source entry, so the substituted certificate fails the match even though it's technically trusted by the OS.

The practical test is to look at the certificate your machine actually receives. In PowerShell, run (Invoke-WebRequest https://storeedgefd.dsx.mp.microsoft.com/v9.0 -UseBasicParsing).StatusCode and, if it errors, examine the exception's certificate subject. If the subject names your antivirus vendor or your company's proxy rather than Microsoft, interception is confirmed. A subject containing "Microsoft" and a valid chain points back to a stale source instead.

Fixing interception depends on who controls it. On a home machine with a consumer security suite, the product's settings usually include an option to exclude specific domains from HTTPS scanning, and adding storeedgefd.dsx.mp.microsoft.com there ends the problem. On a managed corporate device, you can't and shouldn't bypass it yourself; raise a ticket asking IT to allow the Store endpoint through without inspection or to add the proxy root to Winget's expected certificate configuration.

There's an edge case worth naming. Some VPN clients and DNS filters do transparent TLS interception without installing a root CA, which produces certificate errors in browsers too. If your browser also warns on the Store endpoint, the problem is broader than Winget and the network path is the place to fix it. If only Winget complains, it's the pinned-thumbprint comparison and the reset in the previous section is the right move.

Winget Version Gaps That Trigger the Mismatch

Certificate rotations on Microsoft's side don't break every machine at once. They break machines running Winget builds that predate the rotation, because the old build carries the old thumbprint in its default source definition. That's why two PCs on the same network can behave differently: one has a current App Installer, the other hasn't updated in a year.

Check your build against Microsoft's published App Installer release notes rather than guessing. The version string format is a date-based number, and the GitHub releases page for the WinGet repository lists each release with its date and changes. If your version is more than a few months behind, update before doing anything else; the certificate fix may already be included.

Updating App Installer through the Store has a catch: if the Store itself is broken, you can't use the Store to fix the tool that talks to the Store. In that case, download the App Installer package from Microsoft's official WinGet releases page and install it manually. Avoid third-party download sites for this file; the package is signed, and a tampered installer is a genuine risk.

If you're on Windows Server or an LTSC build without the Store, Winget isn't preinstalled and the msstore source may behave differently or be unavailable. Microsoft's WinGet documentation lists supported Windows versions, and Server 2022 with the App Installer sideloaded is a supported path but the Store source requires the Store infrastructure to be present. On those systems, the winget source is the practical route and the Store source can be left out entirely.

Reading the Error Log to Prove Which Certificate Was Rejected

Winget writes diagnostic logs you can read to see exactly what certificate was presented and what was expected. The log location is documented in Microsoft's WinGet troubleshooting guidance and typically sits under your user profile's AppData folder in a DiagnosticStore subfolder. Open the most recent log after reproducing the error and search for the code 0x8a15005e; the surrounding lines name the endpoint and often the certificate subject.

This matters because it converts a guess into evidence. If the log names your antivirus vendor's certificate, you've confirmed interception and can stop fiddling with sources. If it names Microsoft's certificate but reports a thumbprint mismatch, the local source entry is stale and the reset is correct. If the log shows a timeout or DNS failure instead, the error code may be a symptom of a different network problem.

The log also records the Winget version and the resolved source argument, which is useful when you're comparing two machines. Copy those lines into a ticket if you end up contacting support; it saves a round of back-and-forth. Don't post the full log publicly without checking it for usernames and network details first.

Reading logs is the step most guides skip, and it's the reason people cycle through random fixes. Five minutes with the log tells you which of the four causes you actually have. The reset solves stale sources, network changes solve interception, updates solve version gaps, and a log review tells you which one applies before you spend time on the wrong fix.

Edge Cases: Region Locks, LTSC Builds, and Broken Store Installs

Region matters more than most guides admit. The msstore source resolves to a regional Store endpoint, and on some networks in some regions the endpoint returns a certificate chain that differs from the pinned value because of local content-delivery routing. If you've recently changed your Windows region setting or you're travelling, switching back to your home region in Settings under Time & Language can restore the expected certificate path.

LTSC and Server builds are the second edge case. These editions ship without the Microsoft Store, and while WinGet can be installed, the msstore source depends on Store infrastructure that may be absent or partially present. On those systems, expect 0x8a15005e to persist and treat the winget community source as your package route. Microsoft's WinGet documentation is explicit that the Store source requires the Store components.

A genuinely broken Store install is the third. If the Store app itself won't open and Winget fails on the same endpoint, the underlying Store components need repair before Winget will work. Running the Windows Store Apps troubleshooter from Settings under System and Update can rebuild the component registration. Do that before repeating the source reset, because a broken Store will re-break the source on the next update.

Finally, watch for multiple Winget installations. If you've installed Winget manually alongside the Store version, you can end up with two source configurations and commands hitting the wrong one. Running where winget in a terminal shows which executable resolves first; if it points somewhere other than the expected WindowsApps path, remove the stray install before troubleshooting further.

Prevent the Error From Returning After a Windows Update

Windows feature updates sometimes reset App Installer to a bundled version, which can roll back the source definition to an older thumbprint. The symptom is the error reappearing after a major update on a machine that was fine before. The fix is the same reset sequence, but the prevention is to check winget --version after each feature update and update App Installer if the version regressed.

Source definitions also drift if you use multiple package managers that touch Winget's configuration. Some configuration-management tools rewrite source entries, and a tool that writes an old endpoint or an old thumbprint will reintroduce the mismatch. If you manage machines at scale, pin the App Installer version through your deployment tooling and verify the msstore source argument after any configuration push.

Don't disable the certificate check to make the error go away. There's no supported switch to skip it, and any workaround that claims to bypass the comparison is either wrong or removes a security control. The pinned certificate is protecting you from a redirected package source; fixing the mismatch is the right response, not defeating the check.

Keep one habit that catches this early. Run winget source update as part of your normal maintenance, maybe once a month. It refreshes the source definitions and applies any certificate changes before they cause a failure at an inconvenient moment. It takes seconds and prevents the surprise.

FAQ

Does error 0x8a15005e mean my PC has a virus or a corrupted Windows install?

No. It's a certificate-comparison failure inside WinGet, and it says nothing about malware or system corruption. The most common cause is a stale source registration that stores an outdated certificate thumbprint. Run winget source reset --force and re-add the msstore source before considering any repair of Windows itself.

Why does the Microsoft Store website load fine in my browser but Winget still fails?

Your browser validates the certificate through the normal Windows certificate chain and accepts a rotated or proxy-substituted certificate. Winget compares the presented certificate against a thumbprint pinned in its source configuration, so a valid-but-different certificate still fails. Browser success and Winget failure together point to either a stale pinned value or TLS interception.

Can I fix this by turning off my antivirus?

You can test that theory by temporarily pausing HTTPS scanning, but turning off protection is not a fix. The durable solution is to exclude storeedgefd.dsx.mp.microsoft.com from TLS inspection in the security product's settings. If the product belongs to your employer, ask IT rather than disabling it yourself.

Is the msstore source required, or can I just use winget?

The winget community source and the msstore source are separate. If you only install apps available in the community repository, you can remove msstore and avoid the error entirely. But Store-only apps, including many Microsoft-published ones, require the msstore source, so removing it narrows what you can install.

How long does the source reset take?

The full remove, reset, re-add, and update sequence runs in under two minutes on a normal connection. Most of that time is the final source update fetching metadata. If it hangs past a few minutes, a proxy or firewall is blocking the endpoint, and the problem is network-level rather than local.

Will reinstalling Windows fix it?

Reinstalling is unnecessary and won't help if the cause is a proxy, a security suite, or a network that intercepts TLS. Those conditions survive a reinstall. Confirm the cause with the Winget log first; a five-minute log review is far cheaper than a rebuild and usually identifies the exact certificate that was rejected.

Does this error affect other Winget sources like the community repository?

It can, if the same stale-thumbprint or interception condition affects those endpoints. The msstore source fails most visibly because its certificate is pinned and rotates. Running winget source update refreshes all registered sources at once, so the same sequence clears the condition wherever it appears.

What if the error persists after every step here?

A persistent failure after a clean reset, a Winget update, and a test on a different network points to managed-device policy or a security product you can't configure. Collect the Winget diagnostic log lines around the error code and send them to your IT administrator or the security vendor's support, naming the endpoint and the certificate subject shown in the log.