Get Root Certificate

Dreez's
PKI Single Sign-On Project

Load Root CA on Firewall

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:

Certificates issued to VPN clients
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.

In order for the firewall to understand who the CA root is and its associated credentials, we have to load the Root CA onto the firewall.

This section describes the process by which a Root CA certificate is loaded onto the Checkpoint firewall. The certificate is used by the firewall when it checks the client certificate during connection authentication. The firewall needs to make sure the client's certificate was signed by a common Root CA.

Process

The process by which the Root CA is loaded onto the firewall is depicted in the diagram below. From the Checkpoint Management station, the firewall administrator uses a web browser to download the Root CA onto the management station. The administrator then uploads the Root CA onto the firewall using the Checkpoint Management Interface.

First the firewall administrator accesses the CA and requests the CA Root.

The firewall administrator then stores the Root CA onto the local filesystem.

Part of the authentication process during connection negotiations is checking CRL lists to verify if a certificate is valid. The firewall needs to know where the CRL is stored so it can access the CRL. Every certificate is required to specify where the CRL list for this certificate is stored. The diagram below illustrates this attribute for Microsoft certificates. After storing the certificate on the hard drive, double-click on it and check to verify the CRL machine (should be same as domain controller), and that it is accessible by the firewall, both through DNS and IP. From the firewall ping the machine with DNS name and then telnet port 80 to the CRL machine just to verify it is accessible.

In the Checkpoint Management interface, the firewall administrator creates a new (or uses an existing) Certificate Server. A name is given to the Certificate Server and most importantly the CA Type is set to OPSEC PKI. This enables the management station to interact with Microsoft's Active Directory and Certificate Authority.

Under the OPSEC PKI tab you have to specify your CRL options and then load the Root CA into the firewall.

CRLs can be requested from the CA various ways:

OCSP - Online Certificate Status Protocol, a real time CRL query. Not supported in FW1
LDAP - An LDAP query to the Active Directory LDAP server. Have not tested under W2K
HTTP - An HTTP request to the Certificate Authority. Tested and works under W2K

HTTP is the easiest, lowest common denomintor, and most error free way to access CRLs in the Microsoft environment. Inside of the OPSEC PKI menu, you specify a CRL retrieval based on HTTP.

The Get button searches the local hard drive for the Root CA as was saved in the previous steps.

The View button is used to view the certificate as stored on the firewall. Might want to verify you loaded the right certificate by comparing the loaded certificate with the certificate stored on your local hard drive. Verify the CRL points and also make sure the times make sense.

Debugging

CRLs are the crux. Make sure that the CRL machine specified in the CRL list is accessible to the firewall and the firewall has rules that allow the CRL machine to respond back to HTTP CRL queries. Might want to telnet port 80 to the CRL machine. Use a network sniffer to make sure the query is succeeding
CRLs are stored in cache on the firewall, so you might want to start/stop the firewall before you do any CRL tests. I'm not sure where the CRL cache is so I don't know where to delete it and not sure if that interferes with the firewall.
PKI and time synch is extremely important. If the firewall time is not in synch with the CRL times, CRL machines, CA times you will get weird errors throughout the system.
CRLs are a pain. I wish I could just turn them off, they are really not needed in this application of PKI. There is documentation about turning off CRLs in Checkpoint, but that only turns them off during startup.