Care, Share and Grow! : Client Certificate

Required permissions when calling a Web service using client certificate for authentication in an ASP.NET Web application

Saurabh Singh — Fri, 03 Jul 2009 04:08:04 GMT

A Web service requiring Client certificate authentication is a common scenario.

You may have a client application which needs to send the Client certificate as part of the web request for accessing the web service.

This client application may be a Windows/Console application or another Web application.

Often you will get into issues wherein you are able to send Client certificate as part of the web request from a windows/console app but not from another web app. The primary reason for this could often be around Web app not being able to send the client cert to the target Web service.

This can happen for multiple reasons, in particular account under which Web app is running doesn't have enough permissions to access the Client cert in its local certificate store.

Refer to this excellent kb for this for more details.

In this post I want to highlight ways in which you can grant access to the Web application account to access the Client certificate in its local machine store.

When we have to send client cert as part of the web service call from a web app we need to ensure that the client cert is installed in the Local Computer -> Personal Store on the local box (where Web app is running). By default you will see the client cert installed in the Local User Store for the user who requested and installed the cert on the machine. You need to ensure first that the client cert is installed on the Local Computer Store instead of the Local User Store and then follow any of the methods below to grant access to the private key for the account (under which your web app is running).

Method 1:

The above article kb gives an example of granting access using the Microsoft Windows HTTP Services Certificate Configuration Tool

> WinHttpCertCfg.exe -g -c LOCAL_MACHINE\MY -s " IssuedToName " -a " AccountName "

for e.g.

> WinHttpCertCfg.exe -g -c LOCAL_MACHINE\MY -s " IssuedToName " -a "Network Service"

There are other ways in which you can achieve the same result. This feature is in fact built in on Windows Server 2008 within the Certificate mmc console.

Method 2:

Using the WSE X509 Certificate tool (This tool has features that can be used to check certificate properties).

You need to download Web Services enhancements (WSE) 2.0+ SP3 for Microsoft.Net and in the install wizard ensure you select Tools as shown below:

Once installed go ahead and launch the tool. It has a clean UI. You have the option to check certificates in the Local Computer/Current user for the available stores like Personal/Trusted/Intermediate Root CA etc. If you click on View Private Key File Properties (shown below) you can directly modify the permission for private key associated with the certificate. Basically this is just a file under C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys on Win2k3 server and C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys on Win2k8 server.

You may want to go ahead and give the Service account under which the web app is running Full permission on this file (modify the permissions from the Security tab).

Method 3:

If you are running the web app on Windows Server 2008/Vista there is a far simpler way built in the Certificate mmc.

Right click on the certificate and go to All Tasks -> Manage Private Keys and then give Full permission for the associated account.

Till next time..

Cheers!

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!

Automate client certificate one-to-one mapping in IIS 6.0 using C#

Saurabh Singh — Sat, 11 Apr 2009 03:04:00 GMT

In PSS, we occasionally get requests from our customers wherein they want to automatically add entries for client certificate mapping in IIS or Active Directory (AD). That is either a 1-to-1, Many-to-1 or AD mapping for the client certificate authentication for the web site. I recommend going with AD mapping because that eases the management but it finally depends upon one's need.

I am not sure but I feel there is a security breach plus annoyance when an administrator has to laboriously enter the mappings for all the accounts/certificates (I am being specific to 1-to-1/Many-to-1 here).

The concern I feel when dealing with the administrator doing it for 1-to-1 and Many-to-1 are:

a. If there are hundreds of users you need to do this manually for everyone of those accounts and it's a pain.

b. Yes, the above can be automated using a script but then the second concern that arises is that whoever is running the script has to know the passwords for all these accounts to be mapped. I think this doesn't sound good.

I have written a sample application using which users can enter the mappings themselves in the IIS's Client certificate setting, i.e. entries having the client certificate mapped to a windows account (either a local IIS or AD account) and the corresponding password.

So this is how it works:

User accesses this web page from their workstation which already has the client certificate installed.
They are authenticated over Basic with SSL.
Browser sends across the client certificate as part of the HTTP web request.
This application gathers the user account, password plus the client certificate from the incoming HTTP web request and does the mapping in IIS.

I am adding the code here in case someone may want to extract the section for automated scripting instead of using it as a web app.

This code is also attached to this post as well.

