Member Avatar for aimlessWonderer
aimlessWonderer 0 Newbie Poster

It's long, but trying to give as much informtion as possible at one time.

Having an issue with random individuals trying to access an intranet site with a security certificate. Most users are able to simply select their Smartcard/CAC certificate, enter the pin number and then are granted access to the site's pages.

However, random individuals enter their pin and then are immediately re-prompted by the IE alert dialogue to enter their domain username and password. If they don't enter their network domain username and MS password, then they receive a 401.1 Unauthorized.

I am confused as to why these certain users (who are selecting the same certificates as the successful ones) are being prompted for their domain name/pwd. Furthermore, they're able to access other sites which require a CAC to get past the security certificate.

Possible that a user token is unable to be established via a CAC for the particular site, but not sure why. Since these users are getting a 401.1, then somehow their identity associated with their CAC credentials is not validating.

In IIS: Anonymous users are not allowed (unchecked). 128-bit encryption is required with SSL. Integrated Windows Authentication is checked. Accepting client certificates In the site's web.config file all users are allowed and only anonymous are denied.

Developed in asp.net 3.5

We have tried to reproduce the problem in testing and development environments, but have fortunately/unfortunately been unable to duplicate this issue. This furthermore eludes to an issue that might be isolated to the production server, users access to it, and/or the certificate that is applied to that SSL website on that server.

The exact same setup is present on the development box without any issues at all, indicating to me that the problem resides on the production server's ability to properly receive/handle CAC information from those individuals or that something funky is going on with the way the security certificate is relating to the client's CAC x.509 certificate.

A little more information that may be of use: the browser prompt that initially asks for the CAC has nothing to do with the code of the site, but rather is enabled by applying the security certificate to a site in IIS; thus indicating to me that there is something written into the certificate that looks for client certificates tied to the ActivClient agent via the browser???

The violating users' cards work on all other applications and even on SSL sites on other servers that bring up a CAC prompt. I believe we have confirmed that the certificates associated with their cards and their IE browsers are valid through 2015 (or longer in some cases), and are the same in nature (x509 certificate from the card)... and issuer is being consistently selected as DOD Email CA-15 (though the regular DOD CA-15 works as well). Again, maybe something with the fact that it's isolated to one production server, something with the SSL cert. on that url or user access??

Then again, I probably have no idea what i'm talking about, just throwing a bone here to see if anyone has had the same issue or has any ideas.

Thanks in advance for any input, questions, or ideas.

  • 1 Contributor
  • 0 Replies
  • 143 Views

Dani AI

Generated

— given the dev box works but the production site rejects certain CAC holders (they can pick a card, get re-prompted, then see a 401.1), the root cause is almost always a server-side validation or mapping difference rather than a bad CAC. Focus on three areas: certificate validation (chain/CRL), which certificate is actually being used (EKU), and how IIS maps the validated cert to a Windows identity.

Checklist and quick checks to run first:

  • From the production server, verify the client certificate chain and CRL/OCSP accessibility. Export the failing user cert (public) and run:

    certutil -verify -urlfetch usercert.cer

    This will show chain problems and whether CDP/OCSP lookups succeed.

  • Confirm the certificate chosen is the authentication certificate (EKU contains "Client Authentication" OID). In the cert viewer: Details -> Enhanced Key Usage. If users are accidentally using an e-mail-only cert (DOD Email CA-*), authentication will fail.

  • Ensure the production server has the full CA chain (intermediates) in the Local Computer stores and that the server can fetch the CRLs named in the certs. Firewalls often block CRL hosts; that causes validation failures.

What to inspect in IIS/Windows logs:

  • IIS logs (sc-status, sc-substatus, sc-win32-status) and Failed Request Tracing for 401s will show whether the TLS handshake succeeded and at which stage auth failed. Enable Failed Request Tracing on the site and add a rule for 401 responses.
  • Check the System event log for Schannel/TLS errors around the time of the request.
  • Use a network capture on the server (or netsh trace) to confirm the client actually sends a cert and whether a TLS renegotiation occurs.

Configuration notes and quick remediation ideas:

  • If you rely on certificate->AD mapping, verify the certificate attributes (UPN/SAN/subject) match the AD account mapping method used. If using IIS client-certificate mapping, confirm the mapping entries include the specific issuer/serial or subject.
  • Temporarily disable Windows Authentication (or reorder auth methods) to see whether IIS falls back to Windows auth when client-cert auth fails.
  • Do not disable revocation checking globally; instead ensure CRLs are reachable or pre-cache needed CRLs on the server.

Start with certutil + FRT + Schannel logs. Those will quickly tell whether the server is rejecting the cert (chain/CRL/EKU) or failing to map it to a Windows user.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.