Care, Share and Grow! : Authentication

Avoid this confusion around Client certificate mapping in IIS 6.0/7.0

Saurabh Singh — Sat, 13 Jun 2009 03:05:15 GMT

I just wanted to add this quick post around Client certificate Mapping on IIS. This is focused on 1-to-1/Many-to-1 mapping in IIS 6.0/7.0.

If you are interested to know more about configuring Client certificate mapping in IIS 6.0 please check this post of mine and for IIS 7.0 this is an excellent article.

Recently a colleague of mine and I was working on this issue for one of our internal teams and after some real slogging we figured out that one *cannot* set this mapping at any Virtual directory/Application level in IIS.

One has to set the Client certificate mapping at the specific Web site level only!

This is wrong!

This is right!

I couldn't find a documentation on this so thought of putting this as a short post for general audience in case someone is scratching their head over this.

Cheers!

Service Principal Name (SPN) checklist for Kerberos authentication with IIS 7.0

Saurabh Singh — Thu, 25 Dec 2008 04:01:15 GMT

In continuation to one of my earlier posts which focused on IIS 6.0 this post is more about the confusion that may arise around SPNs for setting up Kerberos authentication in IIS 7.0. IIS 7.0 has a new Kernel-mode authentication feature using which the ticket for the requested service is decrypted using Machine account (Local system) of the IIS server. It no longer depends upon the application pool Identity for this purpose by default and in turn improves the performance.

Here is how it looks like.

So what does this mean?

You no longer need to worry about the correlation between HTTP SPNs and the Application pool Identity that was required in the earlier version i.e. IIS 6.0. But that's not blindly true. There has been some confusion whether we don't have to care at all about SPNs or may have to depending upon the settings. Here is a checklist to give more clarity for different scenarios that you may fall under:

SCENARIO 1a

IIS 7.0 Web Site/Application
Authentication	Integrated Windows authentication
Application Pool Identity	NETWORK SERVICE
Kernel-Mode authentication	Enabled (<attribute name="useKernelMode" type="bool" defaultValue="true" /> in the ApplicationHost.config file)
Site URL	Accessed with the NetBIOS name, like http://<myIISserver-NetBIOS-name>/Default.aspx

SPNs will be required ONLY for the IIS machine account:

HOST/<myIISserver-NetBIOS-name>

HOST/<myIISserver-NetBIOS-name.fully-qualified-domainname> for e.g. HOST/myIISserver.mydomain.com

***Note: By default HOST/<myIISserver-NetBIOS-name> and HOST/<myIISserver-NetBIOS-name.fully-qualified-name> is already added for the machine account when a machine is added to a domain and HTTP forms a part of HOST. So you may not have to do anything special here for SPNs. Everything should be set by default.

You can check the set of existing SPNs for the machine account by running the following command:

> Setspn.exe -L <myIISserver-NetBIOS-name> or directly using a Snap-in like Adsiedit.msc.

SCENARIO 1b

IIS 7.0 Web Site/Application
Authentication	Integrated Windows authentication
Application Pool Identity	Custom account for e.g. Domain1\Username1
Kernel-Mode authentication	Enabled (<attribute name="useKernelMode" type="bool" defaultValue="true" /> in the ApplicationHost.config file)
Site URL	Accessed with the NetBIOS name, like http://<myIISserver-NetBIOS-name>/Default.aspx

The SPN requirements remain the same as above. You don't have to add SPNs like http/<myIISserver-NetBIOS-name> for the Domain1\Username1 unlike in IIS 6.0 (where we had to add an SPN of the form http/<myIISserver-NetBIOS-name> for the Application Pool identity).

SPNs will be required ONLY for the IIS machine account:

HOST/<myIISserver-NetBIOS-name>

HOST/<myIISserver-NetBIOS-name.fully-qualified-domainname> for e.g. HOST/myIISserver.mydomain.com

You can check the set of existing SPNs for the machine account by running the following command:

> Setspn.exe -L <myIISserver-NetBIOS-name> or directly using Snap-in like Adsiedit.msc.

SCENARIO 2a

IIS 7.0 Web Site/Application
Authentication	Integrated Windows authentication
Application Pool Identity	NETWORK SERVICE
Kernel-Mode authentication	Enabled (<attribute name="useKernelMode" type="bool" defaultValue="true" /> in the ApplicationHost.config file)
Site URL	Accessed with a Custom Host name, like http://www.mysite.com

SPNs will be required ONLY for the IIS machine account in the following format:

HTTP/<site-custom-name> for e.g. HTTP/www.mysite.com

You can add an SPN using Setspn.exe like

> Setspn -a http/<site-custom-name> <myIISserver-NetBIOS-name>

where <myIISserver-NetBIOS-name> is the IIS machine account and <site-custom-name> is the custom host/host header name for the Web Site URL.

e.g. > Setspn -a http/www.mysite.com <myIISserver-NetBIOS-name>
*The command is NOT case sensitive

You can check the existing set of SPNs for the machine account by running the following command:

> Setspn.exe -L <myIISserver-NetBIOS-name>

SCENARIO 2b

IIS 7.0 Web Site/Application
Authentication	Integrated Windows authentication
Application Pool Identity	Custom account for e.g. Domain1\Username1
Kernel-Mode authentication	Enabled (<attribute name="useKernelMode" type="bool" defaultValue="true" /> in the ApplicationHost.config file)
Site URL	Accessed with a Custom host/Host header name, like http://www.mysite.com

SPNs will be required ONLY for the IIS machine account and NOT for Domain1\Username1 account unlike in IIS 6.0.

HTTP/<site-custom-name> for e.g. HTTP/www.mysite.com

You can add an SPN using Setspn.exe like

> Setspn -a http/<site-custom-name> <myIISserver-NetBIOS-name> where <myIISserver-NetBIOS-name> is the IIS machine account and <site-custom-name> is the custom host/host header name for the Web Site URL.

e.g. > Setspn -a http/www.mysite.com <myIISserver-NetBIOS-name>
*The command is NOT case sensitive

