Quick answer
Import the root CA certificate into the NTAuth store on every domain controller, then force a replication.
What's actually happening here
You're trying to log on with a smart card, and Windows throws SEC_E_PKINIT_CLIENT_FAILURE (0x80090354). The message says the certificate isn't trusted, but that's a half-truth. The real problem is usually one of two things: the certificate chain is incomplete, or the certification authority (CA) that issued your smart card cert isn't listed in the NTAuth store in Active Directory.
When you present a smart card cert for Kerberos PKINIT, the domain controller (DC) doesn't just check that the cert is valid. It checks that the CA is trusted by the domain. That trust is defined by the NTAuth store, which is a container in AD holding CA certificates that are allowed to issue smart card logon certs. If your CA isn't there, the DC treats the cert as untrusted, even if the chain looks fine from the client's perspective.
I've seen this most often after a CA migration, or when someone stands up a new subordinate CA and forgets to publish it. The client side looks fine—the cert shows as trusted in certmgr.msc—but the DC still says no.
Fix steps (main solution)
- Identify the issuing CA. On the client, open the smart card cert and look at the Issuer field. You need the root CA and any intermediate CAs in the chain.
- Check the NTAuth store. On a DC, run
certutil -viewstore -enterprise NTAuth. If you don't see your CA's certificate, that's your problem. - Add the CA to the NTAuth store. You can do this with
certutil -dspublish -f <CAcert.cer> NTAuthCA. Export the CA cert first from the CA's web enrollment page (http://<CA>/certsrv) or from the CA server itself. - Force replication. Run
repadmin /syncall /AdePon the DC to push the change out. Don't wait for the usual 15-minute cycle if users are blocked. - Test again. Try the smart card login. If it still fails, run
certutil -scinfoon the client to confirm the chain is intact.
Alternative fixes if the main one doesn't work
Check the certificate's EKU
The cert must have the Smart Card Logon application policy (OID 1.3.6.1.4.1.311.20.2.2). If it only has Client Authentication, Kerberos will reject it. Re-issue the cert with the right template.
Verify the chain on the DC
Run certutil -verify <certfile.cer> on the DC. If it complains about a missing intermediate, you need to publish that intermediate to the NTAuth store too. The root alone might not be enough if your chain has a two-tier CA structure.
Check the DC's own trust
Sometimes the DC's local certificate store is missing the root. That's rare but happens. Import the root into the Trusted Root Certification Authorities store on each DC manually, then retry.
Prevention tip
This error is almost always a deployment miss. When you set up a new CA, make it a habit to publish it to the NTAuth store before you issue smart card certs. Put it in your CA deployment checklist. Also monitor the NTAuth store periodically—use a scheduled script that exports the store and compares it to your expected CAs.
The reason step 3 works is that the NTAuth store is the authoritative source for the domain. Once the DC sees the CA there, it stops complaining about trust and moves on to validating the actual user credentials. If you skip this, you'll keep chasing phantom trust issues on the client side that don't exist.