Dreez's
PKI Single Sign-On Project

Create Client Certificate

Revision Control

Date

Modifications
2/1/2001 Initial
   
   
   

Contact Dreez: mje@secev.com

Overview

The end-game with certificate based authentication is to have all entities have certificates signed by a common trusted Certificate Authority (CA). This CA is known as the CA Root. In our scenario, there are two types of certificates that the CA Root will verify and sign:

  1. Certificates issued to VPN clients
  2. Certificate issued to the firewall

When the client contacts the firewall to use the VPN, the client and firewall exchange certificates and verify that they both came from a common CA Root.

This part of the process creates a certificate that can be loaded onto the client.  For the time being the certificate will remain a software certificate stored onto the hard drive because I haven't figure out how to load the certificate onto a smart card in a user friendly manner. Besides software certificates are easier to use and I want my user community to be comfortable with their use before I burden them with more security features such as a smart card.

In order to create a certificate, the client must request a certificate from a Certificate Authority (CA) associated with Active Directory. This process is performed through the web enabled interface of the CA.

The Microsoft CA can be configured to run in one of two modes:

  1. Enterprise Mode - In this mode the CA is is integrated with Active Directory. The CA retrieves all the authentication information and user information from Active Directory. In this mode, the user does not even have to authenticate to Active Directory because this mode uses the users login credentials to authenticate the user. Because of the integration with Active Directory, this mode is the most transparent and easiest to use for end users.
  2. Standalone Mode - In this mode the CA is not integrated with Active Directory. In this mode the end user has to provide all the input (user name, credentials, email address, address, etc) to the CA. Because users have to provide more information, this mode is more complex for users to use.

My goal is to make PKI as invisible to users as possible. So I have opted to use the Enterprise Mode for my project. In this mode many of the details are automatically provide to the end user.

For more information on Microsoft's CA click here.

This section describes the process by which end-users creates a certificate interacting with the Enterprise CA.

Process

The process of loading the certificate onto the client starts by having the client computer connect to the Certificate Authority (CA) web server associated with Active Directory.  The client has to be the person that is the end user using the VPN system. This client has to be logged into the network using Microsoft login protocols (Kerberos or NTLM) so that Active Directory recognizes the client as an authenticated user.

The figure below shows how a client connects to a CA. The format is:

http://<CAcomputername>/certsrv

The CA computer is typically a domain controller running Active Directory.

 

This next screen is the most important part. A user can request any type of Certificate Template. Microsoft does not care about the Certificate Template. For this project I just used the base CSP - for me crypto is crypto.

The Key Usage is very important. Make sure you use "both". If you use one of the others, you will only be able to encrypt or sign but not both. Don't ask me why but "Exchange" means "Encrypt".

Key size is not a big deal, 1024 is plenty.

Exporting the key is very important. This gives us to capability to export the key into Checkpoints VPN.

These are all the options you should need. Click on submit and continue.

After submitting your request your local machine generates private and public keys. Your local machine then submits the public key to the Root CA for signing. The Root CA automatically signs the key (only if the CA is in Enterprise mode, in Standalone mode a CA person has to authorize the request and notify you when the certificate is signed). 

The result is the following screen. This screen asks you to install the certificate into your local certificate store.

 

 

Now, sometimes you'll see this warning pop up. The browser is asking you if you want to also install the Root CA along with your user certificate. The answer is YES. Be careful, the default is NO. Only answer YES YES YES.

 

 

Debugging

  1. The only problem you should see is trying to connect to the web server. You have to make sure you have logged onto the network with a network logon. If the client hasn't properly authenticated to Active Directory, you will get authentication prompts before it lets you use the web service.

Home | Services | Training | Support | Contact Us | Search

Copyright 2006, Security Evolution, Inc.