You can check the existing set of SPNs for the machine account by running the following command:

> Setspn.exe -L <myIISserver-NetBIOS-name>

Special case of running IIS 7.0 in a WEB FARM

If you are running IIS 7.0 server in a Web farm the KDC will not know in advance which individual server the request may go to and hence ticket decryption may fail. Hence in such a scenario instead of registering SPNs under a specific machine account use a domain account. I am not a SharePoint guy but based on what I have read on the Web this scenario is also applicable to a single SharePoint server configuration.

There are two ways to go:

Either

Disable Kernel mode authentication and follow the general steps for Kerberos as in the previous IIS 6.0 version. Refer this.

Or,

[Recommended for Performance reasons]

Let Kernel mode authentication be enabled and the Application pool's identity be used for Kerberos ticket decryption. The only thing you need to do here is:

1. Run the Application pool under a common custom domain account.

2. Add this attribute "useAppPoolCredentials" in the ApplicationHost.config file.

<system.webServer>
   <security>
      <authentication>
         <windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true" />
      </authentication>
   </security>
</system.webServer>

Remember there is no GUI setting for this. You need to modify the ApplicationHost.config file from

<%SystemDrive%>/Windows/System32/inetsrv/config folder on the IIS 7.0 machine.

3. Add the SPNs in the form:

http/<virtualhost-name> and

http/<virtualhost-name.fully-qualified-name> for the Application Pool Identity.

Ensure that we don't have such an entry for SPNs for any other account including IIS server machine account.

***If we have the same SPN mapped to multiple accounts (be it a machine or an user account) it leads to Duplicate SPNs and will break Kerberos.

Hope this helps!

Who knows! You may be missing these points for Kerberos authentication failures for Web applications...

Saurabh Singh — Sun, 16 Nov 2008 13:11:00 GMT

I am sharing here some of the general + elusive + ignored + must-have info that you may want to recheck when you are troubleshooting a kerberos cum delegation failure scenario and feel like reaching nowhere near the end of the tunnel (resolution!). These are my personal checklists based on experiences of troubleshooting kerberos related gotchas. I had also posted my first article on troubleshooting kerberos issues way back in January 2007. This article is a kind of continuation to it since I still see a lot of people missing some finer points here and there. Please check this post for the general kerberos checklist.

So here I go...

Kerberos was designed and is supported in Intranet scenarios. If you are trying to make it work over an Internet environment you may want to recheck other options (unless you are going ahead with Protocol transition for e.g. from Basic/NTLM to kerberos). Remember that for kerberos to work, the client (e.g. client browser) should be able to connect to the Domain Controller(KDC) to acquire the tickets. If your clients are coming over the Internet they may not be having access to the Domain Controller. Most security conscious organizations keep their DC away from Internet facing network in order to reduce the likelihood of it getting compromised. You may have to check with the firewall/proxy settings etc. and more...to make this work which I personally feel is not a good idea.

Kerberos will work for resources (client-IIS-Backend DB etc.) in the same domain or in trusted domains within the same forest. Either have mutual trust (preferable) between the domains in the forest or at least have the IIS domain trust the client's domain. If your clients are coming from a domain across the forest with an external trust we need to do extra work. Refer to this article. I am not an AD guy .

Here is an excerpt from the same article:

The Windows Server 2003 family supports domain trusts and forest trusts. We know what domain trusts are: they allow a user to authenticate to resources in another domain. Like always, all domain trust relationships have only two domains in the relationship: the trusting domain and the trusted domain. There are one-way trusts (unidirectional) and two-way trusts (bi-directional) and a Windows Server 2003 domain can establish a trust among other Windows 2000/2003 domains in the same or different forest, Windows NT 4.0 domains and Kerberos V5 realms. In Windows 2000, if users in one forest needed access to resources in a second forest, an administrator could create an external trust relationship between the two domains, which is one-way and non-transitive. This meant that in order to extend your trust to other domains in the forests you had to explicitly configure each and every one of them.
Windows Server 2003 offers a forest trust: two-way Kerberos-based transitive trust between Windows Server 2003 forests, enabling a transitive trust between all the domains in the two forests. Forest trusts are established between the root domain of both forests and can be either one way or two way. A Few things to remember are to make sure all domain controllers in both forests are running Windows Server 2003, with a correctly configured DNS infrastructure and forest functionality level set to Windows Server 2003 mode in both forests.

Many a times you will see something as shown below when connecting to a web site over Windows integrated authentication. You may have checked all the basic settings for kerberos and things look okay, yet somehow mysteriously this is failing to work with kerberos. After three attempts it will fail with 401.

You typed in http://www.test.com in the browser and it seems to be connecting to some other machine name as shown below in the picture.

Look at the IE prompt which shows that we are trying to connect to testkrb.saurabh1.com although web site URL in the browser's address box shows we are trying to reach the site www.test.com. Ideally we should have seen "Connecting to www.test.com" and not "connecting to testkrb.saurabh1.com". Equivalently try a ping to www.test.com and see what it resolves to.

If you see such a scenario it's time to check whether the web site URL is an Alias(CNAME) or a DNS Host (A) Record. There is a known issue with using Alias for a site which may not allow kerberos to work. There are some details which I don't want to get into at this point, probably some other day. In short, it tries to look into the KDC based on the SPN http/testkrb.saurabh1.com and not an SPN of the form http/www.test.com.

Solution:

Server side: Either go ahead and change the DNS entry to add www.test.com as a DNS Host (A) Record and not CNAME.

or,

