I know this error is maddening — you've got a cert that looks perfectly valid in the store, yet Windows throws 0x80090327 at you like it's never seen the thing before.
The fix that actually works
99% of the time, this is a missing root or intermediate CA in the machine's certificate store. The server on the other end is sending a leaf cert whose chain Windows can't complete. Install the missing piece and the error vanishes.
First, figure out what's actually missing. Open an elevated Command Prompt and run:
certutil -verify -urlfetch C:\path\to\yourcert.cerRead the chain output carefully. You'll usually see something like Error Verifying Cert: CERT_TRUST_IS_UNTRUSTED_ROOT or CERT_TRUST_IS_PARTIAL_CHAIN. That tells you whether the root or an intermediate is the problem.
If it's the root CA, grab the .cer file from the issuer's website (DigiCert, Sectigo, Let's Encrypt ISRG Root X1, etc.) and install it like this:
certutil -addstore -f Root "C:\path\to\root.cer"If it's an intermediate, it goes in the CA store instead:
certutil -addstore -f CA "C:\path\to\intermediate.cer"For a GUI route: certlm.msc → Trusted Root Certification Authorities → Certificates → right-click → All Tasks → Import. Same for Intermediate Certification Authorities.
Once installed, re-run certutil -verify. If the chain now shows a clean tree with no error flags, you're done. Restart the service that was failing — IIS, SQL Server, whatever app was making the outbound HTTPS call.
Why this works
Windows validates every TLS connection by walking the certificate chain from leaf to root. The leaf cert is signed by an intermediate, which is signed by a root. If any link is missing from the local machine's stores, Schannel (Windows' TLS engine) can't verify the chain, and it fires back SEC_E_CERT_UNKNOWN — literally "I don't know this certificate."
Big gotcha: installing the cert in the Current User store doesn't help. Services like IIS, SQL Server, and most background apps run under service accounts and read from the Local Machine store. That's why certlm.msc isn't the same as certmgr.msc, and why people install a root CA "successfully" and still get the error.
Second gotcha: the server you're connecting to might be sending an incomplete chain. This is common with misconfigured nginx or Apache servers that forget to include the intermediate in their bundle. Run an SSL Labs test on the endpoint. If it warns about chain issues, the fix isn't on your end — it's on theirs. But you can work around it by installing the missing intermediate locally.
Less common variations
Self-signed certs on internal apps. If a dev shipped a self-signed cert and told everyone to "just trust it," the root is the cert itself. You need to add it to Trusted Root on every machine that talks to the app. There's no shortcut here — domain-joined machines can push it via Group Policy under Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities.
The cert expired but the error lies. Windows sometimes reports SEC_E_CERT_UNKNOWN when the real problem is CERT_E_EXPIRED buried deeper. Always check the NotAfter date. A quick PowerShell check:
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\path\to\cert.cer")
$cert.NotAfter
$cert.Verify()Clock skew. If a VM's clock drifted more than 5 minutes, cert validation fails spectacularly. I've seen this bite people after a snapshot restore on Hyper-V. Run w32tm /resync and confirm the time is right. It sounds stupid until it happens to you at 2 AM.
Group Policy blocking third-party roots. Some hardened environments have Turn off Automatic Root Certificates Update enabled, which means Windows won't fetch missing roots from Microsoft's update service. Check HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot for a DisableRootAutoUpdate value of 1.
Proxy doing TLS inspection. Corporate proxies that MITM TLS will present their own cert. If the proxy's root CA isn't in the Local Machine store, every outbound HTTPS call from a service will fail with this code. This one's nasty because your browser works fine (user store has the cert) but the service doesn't.
Preventing it next time
Automate chain validation in your monitoring. A simple scheduled task running certutil -verify against your critical endpoints will alert you before the cert expires, not after.
When you deploy a cert, always ship the full chain: leaf + intermediate, in the correct order. Never make clients chase down your intermediates.
Keep the authroot update enabled. Microsoft pushes new roots regularly, and disabling that feature is how you end up with stale trust stores six months down the line.
And for the love of uptime — check your service account's certificate store, not yours. That's the one that matters.