IIS and client certificates

Introduction

Hello. My name is David Dietz and I have been supporting Microsoft Internet Information Services (IIS) for the past six years. Over the course of this time, one topic that has been a challenge for many Web administrators is client certificates. In this article, I will go over some basics of client certificates and try to make some sense of what they are for and what they can do.

Some of the misconceptions that we see on a regular basis are:

• Client certificates are needed to make SSL work properly.
• When using client certificates, you don't need a certificate on the server.
• A client certificate that is issued by any certification authority will work with any server.
• If you issue a client certificate, your Web server will automatically accept it.

The first and perhaps most confusing point is the difference between client certificates and Secure Sockets Layer (SSL) server certificates. Although client certificates and SSL server certificates both use certificates, they are not directly related to each other. SSL server certificates provide encryption and security functionality. Client certificates provide user authentication functionality. If this makes sense, the rest should be easy.

Client certificates are issued to a user by a certification authority. They consist of the public key portion of the certificate and a private key that is held only by the entity to which the certificate is issued. The certification authority may be a well-known public organization that provides certificate services as part of its business, or it could be an internal server that only your company uses. In either case, the client certificate will have certain information that identifies the user either individually or as part of a group.

In IIS, you have the option of ignoring, accepting, or requiring client certificates when a user accesses resources on your server. Ignoring certificates simply means that you are not using them, will not ask the client for one, and will discard one if it is sent to your server. If you choose to accept certificates, your server will prompt for a certificate but will not necessarily deny access if a certificate is not provided. If you require client certificates, the user must supply a valid certificate or the user will receive an error message.

For a certificate to work properly, certain requirements must be met on both the server and the client. Each side has a list of root certification authorities that they trust. When the server prompts for a certificate, the request includes a list of the certification authorities that the server trusts. The client then compares this list to the list of certification authorities that the client trusts and creates a list of the ones that match. Then, the client compares that list to the client certificates it has and determines which, if any, certificates have been issued by certification authorities that both the client and the server trust. Depending on the client, you may see a list of certificates to choose from if there is more than one certification authority that both sides trust. The client then sends the public portion of the certificate to the server. At this point, the server generally checks to make sure that the certificate is valid and, if no mapping is performed, the communications between the client and the server can continue.

This is the most basic functionality of client certificates. At this point, the server knows only that the client has a valid certificate.

Here is where things get interesting. The server can be configured to do a mapping of the certificate to a user account. This can be either a one-to-one mapping, where the specific certificate is mapped to a single user account, or a many-to-one mapping, where the server uses certain fields in the certificate information to map any matching certificate to a designated user account. When a mapping is used, the certificate allows the user to be granted or denied access to resources as a particular user. When using client certificates in this manner, you do not have to use any other authentication method.

Common error messages that are related to client certificates

This error message is received if a client does not provide a client certificate when one is required. Either the client refused to send a client certificate or the client did not have a certificate issued by a mutually trusted certification authority. 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. 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. 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.