Client side: Apply this hotfix to IE browser on the client(s) (I don't see this as a good option).

I would recommended to use a host name instead of an IP address to access a web site meant for a kerberos based authentication. You may see it working just fine even with IP address in some scenarios but then it may pose problems when we have client and servers in different domains etc. You may get into an issue wherein domain2 will not give any referral back to to the client to look into domain1 for the SPN. This can occur if IP address is being used to look for a service. In such a case even after adding SPN's for IP addresses, Kerberos won't work and will fall back to NTLM.

If your web site is configured to use a non-default HTTP port like 81 instead of 80, users will access the site as http://www.test.com:81 and not http://www.test.com (browsers append ':80' as the default port if none specified). Here lies the confusion when you add SPNs for the web site. Don't have an SPN with the port number appended even if you are running your site on a non-default port.

If the site is accessed as http://www.test.com:8080 SPN will still be of the form http/www.test.com and not http/www.test.com:8080.

Refer to this article. It confuses me further but I would suggest go ahead with the default as above.

Consider a scenario wherein two applications http://servername/app1 and http://servername/app2 are running under a NETWORK SERVICE & a domain user Application Pool identities respectively .
The SPNs requested will be http/servername in both the cases, and since we can’t have duplicate SPNs; kerberos may not work for either of the applications. We need to then either use the same Application Pool identity or separate host headers for the web sites and set SPNs accordingly. NOTE: This issue is taken care of in IIS 7.0 with Kernal mode authentication.
Again,if you are using two web sites with same name but different ports like http://servername:81 and http://servername:82; by default IE will request a ticket for the same SPN HTTP/servername.
We would then need an hotfix for the client machines, Refer to this.
When do we have Duplicate SPNs leading to kerberos not working?

Duplicate SPN arises from the fact that the same SPN is mapped to multiple accounts, it may be a machine or an user account. Doesn't matter. Mapping to multiple accounts will lead to duplicate SPNs!

*Remember: You can have multiple different SPNs registered under the same account but not vice-versa, i.e. you should *not* have the same SPN registered under multiple accounts.

IIS uses NTLM credentials when accessing a resource for a local request coming to it (i.e. client say IE, and IIS are on the same box). It may use Kerberos or NTLM from a separate client machine depending on the setup.The best way to check if delegation is working is from a client machine which is not same as the IIS server. NTLM doesn't support delegation. Kerberos does!

At times making sure all the settings on the client, IIS, AD, back-end (if any) to make kerberos work properly doesn't help, and in such cases make sure that we purge all the kerberos tickets using Klist or Kerbtray on the client. In fact if possible logoff and re-login to the client machine from where you are testing the web application for kerberos authentication so that the client is issued a fresh ticket.

*Check the following link for my other posts related to Kerberos.

Till next time...

How to achieve a feature similar to single logon for multiple web applications using Basic authentication

Saurabh Singh — Fri, 10 Aug 2007 01:23:00 GMT

Here is something which I recently figured out. This may be very simple to many but thought of sharing it for a wider audience.

Let's say you have two ASP.Net web applications running on two different servers.
Now, assuming you have a constraint wherein you cannot use Windows integrated authentication (in cases where in you have some JSP application running on Websphere and another Asp.Net app on IIS server or any multi-platform scenarios), and you want to access the 2nd web app internally from the 1st web app for authenticated users. Now since you cannot use windows integrated authentication (e.g. Websphere doesn't support windows integrated authentication) the only option is to use Basic authentication which is supported across multiple platforms.

So here Windows integrated and anonymous authentication are out of picture and you are left with Basic authentication. Now if you want to access the 2nd Web app internally from the 1st web app and since both are configured for Basic authentication what will you do. IIS prompts for basic authentication and since you are trying to access it internally from the 1st web app you may get into issues wherein IIS will throw 401 Unauthorized error.

1st Web app ---> 2nd Web app
(Basic Authentication) (Basic Authentication)

Had Windows integrated authentication been supported we could have gone ahead with Kerberos but now that is out of picture.

This is what I figured out. If a user is authenticated using basic authentication, an Authorization header is passed (after user enters the credentials and is authenticated) to the server as part of the request header. Now this header will remain the same for a combination of username and password. Web server recognizes the future requests for the same user using the same header.

Now if you try to call the 2nd web app URL through the 1st web app using httpwebrequest you will get 401 unauthorized. This is because the web request from the 1st web app does not send the Basic authentication token to the destination by default. It sends a new request to the 2nd web app and since 2nd web app is configured for basic authentication only and no anonymous authentication it will fail with 401.

To avoid getting into such issues you can modify your code in the 1st web app such that it also appends the Authorization header (which it gets during the first basic authentication done by the 1st server) along with the new http request to the 2nd web app (now all this assuming the user is allowed to access both the websites on both the servers).

Here is code snippet on the 1st web app which calls the 2nd web app internally.

Default.aspx
==============

Default.aspx.cs
===============

Assuming web app2 being http://shrek:8080/default.aspx

Here is the error thrown on the browser:

Now try adding the following lines and browse to the page in web app1. You should be able to access the web app2 without any issues.

Default.aspx.cs
===============

If you notice we are resending the authorization header that we got during the 1st web app authentication process. The same authorization header when accessing the 2nd web app nullifies the requirement for a new authentication handshake between IIS and the its client request. If we did not pass the authorization header to the 2nd web request IIS has to renegotiate a new authentication process with its client in order to get the necessary credentials for allowing access to its contents. Thereby throwing error 401 in our case since we are calling the 2nd web app internally in the code. The above scenario can work for N number of websites which can easily be greater than 2.

Do remember to add resp.close() and reader.close() in the above code section at the end.

If IIS is configured for basic authentication only it will look for Basic Authorization header before serving the request.

Also remember if you use just a response.redirect from 1st web app to 2nd web app it will work just fine but you will be prompted twice for basic authentication. This is because you get prompted for credentials the first time when you access the 1st web app and then again when a new request is sent for the 2nd web app through response.redirect it doesn't have the authorization header by default (Remember response.redirect cause a new request to be sent to the server from the client's end). So IIS again prompts you for credentials.

If it doesn't find an authorization header it will send a 401 response back asking the client to resend the request with a valid authorization header. Here above we are adding an authorization header along with the request in the first place so that IIS need not send 401 response.

***Basic authentication sends credentials in clear text and is base64 encoded. So it can be easily decoded by a sniffer. So its recommended to use SSL with basic authentication.

Troubleshooting Anonymous authentication failures in IIS

Saurabh Singh — Sun, 01 Jul 2007 21:08:00 GMT

Recently I was checking MSDN and KBs for a quick check on troubleshooting anonymous authentication, and sadly I could not find a single article devoted to it (that's strictly my personal experience). We often get calls on issues related to Anonymous authentication failures and this is something which I feel a user can fix oneself without requiring our support. My aim in this post is to ensure people have a good troubleshooting strategy for anonymous authentication failures.

As with all my posts I won't get into much of concept building stuffs here on anonymous authentication in IIS; reason again being the same, you will find tonnes of articles on the Net talking about it and I don't want to be another one.

So in brief Anonymous authentication in IIS is a type of access wherein any user can freely access the site. It's like a public website open to all.

So let's get started....

Anonymous authentication uses a local or domain account when user tries to access a webpage in IIS (By default it is of the form IUSR_<machinename>).

All the webpages which have anonymous authentication will use an account in order to access a page, and depending upon whether the account has permission or not the page will be rendered. Typically if anonymous authentication fails, you will see 401.1 in the error page shown by IIS. This means that Anonymous user account for that page doesn't have necessary permissions to the page or else some other settings like Domain or local policy is restricting the access.

If you have set only anonymous authentication for your web resource (that means no other authentication like Windows integrated or Basic ), and it fails then you will be shown 401.1 directly without any challenge which generally prompts to enter credentials.

Wanna know how IIS negotiates an authentication, check this.

If you want to check the anonymous username being used for a website or a virtual directory, type in this command at the following location:

<Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs get w3svc/anonymoususername

or,

<Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs get w3svc/<Website Identifier>/Anonymoususername

or,

<Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs get w3svc/<Website Identifier>/<Virtual directory>/anonymoususername

[If you get the result like: The parameter "anonymoususername" is not set at this node, it means it is inheriting the settings from its parent level.]

If you want to check where all Anonymous username is set at a webserver level, you can type in:

<Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs find anonymoususername

Typically the Anonymous username is in the form of IUSR_<machinename>, wherein machinename is the server name.

Although you can set it to a different value by manually changing it. It can be a local account to the server or a domain account.

A caveat here, it's a security risk if you make anonymous username as part of an Administrator group (remember it allows access to everyone on the net without asking for credentials).

To set an anonymous username at a website level, you can type in:

<Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs set w3svc/anonymoususername <your desired username> (Remember to include quotes around the username). [This setting is at the global level, i.e. for all the websites in the server provided you don't manually override the settings at a specific website or Virtual directory level]

<Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs set w3svc/<Website Identifier>/anonymoususername <your desired username> [At a specific website level]

<Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs set w3svc/<Website Identifier>/<Virtual directory>/anonymoususername <your desired username> [At a specific Virtual directory level in a specific website]

I will move forward with specific issues one by one:

Anonymous user account is locked out:

Ensure that the account is not locked, disabled or expired.

Password Synchronization issues:

I have seen a lot of support calls (I mean a LOT) where password synchronization has been the issue, and this is very very simple to fix.

Anonymous username's password are stored in two places in IIS 6.0: In the IIS metabase and in the SAM database.

If the password at these places are not synchronized (not same), anonymous authentication will fail. They have to be same.

So do this as the first step in troubleshooting:

1) Find out how many places we have the anonymousername set by following the command I mentioned above. Here I mention it again:

<Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs find anonymoususername

2) If you have it set at multiple places, find out the specific site you are having problem with. Check the anonymous username for it and then check the password.

<Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs get w3svc/<Website Identifier>/anonymoususerpass

[You may find the password in encrypted format like ************. In such a case you need to modify the adsutil.vbs file to get the exact password. Open Adsutil.vbs in notepad from the above location and search for the function "IsSecureProperty(ObjectParameter,MachineName)".

In this function IsSecureProperty(ObjectParameter,MachineName), you will find the following code:

Function IsSecureProperty(ObjectParameter,MachineName)

On Error Resume Next
Dim PropObj,Attribute
Set PropObj = GetObject("IIS://" & MachineName & "/schema/" & ObjectParameter)
If (Err.Number <> 0) Then
ReportError ()
WScript.Echo "Error trying to get the property: " & err.number
WScript.Quit (Err.Number)
End If
Attribute = PropObj.Secure
If (Attribute = True) Then
IsSecureProperty = True <--------
Else
IsSecureProperty = False
End If
End Function

In the highlighted line above, change the value to False, save and now rerun the adsutil.vbs command and you should see the actual password]

or if you have it set at the global level only, check this:

<Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs get w3svc/anonymoususerpass

Copy the password from here and go to Computer management->System Tools->Local Users and Groups->Users

You should find the username (By default, IUSR_<machinename> is used by IIS) [Unless you have Domain controller and Web server running on the same box. In such a case you need to look for the domain user name under Active Directory Users and Computers. I will talk about DC and IIS running on the same box later, this is really important!]

Change the password for Username (or, IUSR_<machinename>), by pasting the password that you got from metabase.

Ideally, if the issue was with Password synchronization your problem should get resolved at this point :) If not, then move on....

