SEC_E_KDC_CERT_REVOKED (0x8009035B) on Smart Card Logon

1. The DC's Kerberos Authentication certificate is actually revoked

This is the most common culprit. Your domain controller uses a special certificate for Kerberos Authentication (Smart Card Logon) — the one with the Domain Controller and KDC Authentication OIDs. If that cert gets revoked, every smart card login attempt hits this error.

Had a client last month whose entire print queue died because of this — their CA auto-renewed the DC cert but the old one wasn't properly removed from the CRL. Users couldn't log in for 3 hours during a shift change. Total chaos.

How to check and fix it

1. Log onto the DC that's failing. Open PowerShell as admin.
2. Run:

   Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.EnhancedKeyUsageList -match "1.3.6.1.5.5.7.3.2"} | Format-List Subject, Thumbprint, NotAfter, SerialNumber

   This lists all smart card logon certs in the local machine store.

3. Note the thumbprint of the one that's currently in use (check the KDC service's cert binding if you need).
4. Open Certificates MMC (certlm.msc), go to Personal > Certificates. Right-click the cert > All Tasks > View Certificate. Check the Revocation Status tab. If it says "Revoked", you've found it.
5. Head to your Certification Authority server. Open certsrv MMC. Expand the CA, click Issued Certificates, find that cert, right-click > Revoke (but only if you're sure it's supposed to be dead — otherwise you'll break more). If it's a renewal mistake, issue a new cert with certreq -new or auto-enroll.
6. Back on the DC, delete the revoked cert from the Personal store. Then force a new cert request:

certreq -new -machine -q C:\Windows\System32\certreq.inf C:\temp\newdc.req
certreq -submit -machine -q C:\temp\newdc.req C:\temp\newdc.cer
certreq -accept -machine C:\temp\newdc.cer

Replace the INF path with your actual template if you have one. After that, restart the KDC service: net stop kdc && net start kdc.

I've seen this fix work maybe 80% of the time. The other 20% is the next cause.

2. CRL (Certificate Revocation List) check failure or stale CRL

Sometimes the cert itself isn't revoked — the KDC just thinks it is because the CRL hasn't been updated or the DC can't reach the CRL distribution point. This is sneaky because the cert looks fine in the store.

Real story: a small law firm had their CA offline for maintenance for 2 days. The DCs couldn't download the CRL, so they treated all certs as revoked. Smart card logon became a brick wall.

Check CRL status

1. On the failing DC, open Event Viewer > Applications and Services Logs > Microsoft > Windows > CertificateServices > Client-Lifecycle-System. Look for Event ID 1 or 100 — they'll say "The certificate could not be validated" with an error about CRL.
2. Check if the CRL is accessible. Open a browser and paste one of the CRL URLs from a certificate's CRL Distribution Points tab. If it 404s or times out, that's your problem.
3. Manually download the latest CRL from the CA: certutil -getca CRL on the DC. Or push it via Group Policy (Certificate Services Client - Auto-Enrollment).
4. If the CA is gone, you can force the DC to ignore CRL checking for smart card logon — but I don't recommend it. It's a security hole. Better to fix the infrastructure.

Quick test: run certutil -verifystore My and look for "Revocation check failure" errors. If you see them, the CRL path is broken.

3. Mismatched certificate template or wrong EKU

If the DC cert was issued from a template that doesn't include the right Enhanced Key Usage (EKU) for Kerberos authentication, Windows rejects it. The KDC needs the KDC Authentication EKU (1.3.6.1.5.2.3.5) and Smart Card Logon (1.3.6.1.4.1.311.20.2.2). Missing either one, and you get 0x8009035B.

This happens when someone manually issued a cert from a generic Web Server template instead of the proper Domain Controller or Kerberos Authentication template.

Check the template

On the DC, run:

certutil -store My | findstr /i "1.3.6.1.5.2.3.5"
certutil -store My | findstr /i "1.3.6.1.4.1.311.20.2.2"

If you don't see both OIDs in the output, the cert is wrong. Delete it from the Personal store and request a new one using the correct template.

To force a new cert from the correct template:

certreq -new -machine -q -cert DomainControllerTemplateName C:\temp\newdc.inf C:\temp\newdc.req
certreq -submit -machine -q C:\temp\newdc.req C:\temp\newdc.cer
certreq -accept -machine C:\temp\newdc.cer

Replace DomainControllerTemplateName with the actual template name (usually "Domain Controller" or "Kerberos Authentication"). Then reboot the DC.