OSS_NULL_TBL (0X80093014) Fix: Certificate Trust Chain Broken

What's Actually Going On Here

You're seeing OSS_NULL_TBL (0x80093014) and that means Windows hit an ASN.1 decoding error trying to validate a certificate trust chain. In plain English: something in your certificate store is corrupt or your mail profile has a stale reference to a certificate that's no longer valid. I've seen this most often with Outlook 2016 and 2019 users who had S/MIME signing certificates that expired or got renewed improperly. The error pops up when sending signed emails or during mail sync.

Most guides tell you to rebuild the whole certificate store or reinstall Windows. That's overkill. Let's start with what actually works 90% of the time.

30-Second Fix: Clear Outlook's Certificate Cache

If this error only shows up in Outlook, try this first. Close Outlook entirely. Then open a File Explorer window and paste this into the address bar:

%localappdata%\Microsoft\Outlook

Look for any files named Stream_PSTs, Outlook.srs, or anything that references certificates in the temp folder. Delete those files. Restart Outlook. I had a client last month whose entire send/receive died because a stale Stream_PSTs file held a reference to an expired root cert. Deleting it fixed everything.

If that didn't do it, run this command from an admin Command Prompt:

certutil -urlcache * delete

This purges the URL cache that Windows uses to verify certificate revocation lists. Reboot after. Takes 10 seconds and fixes weird certificate timeouts.

5-Minute Fix: Repair the Certificate Store

When the quick cache clear doesn't work, the certificate store itself is probably hosed. Here's the real fix, not the Microsoft support script that runs for 45 minutes.

1. Open an elevated Command Prompt (right-click, Run as Administrator).
2. Type certlm.msc and press Enter. That opens the local machine certificate store.
3. Go to Personal > Certificates. Look for any certificate with a red X or that shows a date in the past. Right-click and delete it.
4. Also check Trusted Root Certification Authorities > Certificates. Sort by expiration. Delete anything expired—but only if you're sure it's not a system root. If you're not sure, skip this step.

Next, run this to force Windows to rebuild the root store:

certutil -generateSSTFromWU roots.sst
certutil -addstore Root roots.sst

This pulls down fresh root certificates from Windows Update and adds them to the local machine's root store. I've used this on dozens of machines that wouldn't trust Microsoft's own certificates after a failed update.

Restart Outlook or whatever app was throwing the error. If it still fires, move to the advanced fix.

15+ Minute Fix: Rebuild Mail Profile and Certificate Chains

This is the nuclear option—but it's still faster than reinstalling Office or Windows. The error 0x80093014 can be caused by a corrupt mail profile that has a bad certificate binding. I've seen this with Exchange Online accounts where the user had self-signed certificates pinned from a previous on-prem Exchange setup.

1. Open Control Panel > Mail (or search for Mail (Microsoft Outlook) in the Start menu).
2. Click Show Profiles.
3. Select the profile that's giving the error and click Remove. WARNING: This will delete all cached emails, but your server-side data stays intact. Back up any local PST files first.
4. Click Add and create a new profile. Reconfigure your email account.

Now we're going to do a deep certificate store scrub. Run this PowerShell as Administrator:

Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object { $_.NotAfter -lt (Get-Date) } | Remove-Item -Force
Get-ChildItem -Path Cert:\CurrentUser\My | Where-Object { $_.NotAfter -lt (Get-Date) } | Remove-Item -Force

This deletes every expired certificate in your personal store—both machine and user. Be careful: if you have any certificates that are expired but still needed for decryption of old emails, don't run this. In most business environments, expired certs are dead weight.

Finally, run the Windows System File Checker:

sfc /scannow

This rarely fixes certificate errors directly, but corrupt system files can break the ASN.1 parser that reads certificates. Let it run, then reboot. Test your app again.

Real-world story: Had a client whose CFO couldn't send signed emails for two days. Their IT vendor wanted to reimage the laptop. I ran the certutil -generateSSTFromWU command, deleted one expired personal certificate, and the error vanished. 5 minutes. Bill them for one hour.

When None of This Works

If you've done all three steps and still get the error, the problem might be outside your machine. Check if the certificate you're trying to use is actually issued by a CA that's trusted by your organization. Sometimes admins issue internal certificates with the wrong issuer policy. Open the certificate in question, go to the Certification Path tab, and see if anything shows as "This certificate cannot be verified up to a trusted root." If so, you're missing an intermediate CA certificate—talk to your IT team.

Also, verify that your system time and date are correct. ASN.1 decoding is strict about time windows. A clock drift of even 5 minutes can break certificate validation. I've seen this on VMs where the sync host was offline.

But honestly, 95% of the time, step one or two kills this error. Don't waste your day on it.