NTFS permission for the requested web resource:

NTFS permissions not set properly for the content can also cause 401.1 (although you should typically see 401.3 Access denied due to ACL). Ensure that the page we are trying to access has necessary NTFS permissions for Anonymous username (or the group that anonymous username belongs to). Ensure that Anonymous user account is part of the Users group.

Policy settings:

If your issue did not get resolved by Password synchronization, then Local security policy (or, Domain security policy) can be a very probable reason. Please follow the following articles religiously.

Default permissions and user rights for IIS 6.0 (IIS 6.0)

How to set required NTFS permissions and user rights for an IIS 5.0 Web server (IIS 5.x)

Check this too.

Error message when you try to view a Web site that is hosted on Internet Information Server 6.0 by using anonymous access: "401.1 Unauthorized: Logon failed"

Typical reasons being:

- Anonymous username being a part of Guests group (During IIS installation, IUSR_<machinename> is added to the Guests group by default), and Guests group being denied access to some web folders and/or denied access because of local/domain policy).

Suggestion: Make sure that either you remove the anonymous username from the Guests group and/or remove the Anonymous username from any of the Deny policy settings (You can do this by going to the Local Security policy->Local Policies-> User rights assignment).

- The account is corrupted because of some reason like corrupted SID, moving the server from one domain to another etc.