using System;using System.Data;using System.Configuration;using System.Web;using System.Web.Security;using System.Security.Cryptography.X509Certificates;using System.Web.UI;using System.Web.UI.WebControls;using System.Web.UI.WebControls.WebParts;using System.Web.UI.HtmlControls;using System.DirectoryServices; /* This sample application is to automate One-to-One Client certificate mapping in IIS 6.0. * User should be able to access this site from the browser and select the client certificate * in their machine which will be mapped to their account on the IIS server for 1-to-1 mapping.  * You need to deploy this application on the IIS server which is hosting the website(s) which  * needs client certificate mapping, preferably under its own virtual directory. * * Important: * - Have the authentication for this web application configured to use Basic along with SSL. * - Have the "Accept client certificates" or "Require client certificates" selected under  *   <Website> -> Properties -> Directory Security -> Secure communications -> Edit -> Client certificates * - Ensure the website that we want the mapping for is mentioned in the web.config file associated with *   this application under <appSettings> * - In the Web.config file we are impersonating an Administrator account for this application.  *   <identity impersonate="true" userName="Administrator" password="myadminpassword"/> *   This is done because non-admin users cannot modify the IIS metabase. If you do not want users to map *   entries themselves through web page you can change this to <identity impersonate="true" />. *   In such a case only admins can add the mappings for their user accounts. Non-admins won't be able to  *   add the client mapping entries. *   This is valid for both domain or local Windows NT accounts. * - This app is written using .Net 2.0, ASP.Net 2.0 and above in mind. You should be able to make it work *   with ASP.Net 1.1 as well. * - You may prefer to run this application under its own dedicated application pool to ensure stability and security. *  * DISCLAIMER: The code is not tested for production scenarios so use it at your own risk.  *             In case one wants to use batch scripting etc or some kind of console app instead  *             of web app you can extract the code section from this page which should work fine for the job. */ public partial class _Default : System.Web.UI.Page {    protected void Page_Load(object sender, EventArgs e)      {        Response.Write("<B>Client Certificate One-to-One Mapping Application:</B><BR><HR>");        Response.Write("Serial number: " + Request.ClientCertificate.SerialNumber + "</BR><HR>");        Response.Write("Issuer: " + Request.ClientCertificate.Issuer + "</BR><HR>");        Response.Write("Subject Name: " + Request.ClientCertificate.Subject + "</BR><HR>");        if (Request.ClientCertificate.IsPresent)        {            Response.Write("Validity<BR>");            Response.Write("&nbsp;&nbsp;&nbsp;&nbsp;Not before: " + Request.ClientCertificate.ValidFrom + "</BR>");            Response.Write("&nbsp;&nbsp;&nbsp;&nbsp;Not after: " + Request.ClientCertificate.ValidUntil + "</BR><HR>");        }        else            Response.Write("<B>There is no client certificate sent along with the request!</B><HR>");         Response.Write("Authenticated User: " + Request.ServerVariables["AUTH_USER"] + "</BR><HR>");        Response.Write("Authentication Type: " + Request.ServerVariables["AUTH_TYPE"] + "</BR><HR>");    }    protected void Button1_Click(object sender, EventArgs e)    {        string user = Request.ServerVariables["AUTH_USER"];        string password = Request.ServerVariables["AUTH_PASSWORD"];        string clientCertMappingName = "Mapping for " + user;  // <--- Our One-to-One Mapping name for the entry        HttpClientCertificate cert = Request.ClientCertificate;        /*          If you want to map a client certificate located on the disk instead of the one as part of the           HTTP Web request try the code below.                    X509Certificate certificate = X509Certificate2.CreateFromCertFile(@"c:\cert.cer");          X509Certificate certificate = cert.Certificate;          byte[] certHash = certificate.GetRawCertData();        */        byte[] certHash = Request.ClientCertificate.Certificate;        try        {        //Get the name of the Web site for which mapping has to be done from the App settings in the web.config file.        string friendlyWebsiteName = ConfigurationManager.AppSettings["websitename"].ToString();         //Get the Site Identifier based on the friendly name of the Web Site.        string siteId = getsiteid(friendlyWebsiteName);         if (siteId != null)            {            string sitePath = "IIS://localhost/W3SVC/" + siteId + "/IIsCertMapper";            using (DirectoryEntry de = new DirectoryEntry(sitePath))            {                de.Invoke("CreateMapping", new object[] { certHash, user, password, clientCertMappingName, true });            }            Response.Write("Account Mapped: <B>" + Request.ServerVariables["AUTH_USER"] + "</B></BR>");            Response.Write("Mapping Name: <B>" + "Mapping for " + Request.ServerVariables["AUTH_USER"] + "</B></BR>");            Response.Write("Web Site: <B>" + friendlyWebsiteName + "</B></BR>");            }        else            {            Response.Write("<B>Web Site does not have a valid Site ID. Ensure we have the correct site name in the config file for this app.</B>");            }        }                catch (System.Runtime.InteropServices.COMException)        {            Response.Write("A COM exception occurred while setting up the mapping.");        }        catch (SystemException)        {            Response.Write("An error occurred while setting up the mapping.");        }        catch (Exception)        {            Response.Write("An error occurred while setting up the mapping.");        }           }     public string getsiteid(string websitename)    {        DirectoryEntry root = new DirectoryEntry("IIS://localhost/W3SVC");        try        {            string siteid = null;            foreach (DirectoryEntry de in root.Children)            {                if (de.SchemaClassName == "IIsWebServer")                {                    if (websitename.ToUpper() == de.Properties["ServerComment"].Value.ToString().ToUpper())                        siteid = de.Name;                }            }            if (siteid == null) return null;            return siteid;        }        catch        {            return null;        }        finally        {            root.Close();        }    }}

Ciao

Nice weekend!

Unable to access IIsCertMapper object through ADSI

Saurabh Singh — Thu, 03 Apr 2008 02:10:54 GMT

Today, I was working on an issue where we were trying to add mapping for client certificate for a windows account using ADSI and VBScript. Something similar as below:

<%
Dim CertObj, vCert
vCert = Request.ClientCertificate("CERTIFICATE")
Set CertObj = GetObject("IIS://<path>/IIsCertMapper")
CertObj.CreateMapping vCert, "MYACCT", "MYPASS", "My Name", True
%>

where path is in the format: "<IISServerName>/W3SVC/<Identifier>"
However, script was failing on the 3rd line,

Set CertObj = GetObject("IIS://<path>/IIsCertMapper")

We get “Path not found error”, 80070003. Now this is an expected behavior if this object type is not found in the IIS's metabase. You can search for the above in metabase.xml file. Ideally this should have been there, but since we did not have this, to make it work we had to manually create this for a website in question.

You can try this to have the necessary object type:

> cscript adsutil.vbs CREATE w3svc/1/IIsCertMapper "IIsCertMapper"
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.
created "w3svc/1/IIsCertMapper"
>

Here 1 is the identifier for the website in question and "IIsCertMapper" is the Object type.

Once done, try restarting IIS services as like (IISRESET from the cmd prompt).

Open the metabase.xml and now we should see an entry as below:

Once this entry was created in the metabase.xml we should be able to access this object via ADSI script. This is not only applicable to a specific object type like IIsCertMapper but any other object type associated with IIS.

Hope this helps someone, somewhere, somehow ;-)

Certificate Trust List not being honored by IIS 5.0/6.0/7.0?

Saurabh Singh — Sat, 08 Dec 2007 00:36:13 GMT

Something one should be aware of if one is dealing with Client certificate and assuming Certificate Trust List (CTL) will limit the list of Trusted Certificate Authorities (CA's) being sent to the client during the initial SSL handshake.

In IIS 5.0 Post MS04-011 update and IIS 6.0/7.0 using CTL's you cannot limit the list of CA's sent back to the client during the SSL/TLS handshake. i.e. you can't use CTL's to limit the list of certificates that Internet Explorer is showing. IE will show all the certificates irrespective of whether the issuing CA is a part of the CTL or not.

This however is not applicable to Apache web server. Apache will send the list of CA's which are part of the CTL. The above behavior was implemented in IIS as a security design feature. You can use OpenSSL to check the behavior:

Let's assume we have a web site www.test.com which accepts client certificates. OpenSSL will show the following transaction. Note that it sends the list of all the CA's even if you have configured CTL to allow specific CA's.

C:\>OpenSSL s_client -connect www.test.com:443 -prexit
Loading 'screen' into random state - done
CONNECTED(00000790)
depth=0 /C=CA/ST=Karnataka/L=Bangalore/O=abc/OU=IIS/CN=www.test.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=CA/ST=Karnataka/L=Bangalore/O=abc/OU=IIS/CN=www.test.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=CA/ST=Karnataka/L=Bangalore/O=abc/OU=IIS/CN=www.test.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=CA/ST=Karnataka/L=Bangalore/O=abc/OU=IIS/CN=www.test.com
   i:/DC=com/DC=Saurabh1/CN=Microsoft
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIE3DCCA8SgAwIBAgIKEfew+wAAAAAANTANBgkqhkiG9w0BAQUFADBDMRMwEQYK
CZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIU2F1cmFiaDExEjAQBgNV
BAMTCU1pY3Jvc29mdDAeFw0wNzExMTYyMzE1MjFaFw0wOTExMTUyMzE1MjFaMGgx
CzAJBgNVBAYTAkNBMRIwEAYDVQQIEwlLYXJuYXRha2ExEjAQBgNVBAcTCUJhbmdh
bG9yZTEMMAoGA1UEChMDYWJjMQwwCgYDVQQLEwNJSVMxFTATBgNVBAMTDHd3dy50
ZXN0LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyHwhBcSOgyfAe2WJ
2m391qWNTEKj9ScSKrbrzxEFWqEKIReH5pkabxG188vX1uQoo5MUCGd3WIEAb3Xa
T+mY7P/nA3fwMEUjF1apwXPwQf8hpx5GXhPM6YjyizFGxq06qgNTG3+gCh8arwhu
u8f9zKOEUicGDOJaQHIK1ofp4G8CAwEAAaOCAi8wggIrMAsGA1UdDwQEAwIFoDBE
BgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAw
BwYFKw4DAgcwCgYIKoZIhvcNAwcwEwYDVR0lBAwwCgYIKwYBBQUHAwEwHQYDVR0O
BBYEFBi8sz9sklijc8tObd/kfYp13IQXMB8GA1UdIwQYMBaAFAVRxGOV1iHL6wJC
f2vFzSTt5QFwMEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9sYXhtaW5iLnNhdXJh
YmgxLmNvbS9DZXJ0RW5yb2xsL01pY3Jvc29mdC5jcmwwggEVBggrBgEFBQcBAQSC
AQcwggEDMIGpBggrBgEFBQcwAoaBnGxkYXA6Ly8vQ049TWljcm9zb2Z0LENOPUFJ
QSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25m
aWd1cmF0aW9uLERDPVNhdXJhYmgxLERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/
b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBVBggrBgEFBQcwAoZJ
aHR0cDovL2xheG1pbmIuc2F1cmFiaDEuY29tL0NlcnRFbnJvbGwvTEFYTUlOQi5T
YXVyYWJoMS5jb21fTWljcm9zb2Z0LmNydDAhBgkrBgEEAYI3FAIEFB4SAFcAZQBi
AFMAZQByAHYAZQByMA0GCSqGSIb3DQEBBQUAA4IBAQAPf48JnKDC5qnGUOwzPsVY
iz454kHCa6hWxO4L8Lf4uZ/iTwhjvG+LsPZpsijxAkpa/Me2YAtTJS8HaKa0l+on
VAsDl4AJLK0epH7iQUfahe5BH3DxYcXFi2uAZeSFa12STxa5Ywtknrlxelimzak+
CgEZTSUDTtSDAOxwIpIXlmsPzBmaI7Cx6+R0Kul3H+DPRP/iE/Qh7yzlXbDqcAsA
i91ungRcHtiFxkLSwfRbV/qyr2OszKa+7SM9GJ6R0lJC5oRBy/JkQqWiAYvRaf5J
iTdC7eourVL+TH+GhXnFpmCs+YlotkWLj7EsLKwKiEuX8mm8T6UXKzis2OazfHfh
-----END CERTIFICATE-----
subject=/C=CA/ST=Karnataka/L=Bangalore/O=abc/OU=IIS/CN=www.test.com
issuer=/DC=com/DC=Saurabh1/CN=Microsoft
---
No client certificate CA names sent
---
SSL handshake has read 1384 bytes and written 324 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
SSL-Session:
    Protocol : TLSv1
    Cipher    : RC4-MD5
    Session-ID: B21A0000950C415B75F380724109AE354A29437F77C62FCEF493BD823C62C616
    Session-ID-ctx:
    Master-Key: 6A2F53DBE5ED1565D1E7CB218B4D1B7AF7CFE07594469D69772C26232BBB0253326ACC25A106D3A6B452
1B3B0989D57D
    Key-Arg   : None
    Start Time: 1197061986
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---
GET /test.asp
depth=0 /C=CA/ST=Karnataka/L=Bangalore/O=abc/OU=IIS/CN=www.test.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=CA/ST=Karnataka/L=Bangalore/O=abc/OU=IIS/CN=www.test.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=CA/ST=Karnataka/L=Bangalore/O=abc/OU=IIS/CN=www.test.com
verify error:num=21:unable to verify the first certificate
verify return:1
read R BLOCK
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>The page requires a client certificate</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=Windows-1252">
<STYLE type="text/css">
BODY { font: 8pt/12pt verdana }
H1 { font: 13pt/15pt verdana }
H2 { font: 8pt/12pt verdana }
A:link { color: red }
A:visited { color: maroon }
</STYLE>
</HEAD><BODY><TABLE width=500 border=0 cellspacing=10><TR><TD>

<h1>The page requires a client certificate</h1>
The page you are attempting to access requires your browser to have a Secure Sockets Layer (SSL) cli
ent certificate that the Web server will recognize. The client certificate is used for identifying y
ou as a valid user of the resource.
<hr>
<p>Please try the following:</p>
<ul>
<li>Contact the Web site administrator if you believe you should be able to view this directory or p
age without a client certificate, or to obtain a client certificate.</li>
<li>If you already have a client certificate, use your Web browser's security features to ensure tha
t your client certificate is installed properly. (Some Web browsers refer
to client certificates as browser or personal certificates.)</li>
</ul>
<h2>HTTP Error 403.7 - Forbidden: SSL client certificate is required.<br>Internet Information Servic
es (IIS)</h2>
<hr>
<p>Technical Information (for support personnel)</p>
<ul>
<li>Go to <a href="http://go.microsoft.com/fwlink/?linkid=8180">Microsoft Product Support Services</
a> and perform a title search for the words <b>HTTP</b> and <b>403</b>.</li>
<li>Open <b>IIS Help</b>, which is accessible in IIS Manager (inetmgr),
and search for topics titled <b>About Certificates</b>, <b>Using Certificate Trust Lists</b>, <b>En
abling Client Certificates</b>, and <b>About Custom Error Messages</b>.</li>
</ul>

</TD></TR></TABLE></BODY></HTML>

read:errno=0
---
Certificate chain
0 s:/C=CA/ST=Karnataka/L=Bangalore/O=abc/OU=IIS/CN=www.test.com
   i:/DC=com/DC=Saurabh1/CN=Microsoft
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIE3DCCA8SgAwIBAgIKEfew+wAAAAAANTANBgkqhkiG9w0BAQUFADBDMRMwEQYK
CZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIU2F1cmFiaDExEjAQBgNV
BAMTCU1pY3Jvc29mdDAeFw0wNzExMTYyMzE1MjFaFw0wOTExMTUyMzE1MjFaMGgx
CzAJBgNVBAYTAkNBMRIwEAYDVQQIEwlLYXJuYXRha2ExEjAQBgNVBAcTCUJhbmdh
bG9yZTEMMAoGA1UEChMDYWJjMQwwCgYDVQQLEwNJSVMxFTATBgNVBAMTDHd3dy50
ZXN0LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyHwhBcSOgyfAe2WJ
2m391qWNTEKj9ScSKrbrzxEFWqEKIReH5pkabxG188vX1uQoo5MUCGd3WIEAb3Xa
T+mY7P/nA3fwMEUjF1apwXPwQf8hpx5GXhPM6YjyizFGxq06qgNTG3+gCh8arwhu
u8f9zKOEUicGDOJaQHIK1ofp4G8CAwEAAaOCAi8wggIrMAsGA1UdDwQEAwIFoDBE
BgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAw
BwYFKw4DAgcwCgYIKoZIhvcNAwcwEwYDVR0lBAwwCgYIKwYBBQUHAwEwHQYDVR0O
BBYEFBi8sz9sklijc8tObd/kfYp13IQXMB8GA1UdIwQYMBaAFAVRxGOV1iHL6wJC
f2vFzSTt5QFwMEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9sYXhtaW5iLnNhdXJh
YmgxLmNvbS9DZXJ0RW5yb2xsL01pY3Jvc29mdC5jcmwwggEVBggrBgEFBQcBAQSC
AQcwggEDMIGpBggrBgEFBQcwAoaBnGxkYXA6Ly8vQ049TWljcm9zb2Z0LENOPUFJ
QSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25m
aWd1cmF0aW9uLERDPVNhdXJhYmgxLERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/
b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBVBggrBgEFBQcwAoZJ
aHR0cDovL2xheG1pbmIuc2F1cmFiaDEuY29tL0NlcnRFbnJvbGwvTEFYTUlOQi5T
YXVyYWJoMS5jb21fTWljcm9zb2Z0LmNydDAhBgkrBgEEAYI3FAIEFB4SAFcAZQBi
AFMAZQByAHYAZQByMA0GCSqGSIb3DQEBBQUAA4IBAQAPf48JnKDC5qnGUOwzPsVY
iz454kHCa6hWxO4L8Lf4uZ/iTwhjvG+LsPZpsijxAkpa/Me2YAtTJS8HaKa0l+on
VAsDl4AJLK0epH7iQUfahe5BH3DxYcXFi2uAZeSFa12STxa5Ywtknrlxelimzak+
CgEZTSUDTtSDAOxwIpIXlmsPzBmaI7Cx6+R0Kul3H+DPRP/iE/Qh7yzlXbDqcAsA
i91ungRcHtiFxkLSwfRbV/qyr2OszKa+7SM9GJ6R0lJC5oRBy/JkQqWiAYvRaf5J
iTdC7eourVL+TH+GhXnFpmCs+YlotkWLj7EsLKwKiEuX8mm8T6UXKzis2OazfHfh
-----END CERTIFICATE-----
subject=/C=CA/ST=Karnataka/L=Bangalore/O=abc/OU=IIS/CN=www.test.com
issuer=/DC=com/DC=Saurabh1/CN=Microsoft
---
Acceptable client certificate CA names
/DC=com/DC=Saurabh1/CN=Microsoft
/DC=com/DC=Saurabh1/CN=Saurabh CA
/C=US/O=VeriSign, Inc./OU=Class 1 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign,
Inc. - For authorized use only/OU=VeriSign Trust Network
/C=US/O=VeriSign, Inc./OU=Class 4 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign,
Inc. - For authorized use only/OU=VeriSign Trust Network
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification Services Division/CN=Thawte P
ersonal Freemail CA/emailAddress=personal-freemail@thawte.com
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification Services Division/CN=Thawte P
ersonal Premium CA/emailAddress=personal-premium@thawte.com
/C=US/O=First Data Digital Certificates Inc./CN=First Data Digital Certificates Inc. Certification A
uthority
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification Services Division/CN=Thawte P
ersonal Basic CA/emailAddress=personal-basic@thawte.com
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 1 Public Primary Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign,
Inc. - For authorized use only/OU=VeriSign Trust Network
/C=HU/L=Budapest/O=NetLock Halozatbiztonsagi Kft./OU=Tanusitvanykiadok/CN=NetLock Uzleti (Class B) T
anusitvanykiado
/C=US/O=GTE Corporation/CN=GTE CyberTrust Root
/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
/C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Li
mited/CN=Entrust.net Secure Server Certification Authority
/C=HU/ST=Hungary/L=Budapest/O=NetLock Halozatbiztonsagi Kft./OU=Tanusitvanykiadok/CN=NetLock Kozjegy
zoi (Class A) Tanusitvanykiado
/C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign,
Inc. - For authorized use only/OU=VeriSign Trust Network
/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Root
/C=HU/L=Budapest/O=NetLock Halozatbiztonsagi Kft./OU=Tanusitvanykiadok/CN=NetLock Expressz (Class C)
Tanusitvanykiado
/OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority
/DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority
---
SSL handshake has read 7991 bytes and written 740 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
SSL-Session:
    Protocol : TLSv1
    Cipher    : RC4-MD5
    Session-ID: 7F0A00002D0024D14CCB9D959D185669A22B6F9ECF613E75C0B9A7DD75DD436A
    Session-ID-ctx:
    Master-Key: A17E388F8744B03CAA268418A700F92B5BABDBD09908F8E5503B299579CA4C09A93CCEC5BBCB7BD2F39A
2C64EF36F674
    Key-Arg   : None
    Start Time: 1197061993
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---

This is the default behavior for IIS 5.0 (Post MS04-011), IIS 6.0 and to my knowledge will remain so going forward with IIS 7.0 as well.

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.

How to setup IIS and AD for Client certificate authentication

Saurabh Singh — Sat, 14 Apr 2007 14:01:00 GMT

Hi All,

This post talks about how Client certificates are configured on websites. I have seen a lot of incidents where people get into issues with client certificate in particular, although server (website) certificates can give a scare at times.

Here I will be walking you through the steps of configuring client certificates in your Windows 2003 environment (although there is not much of a difference in Windows 2000).

Environment

Windows 2003 (Web server) IIS6.0

Windows 2000/XP/2003 (Client)

Windows 2003 (Microsoft Certificate server)

Walkthrough

1. To enable SSL transaction between the server and the client, you need to have a server certificate installed on IIS website. Websites can get the server certificate from a trusted root Certificate Authority (CA). We will be focusing on the steps for acquiring client certificates and setting them in IIS for user authentication.

2. Here I will show the screenshot of the steps that one needs to follow with brief explanation of the steps.

Client Workstation: WIN2kIIS-VPC

CA server: WIN2K3DC

IIA Web Server: WIN2K3OWA

DC: WIN2K3DC

Domain: Anjenya.local

Requesting a client certificate from a Trusted root Certificate Authority (CA):

Access the CA Website from your client machine as http://Win2k3dc/certsrv

There are two ways of obtaining client certificate.

Click on the link: Request a Certificate.

Click on “Select a certificate type: User certificate”.

You can also obtain the certificate by clicking on “advanced certificate request” to add more specific details about the client certificate.

Click on More Options >>

Go ahead and hit Submit >

Click on “Yes”

Go ahead and click on the link to install the certificate. You might get the certificate directly as above or through email etc when in case of a 3^rd party after verification.

Click on “Yes”

Now the User certificate is successfully installed on your client machine.

You can check the certificate in two ways:

1. Goto IE->Tools->Internet Options->Content->Certificates.

You should see the certificate there under Personal store, which was installed on your client machine.

1. Or else you can open the Certificate snap-in through Start->Run->Mmc->Console->Add/Remove Snap-in->Add… -> Certificates.

Go ahead and add the certificates snap-in.

Double click on the certificate and you should see the details about it:

Enhanced Key usage will show you the purpose of this certificate.

The above picture shows that this certificate is meant for Client Authentication.

So here we finish the process of acquiring the client certificate.

Now the next step is to map the client certificate in IIS manager, depending upon one’s requirements. It can be one of the following:

Option to accept the client certificate from the user by the IIS website (with no mapping enabled).
Option to have 1-to-1 mapping for client certificate.
Option to have Many-to-one mapping for client certificate.
Option to have Active Directory Mapping for client certificate.

1-to-1 and Many-to-1 mapping are simple to setup.

Here I will walk you through the process of setting up the above configuration for 1-to-1 mapping and Active directory mapping.

Let’s say that you have a website in IIS for which you want to enable client certificate.

You need to go to IIS Manager->Default Website-> right click and go to Properties->Directory Security->Under Secure Communications section, click on Edit.

Here in the picture above, you have three options for Client Certificates:

Ignore client certificates: IIS will ignore client certificate when a request reaches IIS website, even though web request has the certificate in it.
Accept Client certificates: IIS website will accept any client certificate from the user, if it is along with the web request.
Require Client certificates: IIS website will check for client certificate along with web request. If no client certificate is in the web request, users shall see 403.7 – Client certificate required, as the error message in the web page response.

Now in the next section in the same picture above, if you want your website to be configured such that a client certificate is mapped to a user account, you can check on “Enable client certificate mapping”. What it means is that request will be executed in the context of an account.

Now, when you enable 1-to -1 Mapping, an individual client certificate will be mapped to a specific Windows account. So in case you don’t want any of the IIS authentication methods to be used, like Anonymous, Basic, Digest or Windows Integrated authentication, you can rely upon client certificate authentication based on 1-to -1 or Many-to-1 mappings.

We will first go ahead with 1-to-1 mapping:

Click on “Add…” in the Account Mappings window shown above.

Now before you map a client certificate with a windows account, you need to have the corresponding client certificate on the server.

Export the client certificate from the CA or the client machine (where you have the certificate installed) as follows:

1) From Client machine: Open Certificate snap-in as earlier and go to Certificates – Current User -> Personal -> Certificates.

Double click on the selected certificate and Click on Details and go to “Copy to File…”.

Follow the Export wizard.

You can either Export the private key or not export it. You should know the meaning of exporting the private key.

Go ahead and save the client certificate somewhere on your workstation (client).

2) From CA:

