Client Certificate Authentication With Site Server 3.0 Commerce Edition

August 1999

Dave Crocco

Microsoft Corporation

To acquire the full benefits of this document, the reader should have a general understanding of private/public key encryption, digital signatures, SSL, and public key certificates. They should also understand the concepts involved with client authentication and page security in Site Server and IIS.

Overview

It is possible with Site Server to map a client certificate to a set of user authentication credentials. Subsequent to creating the mapping, a user can supply the certificate during the negotiation of a client-authenticated SSL connection and be automatically authenticated with Site Server. The mapping is accomplished by storing a hash of the certificate DN (distinguished name) concatenated with the certificate issuer. Assuming all trusted certificate authorities assure no duplicate DNs can be signed to different public keys (usually a safe assumption), this works properly.

Setting-up Microsoft SiteServer 3.0 Commerce Edition to Work with Client Certificate Authentication

Use of Microsoft Certificate Server

If you plan to use Microsoft Certificate Server for your certificate authority (CA), you must either set it up as a CA that is recognized by a certifying chain who’s root is already installed in IIS, or you must install it as a recognized root CA in IIS. That is the only way that IIS knows to trust certificates from your certificate server.

If you elect to use your certificate server as a stand-alone CA with no other certifying chain, you must perform the following steps to get your CA certificate in IIS:

  1. Login to your Site Server server as administrator. It must be administrator and not another account that has administrative privileges.

  2. Use Internet Explorer 4.0 to access the certsrv site on the server that has Microsoft Certificate Server installed. Traverse the pages to acquire the root CA certificate for the certificate server. This will install the certificate in the systemcertificates\root and systemcertificates\CA keys in the registry for the administrator account. (Commonly referred to as the system certificate store.)

  3. Run the IISCA utility that can be found at \winnt\system32\inetsrv\iisca.exe. This copies the certificates from the administrator account to IIS.

  4. Bounce (stop and restart) the w3svc service. It is really best to reboot the server at this point.

Installing a Server Certificate in IIS

A server certificate must be installed in IIS for an SSL negotiation to occur successfully. This is accomplished using the keyring utility. It can be invoked directly or by traversing the menus in MMC as follows:

  1. Select the Directory Security tab of the Default Website Properties dialog box.

  2. Select the Edit button under the Secure Communications section.

  3. Select the Key Management button. You are now in keyring.

In keyring:

  1. Select the WWW tree node.

  2. Select the Key/Create New Key menu item.

  3. Create a key request using the wizard. If you have Microsoft Certificate Server installed on the same server, it will automatically negotiate with the server to install the key in one step. Otherwise, it will create a non certified key-set and a PKCS10 certificate request that must be submitted to a certificate authority. After receiving your server certificate from the authority, you would need to return to keyring to install it.

There is one more important thing to keep in mind if you are going to use your Microsoft Certificate Server (MCS) to issue a server certificate and your MCS is defined as a root CA. All of the clients who attempt to establish an SSL connection will have to install the CA root certificate into their browser or they will encounter a message stating that a secure channel cannot be guaranteed.

Establishing the Certificate Mapping

There is a sample page called regcert.asp that ships with Site Server 3.0 Commerce Edition. This can be used to create a certificate mapping to a client’s credentials. You must have the virtual server instance mapped to a Site Server authentication instance. The page should be set up with the following security attributes:

The regcert sample page uses AUO to store a certificate hash created using the membership.verifusr.1 object. The certificate information is collected from the certificate object accessible through ASP.

The use of this page is simple, just request it using HTTPS, supply a username, password, and a valid user certificate.

After this, if a site, virtual directory, or page has certificate mapping enabled, the user's credentials will be automatically mapped when a client certificate is supplied via SSL.

Managing Binary Certificates

The Site Server schema has a UserCertificate attribute that can be added to a user object. It is a multi-valued binary attribute. There is no way to view or manipulate binary data in the Site Server MMC snap-in or through AUO. If you wish to store and use binary certificates you must do so using the LDAP protocol. There are many alternatives for this:  ADSI, wldap32 API, and so on. There is a sample ASP application that ships with the Site Server SDK. It requests a certificate from a Microsoft Certificate Server on behalf of an authenticated user then stores the certificate in the user's browser, a binary copy of the certificate in the user's Site Server user object, and optionally as base64 encoded text in the user's Site Server user object. It also creates and stores the certificate hash in the user’s credentials so they can subsequently auto-map. The nice thing about the base64 encoded form is that it can be viewed from the MMC snap-in and manipulated using AUO. An alternative way to accomplish storing a binary certificate in the LDAP store is to write a Certificate Server exit module that uses ADSI or wldap32.

The SDK sample can be found in the samples directory after installation:

Information in this document, including URL and other Internet web site references, is subject to change without notice.  The entire risk of the use or the results of the use of this resource kit remains with the user.  This resource kit is not supported and is provided as is without warranty of any kind, either express or implied.  The example companies, organizations, products, people and events depicted herein are fictitious.  No association with any real company, organization, product, person or event is intended or should be inferred.  Complying with all applicable copyright laws is the responsibility of the user.  Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document.  Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 1999-2000 Microsoft Corporation.  All rights reserved.

Microsoft, Windows and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries/regions.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.