CRYPT_E_SELF_SIGNED (0x80092007) - Quick Fixes From 14 Years in IT

Cause #1: Wrong System Clock (This Is Your First Move)

Nine times out of ten, the culprit is your PC's clock being off by more than a few minutes. Windows uses the system time to validate certificate expiration dates. If your clock says 2015, every modern self-signed certificate looks expired. I've seen this on everything from Windows 7 to Server 2022 — especially after a CMOS battery dies or a VM boots without NTP.

How to fix it:

1. Right-click the clock in the taskbar and pick "Adjust date/time".
2. Turn on "Set time automatically" and "Set time zone automatically".
3. Click "Sync now" under Synchronize your clock. If it fails, run this from an admin command prompt:

w32tm /resync /nowait

If resync fails, your NTP client may be hosed. Reset it with:

net stop w32time
w32tm /unregister
w32tm /register
net start w32time
w32tm /resync

Reboot after this. I've also seen clock drift caused by dual-booting with Linux or macOS — they often use local time differently. Set Windows to use UTC by adding a registry key:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1

That one's saved me on HPC clusters more times than I care to count.

Cause #2: Expired or Missing Root Certificate

If your clock is fine, the problem is likely a missing or expired root certificate in the Trusted Root Certification Authorities store. Self-signed certificates don't chain up to a public CA — they stand alone. Windows treats them as untrusted by default unless you explicitly install the root. This happens a lot with:

• Internal corporate websites using self-signed certs
• Dev tools like IIS Express, ngrok, or Docker local registries
• Old software that shipped with a self-signed cert that expired

How to fix it:

1. Press Win + R, type certmgr.msc, hit Enter.
2. Look under Trusted Root Certification Authorities > Certificates for the issuer name of the cert throwing the error. If you don't see it, you need to import it.
3. Export the self-signed cert from wherever it came from (a .cer or .crt file).
4. In certmgr.msc, right-click Trusted Root Certification Authorities > All Tasks > Import. Browse to the cert file, place it in the Trusted Root store.

Don't bother installing it in the Intermediate store — that's a common mistake. It won't work. It has to be Trusted Root.

If you're in a domain environment, you can push this via Group Policy. Create a GPO under Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities. Import the certificate there. Run gpupdate /force on the affected machines. Saves you touching each box.

Cause #3: Broken Certificate Chain or Revocation Check Failing

Sometimes it's not the root itself — it's the chain. A self-signed cert might have an intermediate that's expired or a CRL distribution point that's unreachable. Windows tries to build the full chain and fails because an intermediate was issued by a self-signed root that isn't trusted. I've seen this with:

• Outlook connecting to an Exchange server using a self-signed cert — the autodiscover chain breaks
• Internet Explorer (yes, some still use it) refusing to load a self-signed HTTPS page
• PowerShell Invoke-WebRequest on a dev server

How to fix it:

1. Open the certificate in certmgr.msc — double-click it, go to the Certification Path tab.
2. You'll see a red X somewhere. Click each certificate in the path and check its validity dates.
3. If any cert is expired, you need a new one. This isn't a fix — it's a realization.
4. If the path looks fine but it still fails, disable certificate revocation list (CRL) checking temporarily to test:

certutil -setreg chain\ChainCacheResyncCycle @0
certutil -setreg chain\CheckRevocationFreshnessTime @0
net stop cryptsvc && net start cryptsvc

If that fixes it, the CRL endpoint is unreachable. Fix DNS or network routes. Don't leave revocation checking off — that's bad security. I've seen production servers running without it for months because someone took this shortcut. Don't be that person.

Quick-Reference Fix Summary

Start with the clock. I've been doing this since Windows XP, and every single time I thought "it can't be the clock" — it was the clock. Save yourself the headache.