Fix CRYPT_E_OID_FORMAT (0X80091003) in Windows

Quick answer

For advanced users: delete the offending certificate from the store or clear the CryptnetUrlCache, then reimport the .cer file. Use certutil -delstore or manually remove files in C:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache. Reboot after.

Now for everyone else: this error shows up when Windows tries to read a certificate that has a broken object identifier (OID). The OID is a numeric string that tells Windows what kind of certificate it's dealing with — like a version number for certificate types. If that string is malformed — missing a dot, containing letters, or just garbled — Windows throws 0X80091003 and refuses to use the certificate.

You'll see this in a few places: when you try to install a driver, when you open a program that checks its own digital signature, or during Windows Update. It can also appear in the Event Viewer under Application logs, with source Microsoft-Windows-CertificateServicesClient-CertEnroll.

The typical trigger is a certificate that was exported from a non-Windows system (like a Linux server) or generated by a tool that didn't follow the OID formatting rules. Sometimes it's a corrupted cache entry — Windows remembered a bad download and keeps choking on it.

Before you start

Back up your certificates. Open certmgr.msc, go to the affected store (usually Personal or Trusted Root), select the cert, right-click, choose All Tasks → Export, and save it as a .pfx file. That way you can restore it if something goes wrong.

Also, close any apps that might be using the certificate. The fixes below may temporarily break something that relies on that cert, so you don't want it in use.

Fix 1: Clear the CryptnetUrlCache (most common)

This cache holds temporary certificate downloads. A corrupted entry here is the #1 cause of this error.

1. Press Win + R, type services.msc, press Enter.
2. Find Cryptographic Services in the list. Right-click it and choose Stop. Leave the window open — you'll restart it later.
3. Open File Explorer and paste this path into the address bar:
   %windir%\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache
4. You'll see two folders: Content and MetaData. Select everything in both folders and delete it. You may get a “file in use” error — that's fine, skip those files.
5. Go back to the Services window, right-click Cryptographic Services, choose Start.
6. Reboot your computer.

After the reboot, try the operation that gave you the error again. In about 60% of cases, this clears it. If it doesn't, move to Fix 2.

Fix 2: Remove and reinstall the certificate

If you know which certificate is causing the problem, delete it and reimport it. If you don't know, check the Event Viewer for the thumbprint of the offending cert.

1. Open Event Viewer (eventvwr.msc), go to Windows Logs → Application.
2. Look for an error with source CertificateServicesClient-CertEnroll or CAPI2. The message will contain 0X80091003 and often a certificate thumbprint.
3. Write down that thumbprint — it's a long hex string.
4. Open Command Prompt as administrator.
5. Run this to find the store:
   certutil -store -v and look for your thumbprint in the output. It'll tell you which store it's in (e.g., My for Personal, Root for Trusted Root).
6. Once you know the store, delete it. Replace StoreName with the actual name and Thumbprint with your value:
   certutil -delstore StoreName Thumbprint
7. Reimport the certificate. If you have a .cer file, double-click it and choose Install Certificate. Place it back in the same store.
8. Reboot.

If you don't have the thumbprint, you can try the brute-force approach: export all certificates in the Personal store, delete them all, then reimport one by one. Yes, it's tedious, but it works.

Fix 3: Reset the certificate store (last resort)

This is heavy-handed and will wipe all your personal certificates. Only do this if you're sure you can restore everything.

1. Open an elevated Command Prompt.
2. Run certutil -delstore My to delete all personal certificates.
3. Run certutil -delstore Root to delete all trusted root certificates.
4. Then use Windows Update to re-download the trusted roots: go to Settings → Update & Security → Windows Update and check for updates.
5. Reinstall the certificates you need from your backups.

Only do this if Fix 1 and Fix 2 didn't work. It's invasive, but it clears every corrupted OID in the store.

Alternative: Use PowerShell to remove a specific cert

If you prefer PowerShell over certutil, you can do this:

Get-ChildItem Cert:\CurrentUser\My | Where-Object {$_.Thumbprint -eq "THUMBPRINT_HERE"} | Remove-Item

Replace THUMBPRINT_HERE with the actual value. This is faster if you know the thumbprint and the store location.

Prevention: avoid this in the future

The root cause is almost always a certificate that was created by a tool that didn't follow the ASN.1 OID encoding rules. If you're generating certificates yourself, use OpenSSL with proper config files, or use Windows' built-in New-SelfSignedCertificate cmdlet. Don't hand-edit .cer files in a text editor — that's a surefire way to corrupt the OID.

Also, keep an eye on the CryptnetUrlCache. If you see this error regularly, it might be worth disabling the automatic certificate download from Windows Update: In gpedit.msc, go to Computer Configuration → Windows Settings → Security Settings → Public Key Policies, and set “Certificate Services Client – Auto-Enrollment” to disabled. But that's a trade-off — you lose auto-updates for root certs.

If you're on a corporate network, talk to your IT admin. They might have a rogue certificate in the registry that needs to be cleaned out. This error can also happen after a bad group policy deployment that pushes a malformed OID.

The real fix is to never let a malformed OID into your store. But when it happens, the steps above will get you back up and running in under ten minutes.