Fix SEC_E_ISSUING_CA_UNTRUSTED_KDC 0X80090359

When does this error pop up?

You get SEC_E_ISSUING_CA_UNTRUSTED_KDC (0X80090359) when trying to authenticate to a domain — maybe during a remote desktop connection, logging into a domain-joined machine, or running a Kerberos-based app. I see this most often after a domain controller gets a new certificate, or after a Windows Update rollup that refreshes the certificate trust list. Users will see a message like "An authentication error occurred. The certificate authority that issued the KDC certificate is not trusted." The event log will log Event ID 29 or 10 under System > Kerberos.

Root cause in plain English

Kerberos uses certificates for domain authentication — that's the PKINIT protocol. When the KDC (your domain controller) presents a certificate, the client checks if the issuing Certificate Authority (CA) is trusted. If that CA's root certificate is missing, expired, or not in the right store, Windows throws this error. The usual suspects: the CA certificate wasn't added to the NTAuthCertificates object in Active Directory, or the client's local Trusted Root Certification Authorities store is outdated. Sometimes you'll also see it if the KDC certificate's Subject or SAN doesn't match the domain name properly, but 9 times out of 10 it's a trust chain problem.

Step-by-step fix

Step 1: Check if the CA certificate is published to Active Directory

On a domain controller or a machine with RSAT tools installed, open an elevated command prompt (right-click Command Prompt, choose Run as Administrator). Run this command:

certutil -viewstore -enterprise ca

You should see the CA certificate listed under NTAuth. If the command returns "The specified query was unsuccessful" or shows nothing, the CA certificate isn't published. That's your problem.

What you'll see if it works: A list of certificates with the Issuer matching your internal CA. You'll see "NTAuthCertificates" in the output.

Step 2: Publish the CA certificate to NTAuthCertificates

If the certificate was missing, run this command on your CA server (the machine running AD CS):

certutil -dspublish -f C:\Path\To\YourCACert.cer NTAuthCA

Replace C:\Path\To\YourCACert.cer with the actual path to your CA certificate file. You can export it from the CA server via Server Manager > Tools > Certification Authority, right-click the CA name, choose Properties, then the General tab, click View Certificate, and go to the Details tab to copy to file.

What you'll see after running: A message saying "Published to NTAuthCertificates container in Active Directory."

Step 3: Force replication across domain controllers

Run this on a domain controller:

repadmin /syncall /AdeP

Wait 30 seconds. Then check if the cert replicated by running Step 1 again on a different DC. I've seen cases where the cert publishes but doesn't replicate for 15 minutes — you can speed that up with repadmin /replicate if you know the source and destination DCs.

Step 4: Update the client's trusted root store

On the machine getting the error, open an elevated command prompt and type:

certutil -syncWithWU -f

That forces a download of the latest Microsoft Root Certificate Program updates. Then run:

certutil -store -group PolicyTrustedRoot

Look for your CA certificate there. If it's missing, group policy might not be pushing it. Talk to your domain admin to confirm the Trusted Root Certification Authorities policy is set under Computer Configuration > Windows Settings > Security Settings > Public Key Policies.

Step 5: Restart the Kerberos client service

On the client machine, run in an elevated prompt:

net stop kdc && net start kdc

Then clear the Kerberos ticket cache:

klist purge

Try logging in again.

Step 6: Verify the KDC certificate itself

If the trust chain is fine and the error persists, check the KDC certificate. On a domain controller, run:

certutil -viewstore -group my

Find the certificate with Intended Purpose = "Kerberos Authentication" (OID 1.3.6.1.5.2.3.5). Make sure it's not expired, and that the Subject Alternative Name (SAN) includes the domain name (e.g., dns=dc01.contoso.com and dns=contoso.com). Mismatched SAN is the second most common cause.

What to check if it still fails

If you've done all that and the error still shows, check these three things:

Group Policy refresh: Run gpupdate /force on the client, then reboot. Sometimes the policy that distributes trusted root certs doesn't apply immediately.
Certificate revocation list (CRL): If the CA is offline or the CRL distribution point is unreachable, the client might reject the KDC cert. Check the KDC certificate's CRL Distribution Point extension in the certificate properties. Make sure that URL is accessible from the client.
Smart card logon: If you're using smart cards, you might also need the CA cert in the Intermediate Certification Authorities store on the client. Deploy that via Group Policy under Public Key Policies > Intermediate Certification Authorities. I've seen this catch a lot of people.

One last thing: if you recently patched a Windows 10 or 11 machine with KB5005573 or similar, that update tightened PKINIT validation. You might need to add the CA cert to the Protected Users group's trusted roots — though that's rare. Check the Microsoft Support article for that specific update if nothing else works.