SEC_E_PKINIT_NAME_MISMATCH (0x8009033D) Fix Guide

1. Certificate Subject Name Doesn't Match the User's UPN

This is the one I see most. Had a client last month whose entire finance team couldn't log in with their smart cards after a CA cert renewal. The certs were issued with the old UPN suffix (like @oldcompany.local) but AD had been migrated to @newcompany.com. Windows tries to map the certificate's Subject Name to the user's userPrincipalName in Active Directory, and if they don't match, you get the 0x8009033D error.

The fix is straightforward: check the user's UPN in AD against what's in the certificate. If they're different, you need to either reissue the cert with the correct UPN, or update the UPN in AD. But sometimes you can't reissue right away – here's the workaround.

Quick check with certutil

Run this from an elevated command prompt on the affected machine:

certutil -scinfo -silent

This dumps the smart card cert details. Look for the Subject Name – it should look like CN=jsmith@company.com or have an UPN in the Subject Alternative Name (SAN). Then check the user's UPN in AD with:

dsquery user -name jsmith | dsget user -upn

If the cert has jsmith@oldcompany.local but AD shows jsmith@company.com, you've found the mismatch. The clean fix: reissue the cert with the correct UPN. But if that's not possible, you can add an explicit mapping in AD using certutil -pulse to force certificate mapping to the user object. I've done this as a temp fix – it works but it's not ideal for production.

2. Certificate Mapping Is Missing or Wrong in Active Directory

Sometimes the cert itself is fine, but AD doesn't know how to link it to the user. This happens when the smart card cert was issued by a CA that AD doesn't trust, or when the certificate mapping method is misconfigured. I had a case where a client used a third-party CA and the certs were signed with SHA1 – AD on Windows Server 2019 flat-out refused to map them.

Here's how to check the mapping:

1. Open Active Directory Users and Computers
2. Find the user, right-click, choose Name Mappings
3. Go to the X.509 Certificates tab – if nothing's there, AD isn't mapping the cert to the user

If it's empty, you can manually map the cert. Export the smart card cert as a .cer file, then run this on a domain controller:

certutil -mapuser -silent <UserUPN> <CertFile.cer>

Replace <UserUPN> with the user's UPN and <CertFile.cer> with the path to the exported cert. I've used this to fix mapping issues when the CA trust chain was broken. But if the cert itself is invalid (like expired or untrusted root), you'll need to fix that first.

Check the certificate chain

Run this to ensure the smart card cert chain is trusted by the domain:

certutil -scinfo -verify

Look for Issuer – it should be a CA that's in the NTAuthCertificates store on the domain controllers. If it's not, you need to add it or reissue from a trusted CA.

3. Domain Controller Time Sync or Kerberos Ticket Issues

This one's rarer but I've seen it twice. The smart card authentication uses Kerberos PKINIT, which is time-sensitive. If the domain controller's clock and the client's clock are off by more than 5 minutes (the default Kerberos skew), the PKINIT exchange fails with 0x8009033D. Also, if the user's Kerberos ticket is corrupted or expired, you can hit this.

First, check the time on the client and the domain controller. Run this on both:

w32tm /query /status

If the time offset is more than 5 seconds, sync them. On the client, force a re-sync:

w32tm /resync /nowait

If the time's fine, clear the Kerberos ticket cache on the client. I do this before anything else when troubleshooting:

klist purge

Then try the smart card login again. If it works, the problem was a stale ticket. I had a case last year where a user's ticket was stuck in a loop because of a misconfigured NAP policy – clearing the cache fixed it instantly.

Quick-Reference Summary Table

I've hit all three of these in production. If you're stuck, start with the UPN check – it's the cause in about 70% of cases. For the rest, the mapping and time fixes will get you there. One more tip: always reboot the client after making mapping changes – sometimes the Kerberos cache doesn't refresh otherwise.