Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

License Error Event ID 20

KDC Event ID 20: the domain controller certificate is no longer usable

10 min read Updated October 4, 2026 Windows Server: AD, DNS & Group Policy

Fix it now

The Key Distribution Center reports that the certificate it was using was once valid, is now invalid, and no suitable replacement was found. Password logons carry on working, so this can sit unnoticed for weeks. What breaks is smart card logon and anything that validates the domain controller before trusting it.

Run these on the affected domain controller, in an elevated Command Prompt

certutil -dcinfo verify
certutil -pulse
  1. Read the certutil -dcinfo verify output first. It checks the domain controller certificates and reports the chain status, which is the same information the event puts in its error data.
  2. Open the computer’s certificate store and look at the domain controller certificates: expiry date, intended purposes, and whether the private key is present. Certificates without a usable private key fail exactly like expired ones.
  3. Delete the invalid domain controller certificate from the Personal store. That is Microsoft’s documented first step, and it stops the KDC selecting it again.
  4. Request a new domain controller certificate through the Certificate Enrollment Wizard, or let autoenrolment do it with certutil -pulse.
  5. Re-run certutil -dcinfo verify and confirm it passes before testing a smart card logon.

Check that the issuing CA is in the enterprise NTAuth store. A certificate issued by a CA that is not in NTAuth cannot be used for this, and PKIView shows the store’s contents without an LDAP query.

If the verification passes and smart card logon works, you are done. The next section explains what the KDC is selecting and how the neighbouring events differ.

Why it happens

Kerberos uses a domain controller certificate to prove the KDC’s identity during certificate-based authentication. Event ID 20, whose symbolic name is KDCEVENT_INVALID_KDC_CERTIFICATE, says the currently selected certificate was once valid but is now invalid and no suitable replacement was found, that smart card logon may not function correctly until it is remedied, and that the chain status is in the error data. That last clause is the diagnostic: the event is telling you which chain check failed, if you look.

Two neighbouring events say related but different things, and confusing them wastes a morning. Event ID 19 reports an attempt to use smart card logon where the KDC cannot use the PKINIT protocol because it is missing a suitable certificate – there is nothing to replace, rather than something that expired. Event ID 29 says the KDC cannot find a suitable certificate for smart card logons, or the certificate could not be verified, and its own text tells you to verify the existing certificate with certutil or enrol for a new one.

Event ID 21 is on the other side of the exchange entirely. It says the client certificate for the named user is not valid and resulted in a failed smart card logon, with the chain status in the event. If you are seeing 21 and not 20, the domain controller is fine and the card, or the user’s certificate, is not.

The domain controller certificate has expired or has no private key

You have this one if certutil -dcinfo verify fails, and the certificate in the computer’s Personal store is out of date or shows no associated private key.

  1. Delete the invalid certificate from the Personal store on that domain controller.
  2. Request a new domain controller certificate, or trigger autoenrolment with certutil -pulse.
  3. Re-run certutil -dcinfo verify and confirm it passes.

Deleting the old certificate matters. Leaving expired and superseded domain controller certificates in the store gives the KDC something else to select.

The issuing CA is not in the NTAuth store

You have this one if The certificate itself looks healthy, and validation still fails – typically after a third-party or newly built CA started issuing them.

  1. Check the enterprise NTAuth store, which lives at CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration in the forest.
  2. Publish the CA certificate into it: certutil -dspublish -f <file> NTAuthCA, or use PKIView’s NTAuthCertificates tab.
  3. Force a policy refresh so members pick up the thumbprint, which Group Policy places under HKLM\Software\Microsoft\EnterpriseCertificates\NTAuth\Certificates.

The chain cannot be validated from the domain controller

You have this one if The chain status in the event or in the certutil output points at revocation or trust rather than expiry.

  1. Run certutil -verify -urlfetch against the domain controller certificate and read which fetch failed.
  2. Repair the CRL distribution point or the issuing CA’s publication before touching the certificate itself.
  3. Only then re-enrol, since a new certificate from the same CA will fail the same check.

Autoenrolment is not replacing it

You have this one if The certificate expired and nothing renewed it, on one domain controller or on all of them.

  1. Confirm the domain controller’s computer account has Read, Enroll and Autoenroll on the template that issues these certificates.
  2. Confirm the autoenrolment policy is enabled for computers, then run gpupdate /force and certutil -pulse.
  3. Check the CA is issuing the template at all with certutil -CATemplates before blaming the client.

Full reference

The KDC certificate events, and which is which

Event ID What it reports
19 An attempt was made to use smart card logon, but the KDC cannot use PKINIT because it is missing a suitable certificate
20 The currently selected KDC certificate was once valid, is now invalid, and no suitable replacement was found. The chain status is in the error data
21 The client certificate for the named user is not valid, and resulted in a failed smart card logon, with the chain status in the event
29 The KDC cannot find a suitable certificate for smart card logons, or the certificate could not be verified. Verify it with certutil, or enrol for a new one

