CRYPT_E_ISSUER_SERIALNUMBER (0x8009100D): Fix Invalid Cert
Your PC or server can't validate a certificate's issuer or serial number. Usually a time/date mismatch or corrupted cert store. We'll fix it.
The 30-Second Fix: Check Your System Clock
I can't count how many times I've walked into a small office, seen this error pop up in Outlook, IIS, or a custom app, and the fix was literally staring them in the face — their system clock was off by more than 5 minutes. Certificates are time-sensitive. If your PC thinks it's 2019 or next Tuesday, the issuer serial number won't validate.
Look at the clock in your taskbar. Right-click it, pick "Adjust date/time." Turn on "Set time automatically" and "Set time zone automatically." If it's already on, turn it off, wait 10 seconds, and turn it back on. This forces a sync with time.windows.com. Had a client last month whose entire exchange server stopped sending mail because the motherboard battery was dead — clock reset to 2001. New battery, instant fix.
If you're in a domain environment, run w32tm /resync in an admin command prompt to force a sync with the domain controller. That's it. If the error's gone, you're done. If not, move on.
The 5-Minute Fix: Clear and Re-Enroll Problem Certs
If the clock was fine, the next culprit is a corrupted certificate in the Windows cert store. This happens a lot with self-signed certs or expired internal CA certs. Here's the practical route:
- Hit Win + R, type
certlm.msc(for local machine) orcertmgr.msc(for current user), and press Enter. - Expand Personal > Certificates. Look for any cert with a yellow triangle or marked as expired. Right-click it and choose Delete.
- Check Trusted Root Certification Authorities > Certificates for any obviously bad root certs — usually ones with weird names or dates.
- If the error came from an app that uses a specific cert (like a client cert for a VPN or a code-signing cert), find that exact cert, delete it, and re-import the original .pfx or .cer file from a trusted backup.
Key point: Don't go deleting every cert you see. Only remove ones you know are problematic or that match the issuer/serial number in the error message. I've seen people nuke their entire store and then wonder why HTTPS breaks. Be surgical.
After cleanup, restart the app or service that threw the error. If it still fails, run certutil -store -user My in an admin command prompt and look for any certs with a serial number that looks like garbage or a date before 1970. Delete those too.
The 15+ Minute Fix: Full Cert Store Repair or Rebuild
Sometimes the damage is deeper. Malware, botched updates, or a hard crash can corrupt the entire certificate store. You'll see this error across multiple apps — Outlook, Chrome, even Windows Update. Here's the nuclear option that works:
- Scan for malware first. Run a full scan with Windows Defender Offline or Malwarebytes. I had a client whose machine was riddled with adware that mangled the root certs. Cleaned the malware, then the error vanished.
- Export and re-import trusted roots. On a working machine (same OS version), open
certlm.msc, right-click Trusted Root Certification Authorities, choose All Tasks > Export. Save as a .cer file. Transfer it to the broken machine, import it into the same store. This overwrites corrupt entries. - Reset the certificate store via command line. In an admin command prompt, run:
certutil -store -user My > C:\temp\certbackup.txt
certutil -delstore -user My "Issuer Name"
Replace "Issuer Name" with the actual issuer from the error. Then re-import the good cert from your backup.
If the store is completely toast, you can rebuild it from scratch. On Windows 10/11 and Server 2016+, run:
certutil -repairstore -user My
certutil -repairstore -user Root
certutil -repairstore -user CA
This re-enrolls missing system certs from Microsoft's trusted root program. It takes about 5 minutes. Reboot when it's done.
Last resort: System Restore to a point before the error started. If you don't have a restore point, you're looking at a repair install of Windows — but I've only had to go that far twice in 10 years.
Pro tip: If you're seeing this error on a server running IIS, check the bindings. A misconfigured HTTPS binding using a cert that's been deleted or expired is a classic cause. Open IIS Manager, click your site, right-click bindings, and either remove the bad binding or assign a valid cert.
Real talk: 90% of the time, this error is either a wrong clock or a cert that got orphaned after a renewal. Don't overthink it. Start with the clock, then check the cert store. If you're still stuck after the repair commands, post the exact error text in a forum with your OS version — someone's seen it before.
Was this solution helpful?