Windows revocation failures
Symptoms / Windows Errors | Solutions |
---|---|
Error shown to the user: The revocation status of the domain controller certificate used for the smart card authentication could not be determined. AND Windows Event Log: The client has failed to validate the domain controller certificate for dc.example.com. The following error was returned from the certificate validation process: A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider. | On target: certutil -verify -urlfetch C:\Users\exampleuser\Desktop\kdccert.cer How to save kdccert.cer to the desktop: 1. mmc.exe -> Add snap in -> Certificates -> Computer account -> Local computer 1. Select domain controller certificate which has Smart Card Logon and KDC Authentication as intended purposes and right click -> All tasks -> Export -> No, do not export the private key -> DER encoded binary -> save to desktop as kdccert.cer The target host is not able to validate the domain controller certificate, if: It fails to obtain a CRL (or OCSP response) due to DNS or network issues, or: A certificate in the chain or published CRL has expired, or: * The current KDC certificate in use doesn’t have CRL Distribution Point (DP) URL (or OCSP in Authority Info Access (AIA)) but instead only Windows Enterprise CA default LDAP path in CRL DP. Note Active Directory doesn’t allow anonymous bind and the CRL object permissions do not allow access with ANONYMOUS LOGON, so use bind e.g. with ldapsearch if testing if CRL is valid in LDAP path if two-way trust is in place multi-domain environment and it should work, else configure CA with HTTP CRL accessible from all target hosts and renew DC KDC certificate(s). |
This error persists even when KDC certificate has been updated to include proper accessible HTTP CRL DP or expired CRL has been replaced by a valid CRL: The revocation status of the domain controller certificate used for the smart card authentication could not be determined. | Ensure Windows cache doesn’t interfere. Windows has a negacache for CRL queries that cause validation to fail locally if it has failed in the past. The system cache is persistent and survives reboot. The cache of the system cannot be cleared with certutil command but it needs to be cleared manually (e.g. delete CRL files from C:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache\Content\ ) The cache also works the other way: revocation is not noticed if there are cached entries, e.g. for OCSP “Responses that are in cache are held for the validity period of the CRL the response was based off of or the validity of the ocsp response signing certificate – whichever is shorter.” |
Error shown to the user: The revocation status of the smart card certificate could not be determined. | On target: certutil -scinfo -pin 0 -> View Certificate properties Target host is not able to validate the user certificate from virtual smart card, if: It fails to obtain the CRL due to DNS or network issue, or: The PrivX Server’s IP / FQDN is misconfigured. Ensure accessible IP / FQDN on PrivX Server and DNS is configured correctly on Windows environment. Check that CRL DP URL in the user certificate can be downloaded from the target with a browser or certutil and firewalls are not blocking outgoing port 80 on target or incoming port 80 on PrivX CA. PrivX CA issues empty CRL on demand and it is valid one hour in the past and 23 hours in the future. |