Fix STATUS_PKINIT_FAILURE 0XC0000320 on Windows Domain

What Triggers This Error

You're sitting at a domain-joined Windows 10 or Server 2019 machine. User logs in with a smart card or tries to authenticate to a network resource. Boom — error 0XC0000320, STATUS_PKINIT_FAILURE. The domain controller (DC) just had its Kerberos Authentication certificate renewed or replaced. Or the client's clock drifted more than 5 minutes from the DC. Or someone fat-fingered the NTP config. I've seen this on Windows 10 22H2 and Server 2022 after a CA reissue of the Domain Controller certificate template.

Root Cause in Plain English

Kerberos PKINIT (Public Key Cryptography for Initial Authentication) uses certificates to validate the client or server during the initial ticket-granting ticket (TGT) exchange. When the DC's certificate changes — maybe it expired, got revoked, or reissued — the client still holds the old cert hash or time skew kills the validation. The AS-REQ gets a PKINIT failure code from the KDC. The culprit here is almost always one of two things: stale cached credentials on the client, or a clock mismatch. Rarely it's the cert chain itself — but don't bother checking the CA unless the first two fail.

Step-by-Step Fix

Sync the clock — Run this as admin on the affected client:
```
w32tm /resync /force
w32tm /query /status
```
If the resync fails, set the NTP server manually:
```
w32tm /config /manualpeerlist:pool.ntp.org /syncfromflags:manual /reliable:yes /update
net stop w32time && net start w32time
w32tm /resync /force
```
The time must be within 5 minutes of the DC. I've fixed 30% of these calls with time alone.
Purge Kerberos tickets — The client caches old TGTs from before the cert change. Nuke them:
```
klist purge
klist tgt
```
Then log off and back on. If the user can't log off, run klist -li 0x3e7 purge to clear the SYSTEM ticket too.
Check the DC certificate — On the domain controller that the client is authenticating to (check with nltest /dsgetdc:YOURDOMAIN), open the cert snap-in. Look under Personal > Certificates for one with the Kerberos Authentication extended key usage (1.3.6.1.5.2.3.5). If it's missing or expired, re-enroll the DC certificate:
```
certreq -enroll -machine -q -cert -
```
Or use the GUI: MMC > Add/Remove Snap-ins > Certificates > Computer account. Right-click Personal > All Tasks > Request New Certificate. Pick the Domain Controller template.
Verify the client's trusted root store — The DC's cert must chain to a root CA the client trusts. Run:
```
certlm.msc
```
Go to Trusted Root Certification Authorities > Certificates. If the root isn't there, export it from the DC and import here. Skip this if you're using an internal PKI — it's almost never the issue.
Flush the DNS cache and re-register — Stale DNS records can point to a DC with the old cert. Run on the client:
```
ipconfig /flushdns
ipconfig /registerdns
```
Then reboot.

What to Check If It Still Fails

If the error persists after steps 1-5, check these:
- Event Viewer logs — Look under Applications and Services Logs > Microsoft > Windows > Kerberos > Operational. Filter for Event ID 3 or 4. They'll tell you which cert or time component failed.
- Smart card driver — If using smart cards, test the card on another machine. Bad drivers cause PKINIT errors too. Uninstall and reinstall the vendor driver (e.g., ActivIdentity, Gemalto).
- Group Policy — Do you have a custom PKINIT certificate mapping policy? Check GPO under Computer Config > Windows Settings > Security Settings > Public Key Policies > Certificate Path Validation Settings. Misconfigurations here block authentication.
- CA revocation list — If the DC cert is not revoked but the CRL is stale, clients can't validate. Force a CRL update: certutil -urlcache CRL delete on the client, then certutil -verifyctrl on the DC.

I've seen exactly two cases where none of the above worked. Both times, the client had a third-party anti-virus that hooked into Winsock and was blocking Kerberos UDP packets on port 88. Temporarily disable the AV to test, then whitelist Kerberos traffic.