Error 401.2 with smartcard login for new users with more recent Intermediate certificates

Summary
HTTP Error 401.2 - Unauthorized
 You are not authorized to view this page due to invalid authentication headers.

Some new users to my web site cannot log on due to 401.2 and 401.1 errors. Other new users connect without any issue. Users have the DoD CAC smartcard and they are valid for logging into their workstations. All the certificates point to the same root authority, DOD Root 3, but have different intermediate certificates which are DOD CA 38 to DOD CA 51. Users with intermediate certificates numbered 48 or higher get the 401.2 error and cannot log in.

I assume the problem is the more recent intermediate certificates are not installed or configured correctly. I installed the most recent certs from the cert authority using their tool, InstallRoot.exe. MMC confirmed the intermediate certs are in the Certificates (Local Computer) -> Intermediate Certification Authorities -> Certificates.

The server uses the Axway tool to validate certificates. In the Application Event Log for the attempt, it said "Revocation Status: Good" so I assume my OCSP and its cache are set up correctly.

After every 401.2 error is a 401.1 error. The sc-win32-status for the 401.1 error is -1073741715. Is that number significant?  

The detailed configuration description:


I am using IIS 7.5 on Windows Server 2008 R2. I set up the web server and the web site to require a smartcard to open the web site. To that end I set up iisClientCertificateMappingAuthentication with manyToOneMappings. I set up three new users the same way. Two of three new users cannot log in and get both a 401.2 (sc-status=401 sc-substatus=2 sc-win32-status=5) and a "Can't reach this page" with Error Code: INET_E_DOWNLOAD_FAILURE.

IIS Log Entries

Here are the IIS log entries for a successful user, First IP, and a failed user, Second IP. The 500 error for sc-win32-status=64 (the "specified network name is no longer available") is the same for successful and unsuccessful logins.
time	c-ip	cs-username	s-port	cs-method	cs-uri-stem	sc-status	sc-substatus	sc-win32-status	time-taken
1/1/2000 19:32	Second IP		443	GET	/	401	2	5	1734
1/1/2000 19:32	Second IP		443	GET	/	500	0	64	16
1/1/2000 19:31	Second IP		443	GET	/	401	1	-1073741715	2
1/1/2000 19:31	Second IP		443	GET	/	401	2	5	2011
1/1/2000 19:31	Second IP		443	GET	/	500	0	64	118
1/1/2000 19:30	First IP	Server\Username	443	GET	/LoginController.asp	200	0	0	17
1/1/2000 19:30	First IP	Server\Username	443	POST	/EntryBanner.asp	302	0	0	4
1/1/2000 19:30	First IP	Server\Username	443	GET	/EntryBanner.asp	200	0	0	22
1/1/2000 19:30	First IP	Server\Username	443	GET	/	200	0	0	4164
1/1/2000 19:30	First IP		443	GET	/	500	0	64	637

Open in new window


In the System Event Log, the 500 error generates two entries with source of Schannel for every login attempt, successful and unsuccessful:
The certificate received from the remote client application is not suitable for direct mapping to a client system account, possibly because the authority that issuing the certificate is not sufficiently trusted. The error code is 0x80090325. The attached data contains the client certificate.
and
The certificate received from the remote client application was not successfully mapped to a client system account. The error code is 0xc0000192. This is not necessarily a fatal error, as the server application may still find the certificate acceptable.

I attached a PDF with more detailed configuration details.
CAC-Login-Problem.pdf
Bruce DimonSr. Application DeveloperAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

gr8gonzoConsultantCommented:
So if I understand correctly, there are at least 3 entities involved here:
[ User Workstation ]  -> [ Axway ] -> [ IIS]

You've used InstallRoot.exe to get all certs updated on IIS, but have you ensure that the certs are also updated on both the user workstation (again, via InstallRoot.exe) and also on Axway (manual deployment of the intermediate certs)?
0
Bruce DimonSr. Application DeveloperAuthor Commented:
I checked the workstations for the certificates using MMC and found them installed in the intermediate certification authority section. Moreover, I had the users attempt the web site on my workstation by putting their CAC in the second card reader.

I will have to investigate the intermediate certs on Axway. I assumed that it used the server's certificates.

I will run InstallRoot on the workstations to see what that does.
0
Bruce DimonSr. Application DeveloperAuthor Commented:
I think the Axway (Tumbleweed) product is configured correctly because the log entries say it passed the OCSP lookup.

Certificate Revocation Status
Calling Application: Microsoft Local Security Authority Service
Certificate Name: /C=US/O=U.S. Government/OU=DoD/OU=PKI/OU=CONTRACTOR/CN=XXXXX.XXXXX.XXXX.9999999999
Certificate Issuer: /C=US/O=U.S. Government/OU=DoD/OU=PKI/CN=DOD ID CA-49
Certificate Serial Number: 025D35
Revocation Status: Good
Validation Protocol: OCSP
Validation Url: http://ocsp.disa.mil
Responder Key Hash: Hash Value Here
Transaction Id: 300-162


Certificate Revocation Status
Calling Application: Microsoft Local Security Authority Service
Certificate Name: /C=US/O=U.S. Government/OU=DoD/OU=PKI/CN=DOD ID CA-49
Certificate Issuer: /C=US/O=U.S. Government/OU=DoD/OU=PKI/CN=DoD Root CA 3
Certificate Serial Number: 0127
Revocation Status: Good
Validation Protocol: OCSP
Validation Url: http://ocsp.disa.mil
Responder Name: /C=US/O=U.S. Government/OU=DoD/OU=PKI/CN=BlahBlahBlah
Transaction Id: 300-161
0
Bruce DimonSr. Application DeveloperAuthor Commented:

It was a change in the users' certificates!

The smartcard authority is rolling out a change to how the cards will be used to log into websites. There added a brand-new certificate to the card and will deprecate the certificate currently enabled for logging in. Previously we told the users to log in with their email certificate because that was the one that I put into the IIS when we used one-to-one mapping. Also, it's in their signed email so it's easy to get. However that email cert will no longer work for logging in. I used the new cert instead and the new people started working.

The document explaining this claimed that the old old way would still work until next year. Argh! They made me an early adopter.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Bruce DimonSr. Application DeveloperAuthor Commented:
Thanks for responding. My solution turned out to be nothing wrong on my end. The new users' certificates were not enabled for smartcard login.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
PKI CERTIFICATES

From novice to tech pro — start learning today.