Link to home
Start Free TrialLog in
Avatar of Bruce Dimon
Bruce DimonFlag for United States of America

asked on

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
Avatar of gr8gonzo
gr8gonzo
Flag of United States of America image

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)?
Avatar of Bruce Dimon

ASKER

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.
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
ASKER CERTIFIED SOLUTION
Avatar of Bruce Dimon
Bruce Dimon
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks for responding. My solution turned out to be nothing wrong on my end. The new users' certificates were not enabled for smartcard login.