Digital Certificate Support Introduction

You have the choice of three authentication methods when implementing IPSec. The previous method discussed preshared keys, which are great for a small environment. However, preshared keys are not a scalable solution. Imagine having to change the preshared key on 500 virtual private network (VPN) software clients and 50 site-to-site tunnels on a frequent schedule. I think you get the picture that as the size of the IPSec implementation increases , the desirability of preshared keys decreases.

The scalable alternative to preshared keys is to use digital certificates for authentication. To use digital certificates, you need to perform a few more configurations than you would for preshared keys; however, the configurations are not difficult. You also need a CA server, either internally or externally, to get a digital certificate.

You must make a number of configuration entries on the router for it to support authentication with digital certificates. Although this step is not necessarily the first step in configuring digital-certificate support on the router, we created an IKE Phase 1 policy earlier. So let's change that policy to support certificate use.

Digital certificates take up space in a router's memory. You must be aware of the router's current memory utilization and the memory impact that digital certificates have on the router's memory.

A CA is a trusted third party that is responsible for issuing, managing, and revoking digital certificates. An RA is simply a server that acts as a proxy for the CA. This process ensures that CA functions can continue even when the CA is offline.

A router will have a root certificate and an identity certificate stored in its memory. If the CA uses an RA, an RA certificate is also stored in memory.

A router also stores CRLs if you configure the router to support CRLs. A CRL is a list of all certificates that have been revoked by the CA. The CRL lists certificates by certificate serial number. The number of CRLs that a router needs to store in memory depends on whether the CA uses an RA.

A router stores one CRL in its memory if the CA does not use an RA. If the CA uses an RA, it must store multiple CRLs in memory.

IKE Phase 1 Policy

Because authentication happens during IKE Phase 1, you need to change the IKE policy created earlier, or you need to create a new IKE policy. For simplicity, we change the IKE policy 100 that was created earlier. Figure 9.3 shows the command to change the IKE security policy from preshared keys to RSA signatures.

Figure 9.3. IKE Authentication using digital certificates.

That is all you need to do to reconfigure IKE policy 100 .

Digital Certificate Validity Period

Digital certificates are valid from a specific time and date and expire on a specific time and date. For this reason, you must configure the router's clock and time zone to reflect the correct time and date. If you do not, it is possible that the router might reject a digital certificate. The router might believe the certificate is invalid because of an erroneous time and date setting on the router. The command syntax to configure the correct time and date is

 Router# clock set  hh:mm:ss month day year  

To configure the time as 2:35 p.m. and 30 sec for the date 2/29/2004, the command would be

 Router# clock set 14:35:30 february 29 2004 

The command syntax to configure the correct time zone is

 Router(config)# clock timezone zone hours-offset  [minutes-offset]  

To configure the time zone as Pacific Standard Time, the command would be

 Router(config)# clock timezone PST -7 

Making this setting is a critical step in support digital certificates; don't forget it. However, if your router does not have a clock chip, you can use the Network Time Protocol (NTP) to synchronize the router's clock with an NTP server.