Install Client Certificate

Dreez's
Microsoft's PKI Single Sign-On Project

Install Certificate on VPN Client

Revision Control

Date	Modifications
2/1/2001	Initial Description,
3/3/2001	VPN Project, AD Modifications

Contact Dreez: mje@secev.com

Overview

This section describes how to install an existing certificate onto VPN client machine. Note that at this point the client should have created a certificate and loaded it into the clients local certificate store. See this on creating a certificate. The next step involves copying the the certificate, public keys, and private keys into the VPN environment. The target machine could be the same machine the certificate was generated on (desktop at work) OR it could be a machine at a different location or a laptop or a smartcard.

Process

The first step in the process is to copy the certificate, public key, private key from the local computer onto the target computer. We do this through the export capability in IE5.5. The following diagram shows how you specify Tools, Content, Certificates. Then you choose the certificate that you just generated and click Export.

Next>>>>>>

Yes I want to export the private key along with the certificate. The private key will be used go initiate VPN key exchanges and sign data traffic.

The format is something called PKCS #12. This is an encrypted file format that stores keys and certificates. It has to be encrypted because it contains your private keys.

We also want to export all Root CAs that have signed you certificates. This is actually a critical piece of the puzzle, because remember that both the client and the VPN server certificates have to be signed by a common root. So this is where we load the common root onto the VPN system.

This is how the .pfx file is encrypted. By passwords.

Specify a filename to store the keys under.

The next step is the where we load the private keys into the VPN client software. Bring up the Checkpoint's Secure Client/Remote VPN software.

Certificates->Import->Browse

Choose the same export file that you saved above.

Enter the passwords to decrypt the file. These are the same passwords that you locked/encrypted the file with when you exported from IE.

This action will import the file and save it out to disk in ".epf" format which Checkpoint is capable of reading.

Next step is to go through the process of creating a new Checkpoint site. Bring up Secure Remote/Client and click on the site creation button. Input the site IP address and hit OK.

And when its time to authenticate to the site you will be prompted for authentication information. We input the certificate that we imported in the previous step. Enter the certificate name and before you hit OK, we will "View" the certificate.

Review the user's certificate. Make sure the DN name is equal to the DN name you assign the user in the user record on the firewall or the LDAP server. See Active Directory Naming and Configure User.

Make sure the time is in sync with the CRL machine, the CA machine the firewall and the local laptop. Times are critical. If there are timing errors weird problems start occuring.

Finally make sure the common Root CA is the one that issued and signed this certificate. This Root CA must be the same Root CA that we loaded onto the firewall and signed the firewalls certificate.

If all the parameters check out, then return to the previous windows and hit <enter>.

In the background, authentication and key exchanges are taking place. It takes a while depending on line speeds for all the negotiation to complete so be patient. Once you see the following window, you know that your machine has authenticated the remote firewall/VPN server.

This window is a red herring because it is warning you against a man-in-the middle attack that use to be present when authentication only included username password. The man-in-the-middle attack is where a middle-man interposes themselves between you and your VPN server and spoofs the VPN server. This window is telling you to check the keying information to make sure you are talking to the VPN server and not some interposed middle-man. This warning in no longer valid when using PKI because the Root CA signed the client certificate and the VPN server certificate, so only Root CA signed certificates are allowed to talk to each other. If the middle-man found a way to get their certificate signed by a Root CA, there might be a man in the middle attack once again.

The first time a user is authenticated and a policy is downloaded onto the laptop, this banner comes up notify the user that his client has a new policy loaded.

At this point, you are ready to go.

Debugging

Most of the problems related to PKI and VPN integration had to do with time synchronization problems. It is very important that the times on all systems are synchronized with what the X.509 certificates say.