Fix STATUS_ISSUING_CA_UNTRUSTED 0XC000038A

Yeah, this one's annoying. You're trying to connect to a service — maybe an RDP session, an Exchange server, or an LDAPS connection — and Windows just slams the door with 0XC000038A. The connection fails, logs show nothing helpful, and you're left staring at the screen. Let's fix it.

First, Grab the Missing Certificate

The core problem: the server you're hitting uses a certificate issued by a Certificate Authority (CA) that your client machine doesn't trust. That CA could be an internal enterprise CA or a third-party intermediate CA that's missing from your trusted store.

Log into the server or service that's generating the error. Open a browser or use certlm.msc (Local Machine certificate store).
Find the certificate being presented. For RDP, it's under Remote Desktop. For IIS, look under Web Hosting. For Exchange, check the SMTP or IIS bindings.
Export that certificate as a .cer file. Don't include the private key. Just the public cert.
Open that .cer file. Go to the Certification Path tab. You'll see the chain: Root CA -> Intermediate CA -> Server cert. One of those will have a red X or say "This certificate is not trusted."
That's your culprit. Export the issuing CA certificate (the one right above the server cert in the chain). Again, just the .cer.

Second, Import the Root CA into the Trusted Store

Now you need to drop that certificate into the correct store on the client machine. Here's the only reliable way:

certlm.msc

Open that (Local Machine, not Current User). Right-click Trusted Root Certification Authorities -> All Tasks -> Import. Browse to the .cer file you exported. Complete the wizard. Reboot the client machine.

If the issuing CA is an intermediate CA (not the root), you import it into Intermediate Certification Authorities instead. But 9 times out of 10, the root CA is missing. Start there.

Why This Works

Windows uses a chain validation model. When a server presents a certificate, Windows walks up the chain to the root. If any CA in that chain isn't in the Trusted Root store, the chain is broken. Error 0XC000038A is Windows saying, "I can't verify the top of this chain, so I'm not trusting anything below it."

Most internal CAs distribute their root cert via Group Policy or auto-enrollment. But if the client isn't domain-joined, or the CA was installed after the client was built, you get this error. For third-party certs (like Comodo or DigiCert), the root is usually already in Windows. But intermediate CAs aren't always included — especially if the service is using a newer intermediate that hasn't been pushed via Windows Update yet. Exporting the full chain from the server side and importing it on the client solves both cases.

Less Common Variations

Missing Intermediate CA

If you import the root CA and still get the error, check the chain again. Some servers present a cert signed by an intermediate that isn't in the client's store. This happens a lot with Exchange 2016's self-signed cert + internal CA setups. Import the intermediate into Intermediate Certification Authorities under the Local Machine store.

Certificate Revocation Check Failure

Sometimes the error is actually a CRL check timeout, not a trust issue. The client can't reach the CA's CRL distribution point (CDP). If you've already imported the root and intermediate, test by disabling CRL checking temporarily:

certutil -setreg chain\ChainFlags 0x10

Then reboot and test. If the error goes away, you know the CDP URL is unreachable. Fix that by ensuring the client can resolve the CDP URL in the cert. You'll see those URLs on the Details tab of the server certificate. Firewall or DNS issues are common here.

NTLM Authentication Conflict

Rare, but I've seen it. When using RDP with an RD Gateway, the gateway presents its cert. If the client doesn't trust it, you get 0XC000038A. The fix is still the cert import, but double-check you're importing into the Local Machine store on the client, not the Current User store. RDP services run as SYSTEM and only check the machine store.

Prevention for Next Time

Deploy your internal root CA via Group Policy to all domain-joined machines. Put it in both Trusted Root Certification Authorities and Intermediate Certification Authorities. This covers 90% of future cases.
For non-domain clients, script the import using certutil or PowerShell. Here's a quick one-liner to import a root CA from a network share:

certutil -addstore Root \\fileserver\certs\myRootCA.cer

Keep Windows updated. Microsoft pushes third-party root CA updates through Windows Update. Clients that are months behind on patches might lack newer intermediates.
Use a public CA when possible for external-facing services. It saves you from managing internal CAs on every client. But if you're stuck with an internal CA, the Group Policy route is your best bet.

That's it. Import the missing CA, reboot, and you're done. This fix has worked for me across Windows 10, 11, Server 2016, 2019, and 2022. It's the same problem every time — just a different missing cert.