Suggestion: First try adding the Anonymous username to the Administrators group to check whether you can access the web page or not. If it works it means it's an issue most likely with the permission for that account. If it still does not work, then there is some thing wrong..may be Policy settings or a corrupted account. Change the Anonymous user account to a different account and see if it works (be sure to make that account part of IIS_WPG group). If it works then it's a corrupted account. Recreate the IUSR and IWAM accounts (you can recreate by deleting existing IUSR_machine and IWAM _machine and then doing an IISRESET. IISRESET will recreate the IUSR and IWAM accounts for you) or manually creating a new user.

- Check this The account that is used for anonymous access may be unexpectedly locked out in IIS 6.0 or in IIS 5.0

At times you may see that HTML pages are running fine but not ASP pages. They might throw error like 401.3 etc. Check whether Users group has permission on ASP.dll at the <systemdrive>\wind*\system32\inetsrv folder.

Account Lockout:

Now something that creates confusion among a lot of people. At times people see their anonymous account getting locked intermittently and there seems to be no valid explanations for it.

Scenario: You have set anonymous username at multiple levels in IIS.

Let's say you have different usernames at the following level:

Global Web Sites level {IUSR_m1}

Website 1 {IUSR_m2}

        VD1   {IUSR_m3}

        VD2    {IUSR_m2}

        VD3    {IUSR_m2}

Website 2 {IUSR_m2}

Now, let's assume you have different passwords at different levels. Now in the SAM database you can have only one instance of an account and hence only one password for it. Let's say you accidentally change the password for IUSR_m2 in the metabase at Website1 ->VD2 level and forget to change the password at the Website1, Website1->VD3 and/or Website2 level. Now since the password has to match in the SAM metabase too, only one of these will work. Also by mistake a wrong password can be set at a given level.

1) If you changed IUSR_m2's password in the SAM database to reflect Website1->VD2, then Anonymous authentication works fine when you access a resource from Website1->VD2. Although now, anonymous authentication will fail when you access a resource from any of Website1, Website1->VD3 or Website2 levels.

2) If you have the IUSR_m2's password in the SAM metabase reflecting the password set at any of Website1, Website1->VD3 and Website2 (assuming all of them have same password for simplicity sake), then anonymous authentication will succeed when you access a resource from any of the above levels, but will fail when you access a resource from Website1->VD2 level.

Now most servers have an Account lockout policy after certain invalid logon attempts. So if users try to access the Web resources from different levels, at one point of time because of multiple attempts Anonymous user account will get locked out and this will block access from all the levels irrespective of the matching passwords in Metabase and SAM database.

So IUSR_m2 might get locked intermittently because of the above scenario and will give unpredictable results. That's why I recommend to use a single Anonymous username at the global level only and let all the websites inherit from there,or else use completely distinct accounts at various levels (it again finally depends upon your requirement specific to the system).

IIS and Domain Controller (DC) on the same server:

Also, if your IIS server is a DC then you need to check:

<Anonymous useraccount>-->Properties-->Account-->Logon Hours..., [Ensure we have Logon Hours permitted for the account]

and <Anonymous useraccount>-->Properties-->Account-->Log On To..., [Ensure we have Logon to the machine enabled]

Please keep this handy when you are troubleshooting issues on a DC for IIS authentication.

Generally, DCs are very restricted when it comes to Permissions and access policies. Hence we have seen a lot of issues related to anonymous authentication failures on DCs. Microsoft recommends not to use a machine both as a DC and an IIS server from Security and Performance perspective.

Client Certificate revisited....How to troubleshoot client certificate related issues

Saurabh Singh — Sat, 09 Jun 2007 19:18:00 GMT

Well, I am back to Client certificate again, guess the reason being a lot of support calls that we getting off late are related to any of the following four errors, especially the first two.

403.7

403.13

403.16

403.17 ( I will cover .16 and .17 very briefly since they are very self-explanatory and easy to troubleshoot)

Earlier I had discussed the setup of the client certificate with IIS and AD for authentication mapping etc.

Here I will discuss the troubleshooting strategies on client certificate related errors that are listed above.

To understand how Client certificate is used while accessing a resource on the server, you may prefer to look at this brief but quite explanatory KB by David Dietz from IIS support.

http://support.microsoft.com/kb/907274/en-us

So here we go...

1) 403.7

We see that 403.7 can be thrown by IIS when Client certificate is required and the browser is not sending the client certificate details to the web server (IIS). Either the client did not send the certificate for some reason or else the client did not have a certificate issued by a CA that was also trusted by IIS server. If the client sends a certificate which is not mutually trusted by both client and the server you may see this error.

You may get a meaningful error like this in the browser:

HTTP Error 403 403.7 Forbidden: Client certificate required
This error occurs when the resource you are attempting to access requires your browser to have a client Secure Sockets Layer (SSL) certificate that the server recognizes. This is used for authenticating you as a valid user of the resource.
Please contact the Web server's administrator to obtain a valid client certificate.

To start with, follow this KB http://support.microsoft.com/kb/332077/en-us

You need to make sure that the client certificate is issued by a CA which is in the trusted root CA store on both the server and the client machine. Confirm whether the trusted root CA is part of CTL. The reason being that if your certificate's CA is not in the CTL; although present in the trusted root CA store in the server machine, you may still see the error.

A CTL is a list of trusted certification authorities (CAs) that can be used for client authentication for a particular Web site . You can use CTLs to configure your Web server to accept certificates from a specific list of CAs, and automatically verify client certificates against this list. Only users with a client certificate that is issued by a CA in the CTL can gain access to the server.
Each Web site on your server can be configured to accept certificates from a different CTL. You may want to do this if you need a different list of trusted CAs for each Web site.

