In some instances, it may be desirable to install multiple local certificates that are used to identify the same host. There are a number of situations, where this might be desirable:



Autonomous management of roadwarrior tunnels from multiple sites.



Autonomous management of site-to-site tunnels from multiple sites.

Multiple local certificates are typically used to de-centralize VPN management in larger networks. For instance, a VPN could be used to create a WAN (Wide Area Network) between three head offices of an multinational company. Each head office must be responsible for its own VPN links that connect its regional branches to its head office, as otherwise there would be a reliance on a single set of administrators in one country / time zone preparing certificates for the entire organization.

Using the above example, each head office VPN gateway could utilize two local IDs (certificates):



Country head office ID – This ID would be used by a head office to identify itself to head offices from other countries, to form VPN tunnels that make up the international WAN.



Head office ID – This ID would be used by a head office to identify itself to other domestic offices, so that it can manage VPN tunnel connectivity within its own region.

The same concept can be applied to any situation where autonomous VPN management is required. To continue the above example, many of the offices within one particular country require a number of roadwarrior users to connect to their local networks. In this instance, a branch office VPN gateway could utilize two local IDs (certificates):



Regional branch office ID – This ID would be used by a branch office to identify itself to the head office and other branch offices that make up the country-wide WAN.



Branch office ID – This ID would be used by a branch office to identify itself to its local roadwarriors, so that it can manage roadwarrior connectivity to its own branch.

This example will demonstrate how to delegate VPN management from an un-configured master Smoothwall to an un-configured secondary Smoothwall. The secondary Smoothwall is responsible for managing site-to-site and roadwarrior connections within its own geography.

Firstly, we must create a tunnel to link the master Smoothwall to the secondary Smoothwall.

Since this example covers configuration from scratch, you must follow the instructions from the step most appropriate to your current level of VPN connectivity.

Create the tunnel specification to the master Smoothwall, with Local certificate set to Default see Creating an IPsec Tunnel.

6.

Test the VPN connection.

The next step is to create an additional Certificate Authority on the secondary Smoothwall. This additional Certificate Authority is used to create another local certificate for the secondary Smoothwall, as well as certificates for any further site-to-site or roadwarrior connections that it is responsible for managing.

To create an additional Certificate Authority on the secondary Smoothwall system:

It is possible to authenticate a VPN tunnel by exchanging each host's public key with the other. During authentication, each host uses the other host's public key to decrypt the (private key encrypted) certificate it is passed as identity credentials.

This configuration does not require the Certificate Authority that created either host's certificate to be known to either VPN gateway. This can be useful in many ways:



Simplified internal management, using certificates created by an external Certificate Authority.



Tunnelling between two separate organizations using certificates created by different (possibly external) CAs.



Alternative scheme to allow both ends of the tunnel to create their own Certificate Authority and default local certificates. This would enable each VPN gateway to manage their own site-to-site and roadwarrior connections. This achieves the same result as the previous technique described in the Multiple local certificates section.

Note: The use of public key authentication should not be considered as a direct replacement for a stringent X509 based authentication setup. While public key authentication does use some of the same technologies that constitute an X509 solution, it lacks the ability to validate certificate authenticity. As such, appropriate precautions should be taken when considering implementing this alternative authentication method.

This configuration example uses public key authentication to connect two Smoothwalls, each with their own Certificate Authority so that they can manage their own site-to-site and roadwarrior connections.

The following assumptions have been made:



Two Smoothwalls



Each Smoothwall has its own Certificate Authority



Each Certificate Authority has created a signed certificate for its own local Smoothwall

Create an IPSec site-to-site tunnel specification on the first Smoothwall, and select the second Smoothwall’s host certificate in the Authenticate by drop-down list.

5.

Create an IPSec site-to-site tunnel specification on the second Smoothwall, and select the first Smoothwall’s host certificate in the Authenticate by drop-down list.

The tunnel can now be established and authenticated between the two Smoothwalls. In addition, each Smoothwall is able to autonomously manage its own site-to-site and roadwarrior connections by using its own Certificate Authority to create additional certificates.