| Previous | Next |
| SEC_E_REVOCATION_OFFLINE_C | SEC_E_SMARTCARD_CERT_EXPIRED |
SEC_E_PKINIT_CLIENT_FAILURE
The client-certificate side of PKINIT
PKINIT replaces the usual long-term secret in the initial Kerberos exchange with proof based on an X.509 certificate and its private key. This status is about the certificate selected for the user, not the certificate that identifies the Key Distribution Center. It is therefore useful to separate client-certificate validation from KDC-certificate validation before changing anything on a domain controller.
Windows can surface this status after the card has supplied a certificate but the KDC cannot accept it as a smart card logon credential. The reason can be chain trust, publishing the issuing CA in the required trust locations, certificate profile and extended-key-usage requirements, an unusable private key, revocation validation, or an account mapping that does not match the certificate identity.
Build an evidence chain
- Confirm which certificate the credential provider actually selected. Multiple certificates on one card can have different EKUs, issuers, validity periods, and subject alternative names.
- Verify that the card holds the matching private key and that the reader, card middleware, and cryptographic provider can use it for signing. Copying only a public certificate to a workstation does not make it a smart card logon credential.
- Validate the full issuer chain from the DC, including Enterprise NTAuth publication where the deployment requires it, root and intermediate trust, and revocation information.
- Compare the certificate UPN or other supported mapping data with the intended Active Directory account. A valid certificate for a different identity is not a valid credential for this logon.
References
- RFC 4556: PKINIT
- Microsoft: smart card certificate requirements and enumeration
- MIT Kerberos: PKINIT configuration
Looking for a different code? Search another status or error code.