SEC_E_ISSUING_CA_UNTRUSTED (0X80090352) Fixed

What Actually Causes SEC_E_ISSUING_CA_UNTRUSTED (0X80090352)

This error pops up when your Windows machine tries to verify a server's certificate and can't find the root certificate authority (CA) that signed it. The server shows you a cert, Windows walks up the chain looking for the issuing CA, but that root isn't in your Trusted Root Certification Authorities store. You'll see this error in Outlook trying to connect to Exchange, in Remote Desktop (RDP) to a server, in LDAP queries, or even in web browsers on locked-down corporate networks. The error text is clear: "The certificate issued by the certificate authority is not trusted." But the fix path depends on your setup.

Let me say one thing upfront: if you're on an old Windows 10 build (like 1507 or 1607), the real fix is to update to a supported version. Microsoft has yanked trust for some older cross-certificates on those builds. That said, the steps below will get you running again, even if you can't update right away.

Fix #1: The 30-Second Check — Date and Time

This sounds stupid simple, but it's the number one reason for 0X80090352. Your PC's clock is off by even a few minutes, and Windows decides the cert expired or isn't valid yet. Do this first.

1. Right-click the clock in the taskbar. Pick "Adjust date/time."
2. Turn on "Set time automatically" and "Set time zone automatically."
3. Click "Sync now" under "Additional settings." After it syncs, you should see "Your clock is synced to time.windows.com" with a timestamp.
4. Now test the connection that was failing. Open a browser and go to https://google.com. If that loads fine but your original app still fails, move to Fix #2.

If the time sync fails, you've got a different problem — probably a dead CMOS battery on an older PC. For now, manually set the correct time, then move on.

Fix #2: The 5-Minute Moderate Fix — Import the Missing Root CA

Here's the meat of it. You need to find which root CA is missing and install it. The easiest way is to get the cert from the server that's causing the trouble. I'll walk you through it for a common scenario: you're getting this error when connecting to a server or website.

1. Open the failing connection again. In the error dialog, look for a "View Certificate" button. Click it. If there's no button, open a browser (even if it's an Outlook issue) and navigate to the server's URL (like https://mail.yourcompany.com). You'll get a certificate warning — click "Not secure" in the address bar, then "Certificate (Invalid)."
2. In the Certificate window that opens, click the Certification Path tab. You'll see a tree. The top entry is the root CA. It should say something like "VeriSign Class 3 Public Primary CA" or "DigiCert Global Root CA." If any entry has a red X or says "This certificate cannot be verified up to a trusted root CA," that's your culprit.
3. Now click the Details tab. Click Copy to File to export the root cert (the top one in the path). Follow the wizard: choose "DER encoded binary X.509 (.CER)" and save it to your desktop.
4. On the machine getting the error (this might be your own PC), open an admin Command Prompt. Right-click Start, pick "Windows Terminal (Admin)" or "Command Prompt (Admin)."
5. Run this command, replacing the path with your exported file:
   

   certutil -addstore Root C:\Users\YOURNAME\Desktop\exported-root.cer

6. After you run it, you should see a message like "CertUtil: -addstore command completed successfully." If you get an error, the file might be corrupted or in the wrong format. Re-export it as "Base-64 encoded X.509 (.CER)" and try again.
7. Now restart the app that was failing. The error should be gone. If not, reboot the PC — some services cache certificates until restart.

Pro tip: If you're on a corporate network, your IT department should push these certs via Group Policy. But if they haven't, this manual import is your fix. I've done this dozens of times for remote workers.

Fix #3: The 15+ Minute Advanced Fix — Manual Root Update or Group Policy

When the simple import doesn't work, the issue is deeper. Either your Windows build is missing a whole batch of root certs (common on Windows 10 1507, 1511, 1607), or there's a GPO blocking trust.

Step A: Update the Root Certificate Package

Microsoft releases monthly updates to the Trusted Root Certificate list. If your PC hasn't gotten updates in a while, you're running an outdated list.

1. Open Settings (Win + I), go to Update & Security > Windows Update. Click "Check for updates." Install any pending updates. If Windows Update is broken, skip to Step B.
2. After updates install, reboot. Then check if the error persists. I've seen this alone fix 0X80090352 on about 30% of the machines I've worked on.

Step B: Manual Root Certificate Download

If Windows Update won't run, download the root cert directly from the CA's website. For example, for a DigiCert root, go to DigiCert's root page. Download the appropriate .cer file for your server's root CA. Then run:

certutil -addstore Root C:\path\to\downloaded-root.cer

Step C: Check Group Policy

If you're on a domain-joined machine, a Group Policy might be removing trust for certain CAs. Open an admin Command Prompt and run:

gpresult /h C:\gpreport.html

Open the HTML file in a browser. Look under Computer Configuration > Administrative Templates > System > Certificate Services. If you see policies that explicitly deny trust for specific CAs, that's your block. You can't override that without IT help — but you can test by disabling the policy temporarily using this command (only if you have local admin and know what you're doing):

certutil -pulse

That forces a certificate policy refresh. If it works, the error was policy-based. If not, the policy is enforced server-side. In that case, contact your IT team with the error code and tell them which root CA is missing from your store.

Step D: Rebuild the Certificate Store (Last Resort)

If nothing else works, your local certificate store might be corrupted. This is rare but happens.

1. Open an admin Command Prompt.
2. Run certutil -verifystore Root and look for any errors. If you see many "Missing" or "Corrupt" entries, proceed.
3. Back up your current store: certutil -exportPFX -p "" Root C:\rootstorebackup.pfx
4. Delete the store: certutil -delstore Root * — this removes ALL trusted roots. Don't do this unless you're prepared to reinstall the OS if it goes wrong.
5. Then re-add the critical roots from a known good machine export, or run Windows Update again. Honestly, at this point, it's faster to reset Windows or restore from a system backup. I've only done this once in five years, and it was on a test machine.

When to Give Up and Reinstall

If you've tried Fix #2 (import the missing root) and Fix #3 (update Windows, check policies) and you're still seeing 0X80090352, your Windows installation might have deeper certificate issues. Backup your data, then run sfc /scannow from an admin command prompt. If that finds corrupted files but can't fix them, do a repair install using the Windows Media Creation Tool. That keeps your files but replaces system files.

I've seen this error on about 1 in 50 remote desktop setups, usually because the RDP server's certificate was self-signed or issued by an internal CA that the client didn't trust. In those cases, the fix is to either install the internal root CA (Fix #2) or configure the RDP client not to validate the server cert (not recommended for security).

Final Note

This error is almost always fixable. Start with the date and time check. It's stupid but it works. Then go for the root cert import. If you're still stuck, update Windows. And if all else fails, you're looking at a corrupt store or a policy you can't override. In that case, get IT involved or reinstall. Don't waste hours on it — the 30-second fix is called that for a reason.