If CTL is present, this is the list which is actually used to check for CA's which can issue client certificate to a user. If it is disabled then root CA store will be used for the above. Also make sure that the certificate is a valid client certificate. Make sure it is intended for user authentication.

Check the certificate for "Ensures the identity of a remote computer" and Enhanced Key usage says Client Authentication.

Also Using >Certutil -verify -urlfetch should show:

Verified Application Policies:
1.3.6.1.5.5.7.3.2 Client Authentication

You may also see 403.7 due to an update to the trusted Root CA list. This creates a list that is too large based on the size limit we enforce, the result being truncation of the list when this is sent to the client during the client certificate handshake. The limit is based on data size not CA count so there is no way to say this happens at a certain count of trusted CA’s.
To resolve this we need to delete some of the expired and unused/unknown trusted root certificates from the Trusted Root Certification Authorities list until it is working again.

The problem can also be identified when the following entry is logged on the Web server. It is quite explanatory in itself.

Event Type: Warning
Event Source: Schannel
Event Category: None
Event ID: 36885
Date: 2/9/2007
Time: 9:32:44 AM
User: N/A
Computer: USMASVGDOIM259
Description:
When asking for client authentication, this server sends a list of trusted
certificate authorities to the client. The client uses this list to choose a client
certificate that is trusted by the server. Currently, this server trusts so many
certificate authorities that the list has grown too long. This list has thus been
truncated. The administrator of this machine should review the certificate
authorities trusted for client authentication and remove those that do not really
need to be trusted.

Trusted root certificates that are required by Windows Server 2003, by Windows XP,
and by Windows 2000
http://support.microsoft.com/kb/293781
931125 Microsoft root certificate program members (January 2007)
http://support.microsoft.com/default.aspx?scid=kb;EN-US;931125

2) 403.13

The error you may see in the browser will be as shown below:

HTTP 403.13 Forbidden: Client certificate revoked
The page requires a valid client certificate

For an understanding of this error message check KB 248058.

This error message means that the client sent a certificate, but either the certificate shows up as revoked in the issuing authority's Certificate Revocation List or the server could not retrieve a CRL from the issuing authority.

You need to crosscheck whether the client certificate is revoked or not with the respective CA.
If CA confirms the certificate as valid and not revoked then the issue could be with IIS being unable to retrieve CRL from the CA.

IIS , by default retrieves a CRL whenever it receives a client cert to make sure that cert is not revoked as long as local cache is expired. For this it contacts the CA to get the CRL which is a list of revoked certificates and compares the list with the presented client cert. If for any reason it cannot retrieve the CRL, it will go ahead and throw error message as 403.13 even if cert is valid and not revoked. This can happen in cases where some Proxy/firewall may block access to CDP to get the CRLs.

If a CDP extension is present in a certificate that is part of the certification path, IIS must be able to download at least one of the CRLs. If IIS is unable to resolve the CRL, it returns the HTTP 403.13 error. In this case, we cannot access the above CDP so we fail. Prior to MS04-011 Win2k did not limit validation based on this. However, we now require that the CDP be reachable when validating a certificate chain.
To work around this we must either use a reachable CDP in the client certificate or disable CertCheckMode on the IIS server, thus preventing it from doing any revocation checking.

So, if we are getting Client certificate revoked errors, then check to see if the server can get to the CRL distribution point specified in the client certificate and if it can and is still giving this error, then download the Root and Subordinate CA CRLs and install them on the IIS server so that it can get to it locally.

Also there is a metabase key in IIS called certcheckmode, which if disabled will stop IIS from trying to retrieve CRL checking. In such a case client cert will be accepted even if the cert is revoked. Disabling CRL checking is a quick way to test the cause.

The CertCheckMode property enables or disables Certificate Revocation List (CRL) checking. When CertCheckMode is set to a value greater than 0 (CertCheckMode>0), the CRL does not search for certificates that have been revoked. When CertCheckMode is equal to 0 (CertCheckMode=0), the CRL searches for certificates that have been revoked.

With CertCheckMode disabled, IIS will no longer try to verify revocation of incoming client certificate requests. The client certificates will still need to be within their valid dates and still must be trusted by the IIS server (the IIS server must trust the issuing CA).

We disable the Certcheckmode key by setting it to 1.

>C:\Inetpub\Adminscript\cscript.exe adsutil.vbs Set W3SVC/<Website identifier>/CertCheckMode 1

I had seen an interesting case where 2 of the websites were accepting the same client cert whereas another one was not accepting it on the same web server.

Checking the metabase.xml for the server showed this:

Non-Working site:

=================

<IIsWebServer Location ="/LM/W3SVC/690402"

AuthFlags="0"

LogPluginClsid="{FF160663-DE82-11CF-BC0A-00AA006111E0}"

SSLCertHash="8bcfc28e346bb9ec49374d87479021354349cf85"

SSLStoreName="MY"

SecureBindings="XX.XX.XX.X:443:"

ServerAutoStart="TRUE"

ServerBindings="XX.XX.XX.X:80:"

ServerComment="CDB"

</IIsWebServer>

Working Site:

=============

<IIsWebServer Location ="/LM/W3SVC/90326589"

AuthFlags="0"

CertCheckMode="1"

LogPluginClsid="{FF160663-DE82-11CF-BC0A-00AA006111E0}"

SSLCertHash="a640634e38ff20ebd8c29c32aae635e5575e57f6"

SSLStoreName="MY"

SecureBindings="XX.XX.XX.Y:443:"

ServerAutoStart="TRUE"

ServerBindings="XX.XX.XX.Y:80:wcdb"

ServerComment="WCDB"

</IIsWebServer>

Look at the difference between them. You see CertCheckMode is absent in the Non-working site, and absence of this key is equivalent to it being enabled. So once we put the CertCheckMode set to "1" for non-working site we should be able to resolve the issue. But this means that CRL chekcing is disabled. You may downlaod the CRL on to the server or else open up the relevant ports in order to allow CRL to be retrieved.

Check the KB 294305.

You may also check KB 841632 if IIS 5.0 is in picture.

