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

Question

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.

Error in Client Browser

Users get this on their own workstations and the workstations of people who can log in successfully. For this reason, it cannot be a client browser issue.

Can’t reach this page

• Make sure the web address https://MyWebSite is correct
• Search for this site on Bing
• Refresh the page

More information The connection to the website was reset. 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   sc-status   sc-substatus    sc-win32-status time    cs-uri-stem
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\User 443     GET         200         0               0               17      /HMSLoginController.asp
1/1/2000 19:30  First IP    Server\User 443     POST        302         0               0               4       /EntryBanner.asp
1/1/2000 19:30  First IP    Server\User 443     GET         200         0               0               22      /EntryBanner.asp
1/1/2000 19:30  First IP    Server\User 443     GET         200         0               0               4164    /
1/1/2000 19:30  First IP                443     GET         500         0               64              637     /

Request Trace

Partial trace list of the 402.2 error:

4. -GENERAL_REQUEST_HEADERS  Headers Connection: Keep-Alive Accept: text/html, application/xhtml+xml, image/jxr, / Accept-Encoding: gzip, deflate Accept-Language: en-US Host: X.com User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko DNT: 1

5. -GENERAL_GET_URL_METADATA  PhysicalPath
   AccessPerms 617

6. -HANDLER_CHANGED  OldHandlerName
   NewHandlerName StaticFile NewHandlerModules StaticFileModule,DefaultDocumentModule,DirectoryListingModule NewHandlerScriptProcessor
   NewHandlerType

7. -AUTH_START  AuthTypeSupported 2 AuthTypeSupported Basic

8. -AUTH_END 

9. -AUTH_START  AuthTypeSupported 128 AuthTypeSupported MapCliCert

10. -AUTH_END 

11. -AUTH_START  AuthTypeSupported 4 AuthTypeSupported NT

12. -AUTH_END 

13. -AUTH_START  AuthTypeSupported 128 AuthTypeSupported MapCliCert

14. -AUTH_REQUEST_AUTH_TYPE  RequestAuthType 128 RequestAuthType CertMap

15. -AUTH_END 

16. -AUTH_START  AuthTypeSupported 16 AuthTypeSupported Digest

17. -AUTH_END 

18. -AUTH_START  AuthTypeSupported 1 AuthTypeSupported Anonymous

19. -AUTH_REQUEST_AUTH_TYPE  RequestAuthType 1 RequestAuthType Anonymous

20. -AUTH_SUCCEEDED  AuthType 4 NTLMUsed false RemoteUserName
    AuthUserName
    TokenImpersonationLevel 2 AuthType NT TokenImpersonationLevel ImpersonationImpersonate

21. -USER_SET  AuthType
    UserName
    SupportsIsInRole true

22. -AUTH_END 

23. -GENERAL_SEND_CUSTOM_ERROR  HttpStatus 401 HttpSubStatus 2 FileNameOrURL 401.htm

24. -GENERAL_FLUSH_RESPONSE_START 

25. -GENERAL_RESPONSE_HEADERS  Headers Content-Type: text/html Server: Microsoft-IIS/7.5 WWW-Authenticate: Negotiate WWW-Authenticate: NTLM X-Powered-By: ASP.NET

Configuration

I confirmed that the server has all the latest certs using a program distributed by the entity that made our root certificate. I tested the client certificates against the CRL and the server's OCSD call.

IIS Server Config

Authentication: Only Active Directory Client Certificate Authentication is enabled - others disabled Authorization Rules: Deny Anonymous Users - only entry

Site Config

Authentication: Anonymous Authentication is enabled and Windows Authentication is enabled Authorization Rules: Allow webUsers (a Local Server User Group) - only entry Configuration Editor: system.webServer/security/authentication/iisClientCertificateMappingAuthentication defaultLogonDomain enabled True LogonMethod ClearText manyToOneCertificateMappingsEnabled True manyToOneMappinqs (Count=19) oneToOneCertificateMappingsEnabled False oneToOneMappings (Count=0)

Users

Each user set up in the manyToOneMappinqs has a corresponding local server user account. The local user accounts are all in the webUsers group which has permissions to the website. Each user has two mapping rules: Issuer ("O") which is the entity that created the smartcards and Subject ("CN") which is unique to each user.

The list of users is split between two files: the web site's web.config file and the server's applicationhost.config file. The combined users make up the list in the Site's configuration editor.

Answer 1

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.