Safeguard Authentication Services 5.0.2 - Authentication Services for Smart Cards Administration Guide

Log shows "Failed authentication attempt: cannot verify certificate"

You will get a log error message that says, "Failed authentication attempt: cannot verify certificate" when Active Directory is verifying the user's certificate, or when Safeguard Authentication Services for Smart Cards is verifying the KDC certificate returned by Active Directory. The most likely causes are either that the CA certificate that was used to issue that certificate is not in the NtAuthCertificates container in Active Directory, or Safeguard Authentication Services for Smart Cards was unable to automatically bootstrap the trusted certificates.

Check the user's account settings in Active Directory. For more information, see Check login.

See also Bootstrapping trusted certificates.

Troubleshooting "Client not trusted" issue

Symptom:

An error displays, similar to the following:

ERROR: could not establish initial credentials
ERROR: VAS_ERR_KRB5: at ticket.c:72 in ticket_generate_good_error
Failed to obtain credentials. Client: vas-user@SC.VAS, Service:
krbtgt/SC.VAS@SC.VAS
Caused by:
KRB5_KDC_ERR_CLIENT_NOT_TRUSTED (-1765328322): Client not
trusted

Diagnosis:

You will get an error message that says, "Client not trusted" if Active Directory cannot determine the validity of the client certificate supplied by the smart card, or the validity of any certificate that issued the client certificate.

This may occur for a number of reasons:

1. The Certification Authority service (CA) is not running on the domain controller.

   Active Directory passes the certificate to the CA for verification. If the CA is not running, the certificate cannot be verified and is therefore not trusted.

2. The CA is running, but the Certificate Revocation List (CRL) contained in the certificate is out of date and a new CRL cannot be obtained.

   Typically, the CRL is obtained by means of LDAP calls to an external revocation server, and if this server is unreachable or cannot supply a new CRL, the CA cannot check the revocation status of the certificate and the client is therefore not trusted.

Solution:

1. Confirm that the Certification Authority service is running on the domain controller. Navigate to Start | Administrative Tools | Certification Authority, and verify that there is a small green tick attached to the "CA" property in the left-hand side of the panel. If there is a small red dot for this property, right click on CA, and select All Tasks | Start Service.
2. Confirm that the revocation server is reachable:
   1. Attach a smart card reader to the Windows machine for which login is required.
   2. Insert the smart card into the reader.
   3. Open up a command prompt, and run the command certutil –SCInfo. This command attempts to verify the client certificate on the smart card, including CRL checks.

   4. Check the output for the following:

      The revocation function was unable to check revocation
      because the revocation server was offline. 0x80092013
      (-2146885613)
      ------------------------------------
      Revocation check skipped -- server offline

Troubleshooting certificate lookups

Symptom:

Certificate lookups fail.

Diagnosis:

This failure occurs because the default IPC timeout of 5 seconds is insufficient to handle some referrals.

Solution:

Set a sufficient value for the vascache-ipc-timeout property in vas.conf, as follows:

[libvas]
vascache-ipc-timeout = 10