Go to the Certificate Authority Snap-in and check the following location:

Double click to display the certificate. Click on “Copy to File...” and follow the Certificate Export Wizard, and save the file to the server as shown below:

Now copy the saved certificate from any of the above location to the IIS server, where we need to map it a windows account.

Back to IIS manager console for certificate mapping:

Now map a specific windows account with this certificate as shown below:

Once the 1 to 1 mapping is set in place go ahead and try browsing the site.

Here I have used an ASP script to render the server variables pertaining to the web request.

This script will display the logged on user name and the authentication type used along with some other information.

Also when you want to use Client certificate authentication you can clear all other authentication options in the IIS manager Directory Security setting as show below:

Here you won’t get 401.2 server configuration error because we are using some sort of authentication mechanism (client certificate mapping) to authenticate the user. Had we been not using client certificate mapping we would have got 401.2 if we try to access the site with no authentication method selected in IIS manager.

Had there not been Client cert mapping and we had tried to browse to the web page with all the options cleared as shown above, you would have got error 401.2.

Here is the sample logoninfo.asp page which displays server variables. Try accessing this page.

response.write ("LOGON_USER: ")

response.write (request.servervariables("LOGON_USER"))

response.write ("<BR>")

response.write ("AUTH_USER: ")

response.write (request.servervariables("AUTH_USER"))

