Fix 0XC000038C: Smart card cert not trusted

The fix: NTAuth store and CA trust

You're staring at STATUS_PKINIT_CLIENT_FAILURE (0XC000038C) — the smart card certificate used for authentication was not trusted. This usually pops up when a user tries to log into Windows with a smart card (or virtual smart card) but the domain controller won't accept the certificate chain. The error is specific to Kerberos PKINIT — the protocol that maps a certificate to a Kerberos ticket.

Skip the generic advice about 'renewing the cert' or 'reinserting the card'. The real culprit is almost always one of two things: the issuing CA certificate isn't in the NTAuth store, or the root/intermediate CA certificate isn't trusted on the domain controller.

First, check the NTAuth store

The NTAuth store (CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=yourdomain,DC=com) is a special Active Directory container that lists which CA certificates are allowed to issue smart card authentication certs. If your smart card cert's issuing CA isn't in here, PKINIT will reject it immediately.

# Use certutil on a domain controller or member server with RSAT tools
certutil -viewstore -enterprise NTAuth

Look for the CA certificate that issued your smart card. If it's missing, you need to add it:

# Export the CA cert (not the smart card cert) as .cer, then:
certutil -dspublish -f C:\path\to\CAcert.cer NTAuthCA

This publishes the CA cert into the NTAuth store. Wait for AD replication (or force it with repadmin /syncall), then test again.

Second, verify the CA trust on the domain controller

Even if the NTAuth store is correct, the domain controller's local machine certificate store must trust the entire chain — root CA, any intermediates. A common scenario: you're using a standalone CA or a third-party CA like Entrust or Gemalto. The root CA cert might be missing from the Trusted Root Certification Authorities store on the DC.

# On the DC, check the root and intermediate stores
certutil -store Root
certutil -store CA

If the root CA is missing, import it into the local machine's Trusted Root store. For intermediate CAs, import them into the Intermediate Certification Authorities store.

certutil -addstore Root C:\path\to\rootCA.cer
certutil -addstore CA C:\path\to\intermediateCA.cer

Restart the Kerberos Key Distribution Center service (kdc) after importing — it caches certificate chains at startup.

Why these two steps fix it

What's actually happening here is that PKINIT has a two-phase trust check. First, it looks up the smart card cert's issuer in the NTAuth store. This is a directory-level policy: domain admins decide which CAs are allowed to issue authentication certs. If the issuer isn't there, the DC won't even bother to validate the certificate chain — it immediately returns 0XC000038C.

The reason the second step matters is that, even after the NTAuth check passes, the DC must build a certificate chain to a trusted root. PKINIT uses the Schannel cryptographic provider under the hood, which validates the entire chain from the smart card cert up to a root it trusts. If any intermediate or root is missing from the local machine store on the DC, chain building fails, and you get the same error.

There's a subtle point here: the NTAuth store only stores CA certificates, not root or intermediate chains separately. The root trust is purely local to each DC. So you can have a perfectly configured NTAuth store but still fail if the DC's local stores are incomplete.

Less common variations

Smart card cert has no 'Client Authentication' EKU

Sometimes the certificate is technically valid but doesn't include the Client Authentication Extended Key Usage (1.3.6.1.5.5.7.3.2). PKINIT requires this EKU explicitly. Check with:

certutil -dump SmartCardCert.cer | find "Enhanced Key Usage"

If it's missing, the card issuer needs to issue a new cert with the correct EKU.

NTAuth store corrupted or missing

Rare but happens after AD forest recovery or misapplied group policy. The NTAuth store can be rebuilt manually using the CA cert from your enterprise CA:

certutil -dspublish -f CAcert.cer SubCA

If the store is completely gone, you'll need to republish all CA certs in the trust chain. Check event log IDs 18 and 29 in the KDC event log — they often point directly to a missing NTAuth record.

Certificate revocation list (CRL) check failure

If the DC cannot reach the CRL distribution point (CDP) listed in the smart card cert, the chain fails. This is less common on internal networks with properly configured CDP, but if your smart card cert points to an external URL that's blocked by firewall, you'll see the same error. Add the CDP URL to the DC's trusted sites or bypass CRL checking in the registry (not recommended except as a test):

reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" /v EnableCertTypeCheck /t REG_DWORD /d 0 /f

This disables CRL checking globally — only use to confirm the issue, then fix the CDP access.

Prevention

Don't wait for a user to get locked out at 8 AM. When you deploy a new CA or issue smart cards, do this checklist ahead of time:

Publish the CA cert to the NTAuth store using certutil -dspublish — before any card is issued.
Push the root and intermediate CA certs to all domain controllers via Group Policy (Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities).
Set up CRL distribution points that are reachable from all DCs — internal web server or Active Directory itself via ldap:// paths.
Use certutil -viewstore -enterprise NTAuth periodically (quarterly) to verify the store hasn't been pruned by accident.
Test with a test smart card user account before rolling out to production — log in from a client that's never had the user's cert cached.

The error 0XC000038C is almost always a trust configuration gap, not a broken card. Once you've got the NTAuth store and the DC's local stores aligned, it just works.