The documented repair, in order

  1. On the affected domain controller, open the certificates snap-in for the computer account.
  2. Expand Personal, then Certificates, and delete the old domain controller certificate.
  3. Right-click Personal and request a new certificate, completing the enrolment wizard for a domain controller certificate.
  4. Verify from a domain-joined machine with certutil -dcinfo verify, which confirms the KDC certificate is installed and working.
  5. Restart the Kerberos Key Distribution Center service, or reboot, if the KDC has not picked the new certificate up.

Chain status values you may find in the event

Value What can be said about it
0x800B010C CERT_E_REVOKED: a certificate was explicitly revoked by its issuer
0x800B0110 No Microsoft page publishing this value was found. Treat it as a chain status to resolve from the certutil output rather than from the number
0x800B010E As above: no published meaning was found. Read the named failure in certutil -verify -urlfetch instead

Where a chain status value is not one you can look up, the productive move is certutil -verify -urlfetch against the certificate. It names the failing check in words – an expired CRL, an unreachable distribution point, an untrusted root – which is what you need to act on.

NTAuth, and why it is not the same as trust

A certificate can chain to a trusted root and still be unusable for this, because domain controller and smart card logon certificates must come from a CA published in the enterprise NTAuth store. Windows enterprise CAs that are domain-joined publish themselves there automatically; a third-party or standalone CA does not. The store is an object in the forest configuration partition, its contents are written to the cACertificate attribute, and Group Policy copies the thumbprints to members under EnterpriseCertificates\NTAuth\Certificates.

When password logons work and nothing else does

  • Smart card logon is the obvious casualty, but anything that validates the KDC before trusting it is affected too.
  • A domain controller with no valid certificate can also produce Kerberos pre-authentication failures for smart card users, which appear as 4771 with a smart card pre-authentication type.
  • Check every domain controller, not the one that logged the event. Users authenticate against whichever they find.
  • Keep an eye on the expiry dates as a set: certificates issued on the same day expire on the same day, and a whole estate can go at once.

When a licence is the actual fix

The repair itself costs nothing: delete the invalid certificate, re-enrol, verify. There are two situations where a purchase is genuinely part of the answer. The first is having no certification authority capable of issuing domain controller certificates at all, because the role has to run somewhere supported. The second is a CA or publication host on a Windows Server build that no longer receives updates, where re-enrolling from it simply repeats the problem later. Active Directory Certificate Services is a role of the server rather than a separate product, so what you would be buying is the server licence and its client access licences – Arco supplies Windows Server 2025 Standard for exactly that. If you already run a supported CA, this is a configuration fix and nothing needs buying.

Every code this article covers

Code What it points at Source
Event ID 20 The currently selected KDC certificate was once valid, is now invalid, and no suitable replacement was found; the chain status is in the error data Microsoft Learn
Event ID 21 The client certificate for the named user is not valid and resulted in a failed smart card logon, with the chain status in the event Microsoft Learn
0x800B0110 Seen as a chain status alongside these events. No acceptable Microsoft page publishing this value was found, so diagnose it from the certutil verification output rather than the number not published by the vendor
0x800B010C CERT_E_REVOKED: a certificate was explicitly revoked by its issuer Microsoft Learn
0x800B010E Another chain status value with no published meaning found. Resolve it with certutil -verify -urlfetch, which names the failing check in words not published by the vendor

Confirm the fix worked

  1. certutil -dcinfo verify passes on every domain controller, not only the one that logged the event.
  2. The computer’s Personal store holds one current domain controller certificate with a private key, and no expired ones.
  3. A smart card logon succeeds against that domain controller.
  4. No new KDC events 19, 20 or 29 after the KDC service restart.
  5. The issuing CA appears in the NTAuth store, and members hold its thumbprint.

Questions people ask about this

Why do password logons still work?

Because they do not use the KDC’s certificate. Only certificate-based authentication does, which is why this can go unnoticed until someone tries a smart card.

What is the difference between events 20 and 29?

Event 20 says the certificate that was being used has become invalid and nothing suitable replaced it. Event 29 says no suitable certificate can be found, or the one present could not be verified, and directs you to verify it with certutil or enrol for a new one.

Event 21 keeps appearing instead. Is my domain controller at fault?

No. Event 21 is about the user’s client certificate, not the KDC’s. Read the chain status in that event and look at the card or the user’s certificate.

Do I have to delete the old certificate?

Yes, and it is Microsoft’s own first step. Leaving an expired or superseded certificate in the store gives the KDC something invalid to select.

The certificate is valid but logon still fails.

Check the enterprise NTAuth store. A certificate from a CA that is not published there cannot be used for domain controller or smart card logon, however good its chain looks.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

Free Fix Event ID 5781: dynamic registration of domain controller DNS records failed License Error Event ID 2095 USN rollback: a domain controller restored from a snapshot Free Fix Errors 8456 and 8457: inbound or outbound replication switched off on a DC License Error Error 8568: the functional level will not rise while legacy DCs remain
← Back to Knowledge Base