response.write ("<BR>")

response.write ("AUTH_TYPE: ")

response.write (request.servervariables("AUTH_TYPE"))

response.write ("<BR>")

response.write ("CERT_COOKIE: ")

response.write (request.servervariables("CERT_COOKIE"))

response.write ("<BR>")

response.write ("CERT_ISSUER: ")

response.write (request.servervariables("CERT_ISSUER"))

response.write ("<BR>")

response.write ("CERT_KEYSIZE: ")

response.write (request.servervariables("CERT_KEYSIZE"))

response.write ("<BR>")

response.write ("CERT_SERIALNUMBER: ")

response.write (request.servervariables("CERT_SERIALNUMBER"))

response.write ("<BR>")

response.write ("CERT_SERVER_ISSUER: ")

response.write (request.servervariables("CERT_SERVER_ISSUER"))

response.write ("<BR>")

response.write ("CERT_SERVER_SUBJECT: ")

response.write (request.servervariables("CERT_SERVER_SUBJECT"))

response.write ("<BR>")

response.write ("CERT_SUBJECT: ")

response.write (request.servervariables("CERT_SUBJECT"))

Now in our example we try accessing the above script and we get the following response:

In the above step, if you disable Client cert and enable windows integrated authentication only, you should see something similar to the one shown below:

