0X80091005

CRYPT_E_UNEXPECTED_ENCODING (0x80091005) – Quick Fix & Why

Cybersecurity & Malware Intermediate 👁 9 views 📅 May 27, 2026

This error pops up when Windows can't parse a certificate's encoding. The fix is deleting corrupted certificate stores. Here's why that works.

You're not crazy – this error is cryptic by design.

0x80091005 shows up in Outlook, Windows Update, or Internet Explorer when Windows can't decode a certificate's encoding. The message gives you nothing useful. But the fix is straightforward: delete the corrupted certificate store that's causing the parsing failure.

The Fix – Clear the Corrupted Store

  1. Press Win + R, type certmgr.msc, and hit Enter.
  2. In the left pane, expand Intermediate Certification AuthoritiesCertificates.
  3. Look for any certificate with a yellow warning icon or one that shows "Windows cannot verify the digital signature". Sort by "Intended Purposes" to spot Code Signing or Time Stamping certs that fail.
  4. Right-click the offending certificate → Delete. Confirm if asked.
  5. Also check Trusted Root Certification AuthoritiesCertificates for the same issue.
  6. Restart the app that threw the error.

On Windows 10/11, you can also run this from an admin PowerShell to nuke the entire Intermediate store (nuclear option – use only if the manual step fails):

Get-ChildItem -Path Cert:\CurrentUser\CA | Remove-Item

Why This Works

What's actually happening here is that Windows stores certificates in local databases (stores). When a certificate's ASN.1 encoding gets corrupted – maybe from a bad download, a partial system update, or a third-party tool that mucked with the store – the cryptographic API (CAPI2) can't decode it. The error code 0x80091005 maps to CRYPT_E_UNEXPECTED_ENCODING, which literally means "the data wasn't in the format I expected."

Deleting the offending certificate removes the corrupted blob. The next time the app needs that certificate, Windows fetches a fresh copy from the issuing CA (via the automatic update mechanism). No more broken encoding. It's safe because Windows rebuilds missing certificates on demand – you're not breaking anything permanent.

Less Common Variations

Outlook encounters this with encrypted email

When you get 0x80091005 in Outlook 2016/2019/365 while opening an encrypted mail, the problem is usually a corrupted S/MIME certificate in your personal store. Fix: go to File → Options → Trust Center → Trust Center Settings → Email Security, and under Digital IDs, remove and re-add your certificate.

Windows Update throws the error

If Windows Update fails with 0x80091005, the culprit is often a corrupted root cert for Microsoft's update servers. Run certmgr.msc, navigate to Trusted Root Certification Authorities → Certificates, and delete any cert issued by Microsoft Root Authority that has an expiry date in the past or a missing icon. Then run wuauclt /detectnow to trigger a refresh.

After installing a self-signed cert or corporate CA

IT admins sometimes push broken certificates via Group Policy. The encoding mismatch happens when the cert was exported with wrong encoding (DER vs Base64) or truncated. Re-import from the original source with correct encoding – use certutil -importPFX if it's a PFX file.

Prevention

  • Don't let third-party software manage your certificate store. VPN clients, antivirus, and browser toolbars love to inject their own certs. They often mess up the encoding. Uninstall any software that modifies certs without your consent.
  • When exporting certificates, always choose "DER encoded binary" (.cer) unless you specifically need Base64. The DER format is less prone to encoding errors during transfer.
  • Keep Windows updated. Microsoft releases monthly root certificate updates via KB. An outdated store can have expired or malformed entries that trigger this error.
  • If you're an admin deploying certs via GPO, test on a single machine first. One broken cert in a GPO can hit every user in the domain. Use certutil -verify to validate the file before bulk deployment.
Pro tip: Use certutil -store -user -v My from an admin prompt to dump your personal store and look for any cert with an empty or garbled Signature Algorithm field – that's a dead giveaway for corrupted encoding.

Was this solution helpful?