Fix CRYPT_E_NO_MATCH (0x80092009) on Windows 10/11

You're staring at CRYPT_E_NO_MATCH (0x80092009) and the message "Cannot find the requested object." It pops up during Windows Update, when you open a PowerShell module, or sometimes right after a clean install. What's actually happening here is Windows needs a specific certificate to verify something, and it can't locate it in the certificate store. The store isn't broken, it's just missing one piece.

This error has a habit of appearing in three common places: Windows Update (especially after a failed update), the PowerShell console via the PSReadLine module, and during Office or .NET installs. The triggers differ, but the root cause is always the same: a lookup into the certificate store fails because the target certificate isn't there.

Here's the thing: you don't need to nuke your system. The fixes below go from a 30-second registry tweak to a full certificate store rebuild. Stop at the first one that works. Don't skip ahead and spend 15 minutes rebuilding if a quick registry change solves it.

Fix 1: 30-Second Registry Tweak (Windows Update only)

If this error shows up during Windows Update, the culprit is often a stale update key. Windows Update is looking for a certificate that matches an old update entry. The fastest fix: clear the update history.

1. Press Win + R, type regedit, and hit Enter.
2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate.
3. Find the AccountDomainSid and SusClientId values. Right-click each and delete them.
4. Close the registry editor and restart the Windows Update service: open Command Prompt as admin and run net stop wuauserv then net start wuauserv.

The reason step 3 works is that those registry values are tied to the client's update identity. When they go stale, Windows Update tries to resolve them against a certificate that no longer exists, and you get 0x80092009. Deleting them forces a fresh registration on the next update scan.

This fix only helps if the error is tied to Windows Update. If you're seeing it in PowerShell or during an app install, skip straight to Fix 2.

Fix 2: 5-Minute PowerShell Repair (PSReadLine and general cases)

I've seen this error more times than I'd like in PowerShell, specifically when the PSReadLine module fails to load. What's actually happening is the module's signing certificate isn't found, and the console throws CRYPT_E_NO_MATCH before you even get a prompt.

The fastest fix is to reinstall the module. This takes about five minutes, and it's safe—you won't lose your profile or history.

1. Open a regular Command Prompt (not PowerShell) as administrator.
2. Run powershell -ExecutionPolicy Bypass to launch PowerShell with restricted execution policy lifted.
3. Install the latest PSReadLine:

   Install-Module -Name PSReadLine -Force -SkipPublisherCheck

4. Close and reopen PowerShell.

The -SkipPublisherCheck flag is the trick. Without it, the installer tries to verify the module's Authenticode signature, and that verification process hits the same missing certificate. Skipping the publisher check bypasses the broken lookup entirely. You're replacing the module with a fresh copy that carries its own valid certificate, so future loads won't fail.

If PSReadLine isn't your issue, run Get-AuthenticodeSignature on the file that's throwing the error. That'll tell you if it's a signing problem. For instance, if you downloaded a script and it's unsigned, the error could appear when you try to run it. In that case, right-click the file > Properties > check "Unblock"—that clears the Mark-of-the-Web flag.

Fix 3: Rebuild the Certificate Store (15+ Minutes)

When the first two fixes don't work, the certificate store itself is corrupted. This is rare, but it happens—usually after a failed Windows update or a botched security software uninstall. The store's index gets out of sync, and any lookup returns 0x80092009.

You can't just "rebuild" the store with a button. What you can do is reinstall the Microsoft Root Certificate Program updates. Here's the 15-minute route:

1. Download the latest root update package from Microsoft. As of this writing, it's available at KB931125. You'll want the one for your OS version.
2. Run the downloaded package. It'll ask to install the certificates into the root store—allow it.
3. After it completes, open an elevated Command Prompt and run certutil -store Root. Check that the list looks populated. If you see "The store is empty," that's your smoking gun.

But wait—if the root store is completely empty, the package might not install correctly because it also relies on existing certificates. That's when you do the manual rebuild:

• Open certmgr.msc.
• Right-click Trusted Root Certification Authorities > All Tasks > Import.
• Browse to C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\CertificateStore and import any .cer files you have. If you don't have backups, this won't help—and you'll need to pull certificates from another machine.

In practice, I've only had to do this on machines that went through a malware cleanup where the cleaner nuked the root store. If that's your situation, you're better off using a system restore point before the corruption happened. Check if you have one: System Restore from the Start menu, then pick a point from before the error started.

When to Skip All This

If 0x80092009 appears in a specific application (like Office or a VPN client), the app's own certificate is missing, not the whole store. In that case, reinstalling the application usually fixes it. The error is a symptom, not the disease.

Also, if your system clock is wrong, certificate validation fails because certificates have validity windows. Fix the date and time first, then reboot. You'd be surprised how often that's the actual problem.

The real fix is almost always Fix 2, in my experience. But the 30-second registry tweak is worth trying first because it's harmless. And if you're dealing with a corrupted store, you'll know within a minute—because certutil -store Root will show something odd.

Don't waste time running SFC /scannow or DISM for this. They scan system files, not the certificate store. I've seen people spend an hour on those checks with zero result. Stick to the order above.