Check the Authentication type.

Similarly you can try Many-to-1 mapping, please read MSDN/KB articles that talk about how to set it up…it’s very similar to 1 to 1 mapping.

I would like to discuss Active Directory Mapping in particular here:

We need to have Client certificate enabled, we can remove 1-to-1 and many-to-1 mapping from IIS Manager since we need to enable AD mapping.

In AD mapping we need to follow the following steps:

Go to the IIS Manager, right click on root level WEBSITES->Properties->Directory Security.

Select “Enable the windows directory service mapper”.

Now go to Active directory, open Active directory users and computers, go to Users, and then select the user for which you want to map the certificate.

Right click on the user name, go to Name Mappings. Add the client certificate. Now we have a mapping for that certificate to a user account in the AD.

Go to the client machine and logon with the user credentials , and then try accessing the site now, and now you should be able to access the page and you should see the Logon name in the webpage, here the logon name will correspond to the same user with which we have associated the client certificate in the AD.

Now you should see something like this:

Remember this:

Here is an excerpt from a TechNet article:

In Active Directory mapping, when the IIS server receives a certificate from the user, it passes it on to Active Directory, which maps it to a Windows 2000/2003 user account. The IIS server then logs this account on.

Active directory mapping is most useful when the account mappings are the same on all IIS servers. Administration is simplified because the mapping is done in only one place.

