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).
Windows 2003 (Web server) IIS6.0
Windows 2000/XP/2003 (Client)
Windows 2003 (Microsoft Certificate server)
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
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 3rd party after verification.
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:
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:
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 ("AUTH_USER: ")
response.write ("AUTH_TYPE: ")
response.write ("CERT_COOKIE: ")
response.write ("CERT_ISSUER: ")
response.write ("CERT_KEYSIZE: ")
response.write ("CERT_SERIALNUMBER: ")
response.write ("CERT_SERVER_ISSUER: ")
response.write ("CERT_SERVER_SUBJECT: ")
response.write ("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:
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.
Well, I am back to Client certificate again, guess the reason being a lot of support calls that we getting
Is there a script that will map a user's certificate to their account instead of using the GUI in the AD console?
I will have to dig a little to find out if there is any script. BTW, i had glanced through this article once http://support.microsoft.com/kb/203805/
You may prefer to have alook at it and see if soemthing similar works for you (although this was meant for windows NT and IIS 4.0).
While looking for client certificate mapping, I came across this article & found very useful.
Every step shown in details (With screenshot .. good idea :) ) made the understanding easy.
While searching, I also found related articles for IIS 5 (http://support.microsoft.com/kb/313070) & IIS 6 (http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/d4957ac9-889e-4292-b015-8f3ab83952c6.mspx?mfr=true)
Good job Saurabh...
In 2-way SSL the IIS server sends the client a list of acceptable client certificate CA names (based on the configured CTL). This can be verified using e.g. openssl s_client -connect localhost:443
However when I set up 2-way SSL on my 2003/IIS6 this information is not sent to the client and the browser displays all certificates trusted by the client, which can lead to users selecting the wrong certificates.
This works nicely on e.g. Apache and I think that it has worked previously on IIS.
I tried following your steps above. Have you had any experience with this?
You are right. It works fine on Apache. But this does not work for IIS 6.0. This is by design on IIS 6.0. Adding a certificate in CTL will come into picture only when the selected certificate is being validated. But, initially during the handshake, IIS 6.0 sends the whole list of certificates. And, you can’t use CTL’s to limit the list of the certificates that the IE is showing to the users.
CTL is ignored when it comes to sending the list of trusted CAs to the client in IIS 6.0. It was possible in IIS 5.0 post MS04-011 Security update.
Hope this clarifies.
I also have recently blogged about the topic above regarding frimdot's question. Check this out:
About the following paragraph:
"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."
I would like to think that there is more to it than just this above. What if you trust a CA that is also used by other organizations to issue certs? Lets pretend that someone in one of these other organizations had a certificate issued with a upn on your domain. They then try to connect to your IIS using this client certificate. Is there anything preventing them from being mapped to the user object identified by the UPN?
Am I missing something here? I would like to think that the public keys of the certificates that you issue should be stored in AD. Then when authenticating, the private key from the user certificate is used to digitally sign a message and pass to AD. The AD object (located via the UPN) has the public key to the certificate and can verify the signature, thus securely authenticating the user.
If someone else issued a certificate with a UPN in it, then it wouldn't matter because you are performing a digital signature verification.
Nice info, thanks!
A question though: is it possible to issue a Client Certificate for an expirationdate larger than 1 year? 1 year seems to be some sort of default..?
Regarding your requirement to increase the default expiration date for the issued certificates, here is what you can follow.
First of all have a look at this article http://support.microsoft.com/kb/254632/en-us. Here I assume you are interested in the Microsoft CA.
If you are running windows 2003 Ent Edn, to increase the client certificate expiration date, go to the Certificate Authority snapin -> Certificate Templates
Right click and go to Manage. this will launch a new snapin.
In this snapin, find out the Template Display Name for your certificate type that you are interested in.
For e.g. client certificates will have "User" shown in this snapin. Right click on 'User' and go to its Properties.
Here you will see the option to increase the validity period. By default you will see it as 1 year.
you may not be able to modify the settings (if it is grayed out). Then check for Autoenrollment column in the snapin.
If it shows you as "Not allowed" then you can;t modify it.
In such a case, right click on User and click on Duplicate Template. Now you can modify the default value of the validity Period, and if you want to use this setting in future select, you need to modify the Autoenrollment setting for the group policy.
Looks like you and Lou Prete have the same stuff on your and his blog ... So who copied the other's stuff or you both copied someone else's stuff ...
Hey Amir, man I love your comment :-)
I knew someday this is coming. Well, I guess Lou is the right guy who can answer this. I don't believe in copy-paste ;-). Hope this may at least prompt him to reconsider his post. huhh!!
We were trying out the client certificate mapping and followed your article.
We installed the certificate at client and exported it to DER Encoded binay format.
On the webserver, We have unchecked Anonymous, Integrated and Basic Authentication types on the web service and enabled Require Client certificates.
We created a one-one mapping and mapped the certificate to a windows account.
We have a simple web service which we have enabled for client certificate mapping. It has a webmethod subtract which subtracts two numbers.
On the client side we have a .net program which calls with web service.
We are getting an exception HTT 403:Forbidden.
Please let us know if we are missing anything.
The client code is as follows.
//Service1 is the web service class
Service1 ss = new Service1().
X509Store userStore = new X509Store(StoreName.My, StoreLocation.CurrentUser);
X509CertificateCollection certCollection1 = userStore.Certificates.Find(X509FindType.FindByIssuerName, <CA>, true);
X509Certificate cert = certCollection1;
int subtrac = ss.Subtract(Convert.ToInt32(textBox1.Text), Convert.ToInt32(textBox2.Text));
Thanks in advance
Is it possible for you to try browsing to the same site (may be the web service call or any other sample HTML page lying in the same website/virtual directory) through a browser, let's say IE without any issues? You should be prompted to select a client certificate and then if everything goes well you should get to the page. If this works then we may have to look at the code you pasted above if this is picking up from the right store or not. Also when you get 403, do you see any sub status code like 403.1, 403.7 etc. You can check this in the IIS LOG folder from C:\WINDOWS\system32\LogFiles\W3SVC<ID>. Please let me know the sub status code so that we could get close to where the problem lies.
If the web browser access works fine it could be the code wherein we are looking at the user store instead of the machine store.
This should give you some pointers, http://support.microsoft.com/default.aspx?scid=kb;EN-US;901183
To answer John's comment way up the chain if you are looking for some sort of scripting or app to map client certs apart from the IIS GUI have a look at my post
If you have questions feel free to contact me and I will try my best to help out given the amount of spare time I can gather.