There was an interesting case, where users were getting 403.13 even when client cert was not revoked and we were able to access the get the CRL from the CDP for the client cert by accessing it through a browser. Yet after a lot of tracing and monitoring we found that there was a 4-level hierarchy in the certificate chain, with let's say Root CA1 ->Subordinate Root CA2->Subordinate Root CA3 -> Client certificate and one of the subordinate root CA's crl was not accessible. There are tools like certutil or SSLspy that can come handy. We ran certutil.exe -verify -urlfetch <location of the client cert.cer> on the IIS server and found that CRL retrieval for Subordinate Root CA2 was failing, and hence the issue.

So remember that we need to make sure that the CDPs for all the subordinate CAs certifcates in the chain should also be reachable.

Let's say for my client certificate, the Certification path shows:

Microsoft Corporate Root CA

|--> Microsoft Corp Enterprise CA 2

|--> Saurabh Singh

Here is the information for certificate "Saurabh singh"

CRL Distribution Points (Under Details->Field) shows:

[1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=ldap:///CN=Microsoft%20Corp%20Enterprise%20CA%202(4),CN=CRL,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=corp,DC=microsoft,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint
URL=http://corppki/crl/Microsoft%20Corp%20Enterprise%20CA%202(4).crl
URL=http://crl.microsoft.com/pki/mscorp/crl/Microsoft%20Corp%20Enterprise%20CA%202(4).crl

Authority Information Access shows:

[1]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://corppki/aia/Microsoft%20Corp%20Enterprise%20CA%202(4).crt
[2]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://www.microsoft.com/pki/mscorp/Microsoft%20Corp%20Enterprise%20CA%202(4).crt

Here is the information for certificate "Microsoft Corp Enterprise CA 2":

CRL Distribution Points (Under Details->Field) shows:

[1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=http://corppki/crl/mscrca.crl
URL=http://crl.microsoft.com/pki/mscorp/crl/mscrca.crl

Authority Information Access shows:

[1]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://corppki/aia/mscrca.crt
[2]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://www.microsoft.com/pki/mscorp/mscrca.crt

Now runnning the Certutil.exe as shown below:

cmd prompt> certutil.exe -verify -urlfetch cert.cer <-------the client certificate

Here is the output:

Issuer:
CN=Microsoft Corp Enterprise CA 2
Subject:
CN=Saurabh Singh
Cert Serial Number: 258a555c0004008b1c42

dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwRevocationFreshnessTime: 176 Days, 6 Hours, 5 Minutes, 17 Seconds

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 176 Days, 6 Hours, 5 Minutes, 17 Seconds

CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=Microsoft Corp Enterprise CA 2
Subject: CN=Saurabh Singh
Serial: 258a555c0004008b1c42
Template: AutoEnrolled Client Auth
48 b7 48 da 00 51 21 77 b3 e1 3a ce 98 7d 35 2f b7 e8 0c 1c
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Certificate AIA ----------------
Verified "Certificate (0)" Time: 1
[0.0] http://corppki/aia/Microsoft%20Corp%20Enterprise%20CA%202(4).crt

Verified "Certificate (0)" Time: 1
[1.0] http://www.microsoft.com/pki/mscorp/Microsoft%20Corp%20Enterprise%20CA%202(4).crt

---------------- Certificate CDP ----------------
Verified "Base CRL (821)" Time: 0
[0.0] ldap:///CN=Microsoft%20Corp%20Enterprise%20CA%202(4),CN=CRL,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=corp,DC=microsoft,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint

Verified "Base CRL (821)" Time: 0
[1.0] http://corppki/crl/Microsoft%20Corp%20Enterprise%20CA%202(4).crl

Verified "Base CRL (821)" Time: 1
[2.0] http://crl.microsoft.com/pki/mscorp/crl/Microsoft%20Corp%20Enterprise%20CA%202(4).crl

---------------- Base CRL CDP ----------------
No URLs "None" Time: 0
--------------------------------
CRL 821:
Issuer: CN=Microsoft Corp Enterprise CA 2
fd 19 3c 2f 0c 24 ea 1c 4a 5d df c4 26 2a b0 1b 98 48 ef 99
Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication

CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=Microsoft Corporate Root CA, O=Microsoft Corporation
Subject: CN=Microsoft Corp Enterprise CA 2
Serial: 610d1de0000000000019
Template: SubCA
17 0a 7b 9d 52 85 07 7e 74 1a f5 a0 6b db 05 78 9e bc f1 8d
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Certificate AIA ----------------
No CRL "Certificate (0)" Time: 0
[0.0] http://corppki/aia/mscrca.crt

No CRL "Certificate (0)" Time: 1
[1.0] http://www.microsoft.com/pki/mscorp/mscrca.crt

---------------- Certificate CDP ----------------
Verified "Base CRL (18)" Time: 0
[0.0] http://corppki/crl/mscrca.crl

Verified "Base CRL (18)" Time: 0
[1.0] http://crl.microsoft.com/pki/mscorp/crl/mscrca.crl

---------------- Base CRL CDP ----------------
No URLs "None" Time: 0
--------------------------------
CRL 18:
Issuer: CN=Microsoft Corporate Root CA, O=Microsoft Corporation
0e 70 65 69 a7 4c f9 7d 9f 50 7b db 9c e1 b8 27 9e 53 ba f4

CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0
Issuer: CN=Microsoft Corporate Root CA, O=Microsoft Corporation
Subject: CN=Microsoft Corporate Root CA, O=Microsoft Corporation
Serial: 443c2a54b59cd69d4c09b18a9b02eb55
d2 d3 8e ba 60 ca a1 c1 20 55 a2 e1 c8 3b 15 ad 45 01 10 c2
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Certificate AIA ----------------
No URLs "None" Time: 0
---------------- Certificate CDP ----------------
No URLs "None" Time: 0
--------------------------------

Exclude leaf cert:
8a cf e9 23 e2 d7 cd d1 f0 bb 05 6e 63 b5 31 95 6e 46 0d ad
Full chain:
5b fa 04 32 34 21 49 11 92 56 b3 ee 41 94 b4 b8 f3 f6 44 f2
------------------------------------
Verified Issuance Policies: None
Verified Application Policies:
1.3.6.1.5.5.7.3.2 Client Authentication
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.

If you notice the Certutil.exe tries to check the CRL accessibility by accessing the CRL Distribution points. The above command ouptput should give you an idea regarding the cause. You may see an error in accessing the CRL in the output above in cases where you get the above errors.

Here is something similar when you get an error:

---------------- Certificate CDP ----------------

Failed "CDP" Time: 0

Error retrieving URL: The specified network resource or device is no longer available. 0x80070037 (WIN32: 55)

ldap:///CN=CRL1, CN=xxxx, OU=xxxx, OU=xxxx. by ref. (limits liab.), O=xxxx, C=US?certificateRevocationList;binary,authorityRevocationList;binary,deltaRevocationList;binary

Failed "CDP" Time: 0

Error retrieving URL: The server name or address could not be resolved 0x80072ee7 (WIN32: 12007)

http://www.some_company.net/CRL/net1.crl

--------------------------------

Application[0] = 1.3.6.1.5.5.7.3.4 Secure Email

Application[1] = 1.3.6.1.5.5.7.3.1 Server Authentication

Application[2] = 1.3.6.1.5.5.7.3.2 Client Authentication

Application[3] = 1.3.6.1.5.5.7.3.3 Code Signing

Exclude leaf cert:

14 4c 46 42 11 66 a4 a9 42 70 ad b6 e0 1e 23 ca d4 9b 24 0e

Full chain:

fe 37 4a cf 76 3e 01 14 21 a6 c7 25 35 14 97 e5 91 87 e3 b7

Issuer: CN=A company, OU=PKI, DC=company, DC=com

Subject: OID.0.9.2342.19200300.100.1.1=ZALDI001, OU=People, OU=SAP, DC=company, DC=com

Serial: 42c550de

6e 33 5f 13 e1 67 ad 41 71 02 96 17 c7 57 c9 91 ea cb 1d 24

The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)

------------------------------------

Revocation check skipped -- server offline

Cert is an End Entity certificate

ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)

