1. “Couldn't get certificate info”

Meaning:
A certificate wasn’t provided by the client over the SSL session.

Troubleshooting:

• Has the user authenticated to the computer using their CAC card?
• If authenticated, are they using a supported browser that can interact with CAC middleware (e.g., IE8 or later)?
• Was the user prompted to select a certificate?
  • This occurs if more than one certificate is present.
  • If so, did they select the correct one?
  • If unsure, try again and select a different certificate.

2. “Couldn't find proper SAN field in certificate”

Meaning:
The certificate provided did not contain a Principal Name (PN) under the Subject Alternative Name (SAN) that matched a well‑formed EDIPI format (example: 0123456789@mil).

Troubleshooting:

• Was the user prompted to select a certificate?
  • If so, did they select the correct certificate?
• If unsure, retry and choose an alternate certificate that contains a SAN Principal Name matching the required EDIPI format (0123456789@mil).

3. “User [name] not found:”

Meaning:
EFT could not find a matching directory (AD/LDAP) user using the EDIPI value extracted from the certificate (e.g., 0123456789@mil).

Troubleshooting:

• Check the LDAP query in EFT.log under “Starting ldap search.”
  • Does the userPrincipalName match the EDIPI format (e.g., 0123456789@mil)?
• Review the list of users in EFT Server:
  • Do their UPNs follow the required EDIPI format?
• If UPNs do not contain the EDIPI:
  • Some orgs store the EDIPI in alternate fields (e.g., pre‑Windows 2000 logon name).
  • Either:
    • Update EFT’s LDAP Attribute field to point to the correct AD attribute, or
    • Copy/move the EDIPI value into the userPrincipalName field, which EFT expects by default.

4. “Failed to obtain certificate from LDAP server for:”

Meaning:
A matching user was found, but no certificate exists for that user in Active Directory.

Troubleshooting:

• Does the user have certificates stored under Published Certificates in Active Directory?
  • (Enable Advanced Features to see this tab.)
  • This is NOT the same as certificates under Name Mappings.
• Rare case: Are there multiple objects with the same UPN?
  • Run a manual LDAP query to confirm.
  • If duplicates exist, only the first match is used, which may not contain the correct certificate.

5. “Certificates doesn’t match” / “Certificates don't match for:”

Meaning:
A certificate associated with this EDIPI in AD did not match the certificate provided by the user — their thumbprints differ.

Troubleshooting:

• Ensure at least one certificate in Published Certificates matches the exact certificate on the user’s CAC card.
• Compare the Thumbprint in:
  • EFT log entry “Incoming certificate info”
  • The certificate obtained from LDAP
• If they differ:
  • The certificate on file in AD may be outdated.
  • The CAC card may need to be reissued (if AD has the newer certificate).
  • An incorrect certificate may have been added to Published Certificates — verify using DEERS‑provided CAC data.

General Issues

Issue: “After logging off and closing my browser, reopening shows I’m still logged on.”

Explanation:
This is expected with SSO and integrated authentication.
You are not still logged in — the browser automatically re-authenticates using the CAC certificate.

Issue: “I’m being prompted twice for my certificate.”

Explanation:
Java does not know which certificate you selected earlier when authenticating to the site.
Thus, it prompts again before loading the Java applet (WTC).

To reduce prompts:

• Remove all personal certificates from local storage except the CAC certificate.
• In the Java Control Panel:
  • Go to Advanced → Security → General
  • Enable “Don’t prompt for client certificate selection when no certificates or only one exists.”