Mapping in Active Directory can happen in one of two ways. The administrator can explicitly map a certificate to a user's account. This certificate can come from any source--as long as the root CA for that certificate is trusted for client authentication.

UPN mapping can also be used. A UPN is automatically put into a certificate issued by an enterprise CA. If a certificate is passed to Active Directory for mapping, it is first examined for UPN mapping. If UPN mapping is not possible, the mapping set by the administrator is used.

UPNs are in the form of userid@domain. If the certificate contains a UPN, the domain is within the hierarchy of the directory, and the CA that issued the certificate is trusted to put UPNs in the certificate, then the user's account is retrieved from the directory and logged on. All these conditions must be true before the user's account is retrieved. If any of these conditions is false, the directory is searched for a mapping set by the administrator.

In Active Directory mapping, when the IIS server receives a certificate from the user, it passes it on to Active Directory, which maps it to a Windows 2000 or Windows Server 2003 user account. The IIS server then logs on the account.

You can create an Active Directory mapping in one of two ways. You can rely on UPN mapping, or, if UPN mapping is not possible, you can manually map a certificate to the account of a user.

Use Active Directory mapping when the account mappings are identical on all IIS servers. Active Directory mapping is easier to maintain than IIS mapping because you only have to create the mapping in one location.

NOTE: Let’s assume that the user account with which we are trying to access the site doesn’t have a UPN name in the AD (this might happen in the case where the logged on user is a local user and not a Domain user) then in that case the logon credentials for the request will be the mapped user account for the certificate in the AD. Else, if the client certificate’s “Issued to” is a domain user account, then logon credentials will use that Account and not the mapped account associated with certificate. Also it will not respect user’s logged on credentials or server authentication method in IIS manager.