CertUtil: The revocation function was unable to check revocation because the revocation server was offline.

Ensure that the necessary firewall/network configuration changes to allow the IIS server to access ALL of the external CDP’s listed in the client cert’s revocation chain, or download the CRL(s) to the IIS server manually and set CertCheckMode to MD_CERT_CACHE_RETRIEVAL_ONLY (see this link http://technet2.microsoft.com/windowsserver/en/library/173427fd-eb90-44ef-8a9c-d7bb4ff41ab81033.mspx?mfr=true ). That will tell IIS to look at the CRL in its local store and not try to attempt to access the CRL via the CDP entries specified in the client cert.

One more confusing point that should be clarified here:

If you have a certificate chain, let's say: Root CA -> Intermediate CA1 -> Intermediate CA2 ->..... -><Your Client ceritficate>, then CRL checking will be done for all the Certificates in the hierarchy except the Root CA.

If you are really interested to dig further as to how Certificate Revocation etc. works at a lower level, here is a real exhaustive link to check it out.

http://technet.microsoft.com/en-us/library/af1e419e-ede5-8c4b-bf6e-1fb17658a99d.aspx

Another issue that pops up from time to time is:

"Choose a digital certificate" popup window in Internet Explorer is blank when attempting to use client certificates to authenticate against IIS.

This can happen in situations as explained earlier too in cases where:

The total size of the certificates in the Trusted Root Certification Authorities store on the IIS server was too large to send to the client. The list was truncated as a result.

The following event was written to the System log:
Event Type: Warning
Event Source: Schannel
Event ID: 36885
Description: When asking for client authentication, this server sends a list of trusted certificate authorities to the client. The client uses this list to choose a client certificate that is trusted by the server. Currently, this server trusts so many certificate authorities that the list has grown too long. This list has thus been truncated. The administrator of this machine should review the certificate authorities trusted for client authentication and remove those that do not really need to be trusted.

Resolution would be to Remove unused certificates from the Trusted Root Certification Authorities store on the IIS server, reducing the number of certificates.

Also another cause may be when the any of the Subordinate CAs->certificate->Details->Edit Properties button has Client Authentication disabled in the intended purposes.

Also this should be of help at times http://support.microsoft.com/kb/285069/

Also if we have certificate trust list(CTL) enabled, CTL that IIS sends is what the client uses to know if it has a client cert it can use.
Also there is a <12kb> limit on this and if the customer has applied the Trusted Root CA update, then we may not send the full list of trusted CA’s. Make sure that CA is in CTL as well as the size limit. You may want to revisit the article http://support.microsoft.com/kb/933430. Either install the hotfix if it is applicable or try deleting/moving to other store some of the unused/junk CAs from the Trusted Root Certificate Authority Store on the IIS server. That could do the trick for you!

Refer to one of our finest Escalation engineer (Andreas Klein)'s blog which talks about limiting the list of CA's allowed for Client authentication, without deleting the CAs from the store.

http://blogs.msdn.com/andrekl/archive/2005/04/19/409682.aspx

Also while you may have the certificate in your personal store (using the mmc snap-in it shows up properly), you may not see it in the IE browser. If you go through Internet Options->Content and click Certificates, it doesn’t show up at all. Open the certificate MMC and check whether the cert has a Private key or not.

If the General tab on the cert properties does not say at the bottom that you have a Private Key corresponding to this cert then you don’t, and this may lead to the above problem.

403.16 - Client certificate is untrusted or invalid.

This error message is primarily generated when the certificate that the client provided is improperly formed. It can also be generated if there are intermediate certification authorities in the certificate chain that are not trusted by the Web server.

403.17 - Client certificate has expired or is not yet valid

This error message is fairly self-explanatory. It means that the current date on the server is not within the valid date ranges that are presented in the client certificate. You may also want to ensure that the client certificate and its issuing CAs (including Intermediate CAs) are not expired or invalid.