Fixing STATUS_PKINIT_NAME_MISMATCH (0XC00002F9)

Cause 1: Domain Controller Certificate Missing the Correct SAN or UPN

If you're seeing error 0XC00002F9 during smart card logon or Kerberos authentication, the culprit is almost always the domain controller certificate. Kerberos PKINIT uses certificates to verify the domain controller's identity. If the certificate doesn't include the domain controller's DNS name in the Subject Alternative Name (SAN) or the UPN in the certificate doesn't match, Windows throws STATUS_PKINIT_NAME_MISMATCH.

This typically happens when you're using a third-party CA or a misconfigured internal CA. The DC certificate must have the following:

• Subject Alternative Name (SAN): Must include the domain controller's FQDN (e.g., dc01.contoso.com).
• Enhanced Key Usage (EKU): Must include "Smart Card Logon" (1.3.6.1.4.1.311.20.2.2) AND "Client Authentication" (1.3.6.1.5.5.7.3.2).
• UPN (optional but common): If you set a UPN in the cert, it must match the domain controller's machine account (e.g., DC01$@contoso.com).

Here's the fix:

# On the DC, check the certificate with certlm.msc
# Look for the DC certificate under Personal > Certificates
# Double-click and go to Details > Subject Alternative Name
# Confirm the DNS Name matches the DC's FQDN

# If missing, request a new certificate from your CA with the correct SAN:
certreq -new -attrib "CertificateTemplate:DomainController" request.inf request.req
# Submit to CA and install the issued cert

Don't bother checking the Subject field alone — PKINIT only reads the SAN and UPN. If the SAN is empty or wrong, you'll keep getting the error.

Cause 2: User Certificate UPN Mismatch with Active Directory

The next common cause is the user's smart card certificate. The UPN in the certificate must match the user's userPrincipalName in Active Directory exactly. Case sensitivity matters with some smart card middleware — not with Windows itself, but with the PKINIT process.

Typical scenario: You reissued smart cards from a new CA, but the UPN is set to jdoe@olddomain.local while the AD user's UPN is jdoe@contoso.com. Instant mismatch, instant 0XC00002F9.

Check the user's certificate:

# On the user's machine, run in PowerShell:
Get-ChildItem Cert:\CurrentUser\My | Where-Object { $_.EnhancedKeyUsageList -like "*Smart Card Logon*" } | Format-List Subject, NotBefore, NotAfter

# Look at the Subject field or SAN for the UPN
# Compare to AD:
Get-ADUser jdoe -Properties userPrincipalName | Select-Object userPrincipalName

The fix: Re-issue the smart card certificate with the correct UPN. Most CA templates let you map the UPN from the AD attribute. If you're using a third-party CA, work with them to align the UPN field.

One quick workaround: Temporarily disable PKINIT name validation (not recommended for production, but good for testing). Set this registry key on the domain controllers:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Value: DisablePKINITNameValidation
Type: REG_DWORD
Data: 1

Reboot the DC. If the error goes away, you've confirmed a name mismatch. Turn it back off (set to 0) after fixing the certs.

Cause 3: Certificate Chain Issues or Expired Root CA

Less common but nasty: The domain controller certificate is fine, the user certificate is fine, but the root CA certificate is expired or missing from the trusted root store on the client or DC. PKINIT validates the full chain. If the root isn't trusted, the error pops up.

This happens after a CA certificate renewal or migration. The old root expires, and the new root isn't deployed to all machines.

Check the chain:

# On the client machine, open the problematic certificate
# Go to Certification Path tab
# See if there's a red X on any certificate in the chain
# If the root shows "This certificate has expired or is not yet valid" — that's your problem

# Deploy the new root CA certificate via Group Policy:
# Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities
# Import the new root .cer file
# Run gpupdate /force on the clients

Also check that the intermediate CA certificates are in the Intermediate Certification Authorities store. Missing intermediates cause the chain to fail validation, which triggers PKINIT to reject the cert.

One more thing: If you're using a dedicated KDC certificate (not the default auto-generated one), ensure it hasn't expired. Right-click the certificate in certlm.msc and check the validity period. KDC certs often issue for 1-2 years — easy to forget.

Quick-Reference Summary Table