Before you or a device can use a digital certificate you need to have it in a given device before it can use it. In this article we are going to have our client routers authenticate the CA server that we configured in the previous article as well as request for their own identity certificates.


The process of getting a digital certificate/signature is two-fold. First and foremost is the process of authenticating the CA server, and then the second part being requesting and identity certificate.


In order for this process to work successfully, all devices must have their clocks synchronized and the most preferable way to do that being NTP as we saw in the last article. In this article we are not going to configure the NTP server again for that we refer you to the previous article.






In this article we are going to use the same network topology as we did in the previous article. The following are the steps that we are going to use to authenticate the CA server, request our own identity certs for the two routers from the CA server and then lastly to use those digital certs for a site-to-site VPN authentication.

Step 1: Ensure that there is IP reachability between all the devices.

This step is very important since the devices that want to authenticate the CA server and receive their identity certs can’t do that if they don’t have IP connectivity to the CA server.


Step 2: Synchronize the time with NTP

This step is very important. All devices in the network must have their clocks synchronized with NTP before PKI can be rolled out.


Step 3: Generate the Public-Private Key pair.

For the PKI deployment to even be possible, each device must generate its own Public-Private key pair. This key pair is used to encrypt and decrypt data.


Step 4: Configure the PKI trustpoint with the following information:

1.     The info is

·        Configure the enrollment URL

·        Configure the RSA keypair

·        Configure the fqdn

·        Configure the subject name.

·        Configure info about the revocation check list.


Step 5: Authenticate the CA Server.

This step ensure that we can be able to trust this CA. A device takes the digital cert of the CA Server and will use it to verify the authenticity of other VPN peers. When you will authenticate the CA server you will be prompted to accept the CA Cert that you will receive from the CA Server, accept and continue.


Step 6: Request the Identity Certificate.

An identity certificate of a device is what identifies that device. It contains the device’s public key and it also contains the details of the CA Server that issued and signed this identity cert. You will be asked to enter a pass phrase that will be used to protect the private key. You will also be prompted to optionally enter the information that will appear in the Identity cert such as if you want the cert to include a serial number, also if you want the IP address to be included in this Identity cert. Enter the appropriate info and when prompted accept the identity cert that will be issued by the CA server.


Step 7. Implement IPSEC VPNs using RSA Digital Certs for Authentication

This step implements the site-to-site IPSec VPNs but now it uses the digital signatures that we have acquired. Authentication between VPN peers will happen or take place using digital signatures instead of Pre-shared keys (PSK).


Step 8. Verification

In this step we will verify both the digital certs that we received from the CA server and whether we formed the site-to-site IPsec VPNs using the RSA signatures.



Step 1. IP Reachability

This step verifies that each router is able to ping the ip address of the CA server and the other router’s public Internet facing IP address as shown below. The CA Server’s address is and the Kisii Router’s Public IP address is while the Kisumu router’s public IP address is














Step 2. Configuring NTP

We have already configured the NTP server in the previous article and now it is time to configure the Kisii and Kisumu routers to get their time synchronized with the NTP server. One thing we will configure though locally on each router is the time zone as we will show in the following configuration.


The Kisii Router.



The Kisumu Router






The Kisii Router




The Kisumu Router




Step 3: Generate the Public-Private Key pair.


The Kisii Router




The Kisumu Router




Step 4: Configuring the PKI Trustpoint


The Kisii Router




The Kisumu Router




Step 5: Authenticating the CA Server.


The Kisii Router




The Kisumu Router




Step 6: Request the Identity Certificate.


The Kisii Router:




The Kisumu Router




Step 7. Implement IPSEC VPNs using RSA Digital Certs for Authentication


The Kisii Router




The Kisumu Router




Step 8. Verification

Verifying the CA and Identity certs


The Kisii Router:




The Kisumu Router




RSA-SIG VPN Peer Authentication


The Kisii Router




The Kisumu Router




And that is it for this demonstration. We have successfully been able to have our routers acquire Digital Certs from the CA server and use those Digital certs in a site-to-site VPN peer authentication as we have verified above.








Authentication of VPN peers is very important in a Site-to-Site VPN deployment. Authentication ensures that a router can be able to verify the identity of the peer that this router is forming a VPN with. Authentication ensure that the VPN peer is who they say they are and not some rouge (attacker) router on the other end of the VPN.


VPN peer authentication can be accomplished in one of the two main ways: 1. Using Pre-Shared Keys (PKS) which is a password really, and 2. Using Digital signatures. Between these two methods of authentication, using Digital Signatures happens to be more secure and scalable. As the network expands and you have many VPN peers all wanting to authenticate each other, using Pre-Shared keys can be an administrative nightmare as well as managing and maintaining all these pre-shared keys between all the VPN peers.


There is doubt that using digital signatures for your VPN peer authentication is not only a more secure way to authenticate your VPN peers but it is also a more scalable way to manage your VPN peer authentication even as your network grows.


Digital signatures can be issued by a either a public Certificate Authority (CA) server like GoDaddy or VeriSign, or they can be locally issued from a private CA server from within the organization. The advantage of a Public CA server is that even the devices from outside the organization can be able to trust digital certificates signed by this CA server. If you want to enjoy the advantages that comes from using a public CA server, you have to pay some fee to the CA server to maintains this service, that may be the only drawback to using public CA servers.


If you have thousands of devices in your organization and you want all of them to use digital certs for authentication, using a public CA server will not make any economic sense since the cost that you could incur to maintain these digital certs could be astronomical. The only sensible solution could be to use a private CA server and then configure the machines within your organization to trust this private CA server.


In this article we are going to show you how to configure a Cisco router to act as a CA server for your organization. This solution of using a Cisco IOS router as a CA server is recommended for a small to medium sized organization where the devices needing the services of the CA server are not so many to overwhelm the router offering these services.


That being said, we jump right in on how to configure a Cisco router as a CA server. We are going to use the following topology diagram for our demonstration.





The following list gives a summary of steps that you could use to configure a Cisco router as a CA server.


Step 1: Ensure that there is Layer 3 reachability between the router you are going to configure as the CA server and the rest of the devices that are going to receive their identity certificates from this CA server


Step 2: Ensure that the time is right. That is to say that all devices in your network should have their clocks synchronized. The most reliable and preferable way to keep the time of the devices in your network synchronized is to use Network Time Protocol (NTP).


Step 3: Configure Public Key Infrastructure (PKI) on the CA server. Now this is the process of configuring your Cisco router as a CA server. Follow the following sub-steps to configure the CA server.


1.     Configure this router as a HTTP server.

2.     Enter into the PKI Server mode and configure the following

·        The Database url to nvram:

·        The database level to minimum.

·        Configure the issuer name.

·        Configure the cdp url.

·        (For this demonstration) configure the CA server to grant certificates automatically to anyone who asks.

·        Enable the CA server with the no shutdown command. Accept all the prompts that you are going to receive and finish the process.



Step 1: Ensuring IP reachability.

In this step we are going to ensure that there is IP reachability between this CA server and the MOIGETECH-KISII-EDGE-ROUTER and also with MOIGETECH-KISUMU-EDGE-ROUTER.


Pinging the Loopback address and the interface address of MOIGETECH-KISII-EDGE-ROUTER as shown below.








Pinging the Loopback address and the interface address of MOIGETECH-KISUMU-EDGE-ROUTER as shown below.








Step 2: Configure NTP.

Ideally, you could configure one router within your company to be a NTP client to an Internet facing secure public NTP server. This router will intern act as a NTP server for the devices within your company.


In this demonstration, we are going to configure this CA Server router to act as a NTP server for the two routers. Even though we don’t need this step to configure the CA related commands, the time need to be synchronized between the CA server and the clients going to receive Digital certs from the CA server. This step will also be done in the next article where we are going to use digital certs for peer authentication.




Verifying NTP status on the NTP server.


MOIGETECH_CA_SERVER# show ntp status




Step 3: Configuring CA related commands.


We are now going to configure all the commands that that are related to configuring a CA server in accordance to the summary steps mentioned previously.






MOIGETECH_CA_SERVER# show crypto pki server

This command gives us the summary of the configurations configured in the CA server.




MOIGETECH_CA_SERVER# show crypto pki certificates


This command shows us the details of the certificates that are found here. In this case it is the CA Certificate. It is this certificate that will be used to sign identity certificates of the clients.




And that is the end of this demonstration. This CA server is now ready to service any requests that it may receive. The next article will be about these client devices authenticating the CA server as well as requesting and getting its own identity certs.







 This is the first of many implementations of an IPSec site-to-site VPNs. In this first demo we show you the traditional way of implementing Site-to-site VPNs. Back in the day, it used to be rigid affair where the solution of implementing IPSec VPNs was not so scalable.


The solution is being used even today by most companies with few branches. The solution uses Crypto maps, Crypto ACLs, ISAKMP Policies, IPSec transform-sets among other things. This solution is not scalable and can only be appropriate for a small company with two or three branches. We have included this type of implementing VPNs for completion’s sake and they may be companies today who do implement this type of VPN.


Customer Needs

For this scenario, we have a customer with offices in Kisii City and Kisumu City, Kenya. The office in Kisii has a local area network and a single router, SAFARI-SACCO-KISII-HQ, that connects to the Internet. Router 2 (SAFARI-SACCO-KISUMU) is used to provide Internet access for the site in Kisumu. Figure 1 is a topology diagram of this network.


Figure 1: Company Network Topology with Two Sites




The site in Kisii has file servers that contain sensitive customer data, and the users at the site in Kisumu will need access to that data. In addition, users in Kisii need the ability to securely access some of the computers in Kisumu that have file sharing services enabled. Both sites are using private IP addresses for the LAN that cannot be forwarded directly over the Internet.


The customer has asked us for a recommendation to allow file services between the two offices that can be done securely. The customer also wants to ensure that the data as it is being sent over the networks does not become altered or corrupted in transit. The customer is also concerned about a possible attacker, who is on the Internet at some location other than the offices at Kisii or Kisumu being able to fool one of the routers by pretending to be the other router and connecting to the network. At the current time, the company does not need additional remote access to the networks other than directly between the two sites.


As we consider the VPN options that provide security, we should remember that IPsec can perform the following:


Confidentiality: Using symmetrical encryption algorithms such as 3DES, IDEA, AES, and so on to encrypt clear text into cipher text.


Data integrity: Using hashing algorithms such as MD5 or SHA and Hashed Message Authentication Code (HMAC) to verify that data has not been manipulated during its transit across the network.


Authentication: Done by authenticating the VPN peers near the beginning of a VPN session, using PSKs or digital signatures (leveraging digital certificates).


Hiding the private address space from the Internet: Because IPsec’s Encapsulation Security Protocol (ESP) in tunnel mode encrypts and encapsulates the original packet, and then places a new IP header before forwarding the packet, the Internet sees only the packet as being from the global IP address of one router and destined to the global address of the second router.





Now it is time to verify the already configured network if the IPsec Site-to-Site VPN is working properly. I am going to issue a series of commands that will help us verify if IPsec is working properly.


COMMAND: Show crypto isakmp policy

This command shows us the IKEv1 Phase 1 policy parameters configured on the router.


SAFARI-SACCO-KISII-HQ#Show crypto isakmp policy


Figure 2: Kisii_Router Show crypto isakmp policy




Figure 3 Kisumu_Router Show crypto isakmp policy


SAFARI-SACCO-KISUMU#Show crypto isakmp policy




COMMAND: Show crypto map


This command shows us the router that this router is peering with and the IP address of that router. It also shows us the following:


§  The crypto ACL that is used to match the “interesting traffic”.


§  Shows the Security Association Lifetime


§  Shows whether PFS has been configured or not


§  Shows the Transform Sets.


§  Also shows the interface on which the Crypto ACL has been enabled


SAFARI-SACCO-KISII-HQ# Show crypto map


Figure 4: Kisii Router Show crypto map




Figure 5: Kisumu Router Show crypto map


SAFARI-SACCO-KISUMU# Show crypto map




COMMAND: Show crypto isakmp sa detail


This command verifies the status and details of the following things:

§  This command shows the local and remote IP Addresses of the isakmp tunnel

§  Show the status of the isakmp Security Association (SA) whether is it Active or not.

§  Shows the type of encryption method used for the tunnel.

§  Shows the hashing algorithm used for the tunnel.

§  Shows the type of authentication used, either using pre-shared keys or RSA Digital Signatures.

§  Shows the DH group used for the tunnel.

§  Last but not least, shows the amount of time the tunnel has been up.



Figure 6: Kisii_Router Show crypto isakmp sa detail


SAFARI-SACCO-KISII-HQ# Show crypto isakmp sa detail




Figure 7 Kisumu_Router Show crypto isakmp sa detail


SAFARI-SACCO-KISUMU# Show crypto isakmp sa detail




COMMAND: Show crypto ipsec sa


This command shows us the details of the IPsec tunnel (The second tunnel) that carries user traffic


Figure 8: Kisii_Router Show crypto ipsec sa


SAFARI-SACCO-KISII-HQ# show crypto ipsec sa




Figure 9 Kisumu_Router Show crypto ipsec sa




COMMAND: Show crypto engine connections active


This command shows us the number of packets that have been encrypted and decrypted between the two routers forming the IPsec Tunnel. This command shows us both the ISAKMP tunnel (Management Tunnel) and the IPSec tunnels (User Data Tunnels) between the two routers.


Figure 10: Kisii_Router Show crypto engine connections active


SAFARI-SACCO-KISII-HQ# Show crypto engine connections active




Figure 11 Kisumu_Router Show crypto engine connections active


SAFARI-SACCO-KISUMU# Show crypto engine connections active








IP Security (IPsec) is one of the most mature VPN standards in the industry. The secret of IPsec is that it is not locked in to one specific protocol or even one set of protocols. As technology advances, so can the protocols that are being used by IPsec. The goal of IPsec is quite simple: to provide confidentiality, data integrity, and authentication of the virtual private network (VPN) peer and provide antireplay support. It implements all of these to Layer 3 packets individually, protecting each one as it is sent from one end of the VPN tunnel until it reaches the other end.



To best understand how IPsec operates, let’s take a look at a simple topology that we can use as a framework for this entire article, shown here in Figure 1.


Figure 1: IPsec Example Topology




IPsec has four fundamental goals, as shown in Table 1.


Table 1: IPsec Goals and the Methods Used to Implement Them




Method That Provides the Feature



Data integrity


Peer authentication

Pre-shared keys, RSA digital signatures


Integrated into IPsec, basically applying serial numbers to packets


The goals can be described as follows:



Provided through encryption changing clear text into cipher text.


Data integrity:

Provided through hashing and/or through Hashed Message Authentication Code (HMAC) to verify that data has not been manipulated during its transit across the network.



Provided through authenticating the VPN peers near the beginning of a VPN session using pre-shared keys (PSK) or digital signatures (leveraging digital certificates). Authentication can also be done continuously through the use of an HMAC, which includes a secret known only to two ends of the VPN.


Antireplay protection:

When VPNs are established, the peers can sequentially number the packets, and if a packet is attempted to be replayed again (perhaps by an attacker), the packet will not be accepted because the VPN device believes it has already processed that packet.


From our topology, we could decide that any traffic from the network on the far left that needs to go to the network on the far right should first be encrypted by R1, which would then send the protected packets over the Internet until they reach R2. The cloud between R1 and R2 represents an untrusted network, such as the Internet. R2 then decrypts each packet and sends the traffic on to its final destination, which may be a PC or server on the network. The protected packets could be encrypted, hashed, and kept track of to provide the four major benefits previously listed.



IPsec uses the Internet Key Exchange (IKE) protocol to negotiate and establish secured site-to-site or remote access virtual private network (VPN) tunnels. IKE is a framework provided by the Internet Security Association and Key Management Protocol (ISAKMP) and parts of two other key management protocols, namely Oakley and Secure Key Exchange Mechanism (SKEME).


In IKE Phase 1 IPsec peers negotiate and authenticate each other. In Phase 2 they negotiate keying materials and algorithms for the encryption of the data being transferred over the IPsec tunnel.


There are two versions of IKE:

§  IKEv1: Defined in RFC 2409, The Internet Key Exchange


§  IKE version 2 (IKEv2): Defined in RFC 4306, Internet Key Exchange (IKEv2) Protocol


IKEv2 enhances the function of performing dynamic key exchange and peer authentication. IKEv2 simplifies the key exchange flows and introduces measures to fix vulnerabilities present in IKEv1. Both IKEv1 and IKEv2 protocols operate in two phases. IKEv2 provides a simpler and more efficient exchange.


Phase 1 in IKEv2 is IKE_SA, consisting of the message pair IKE_SA_INIT. IKE_SA_INIT is used to initiate the IKE negotiation. IKE_SA is comparable to the IKEv1 Phase 1. The security association (SA) is the keying material used to encrypt packets over the VPN tunnel.


The attributes of the IKE_SA phase are defined in the key exchange policy. The second phase in IKEv2 is CHILD_SA. The first CHILD_SA (Phase 2 SA) is the IKE_AUTH message pair. This phase is comparable to the IKEv1 Phase 2. Additional CHILD_SA message pairs can be sent for rekey and informational messages. The CHILD_SA attributes are defined in the data policy.


Differences from IKEv1 include the following:

§  IKEv1 Phase 1 has two possible exchanges: main mode and aggressive mode. There is a single exchange of a message pair for IKEv2 IKE_SA.


§  IKEv2 has a simple exchange of two message pairs for the CHILD_SA. IKEv1 uses at least a three-message pair exchange for Phase 2.








Many organizations deploy virtual private networks (VPN) to provide data integrity, authentication, and data encryption to ensure confidentiality of the packets sent over an unprotected network or the Internet. VPNs are designed to avoid the cost of unnecessary leased lines. Understanding why VPNs are important and the underlying building blocks that make them work so well is the focus of topic.



If we break down the term virtual private network into its individual components, we could say that a network allows connectivity between two devices. Those two devices could be computers on the same local-area network or could be connected over a wide-area network. In either case, a network is providing the basic connectivity between the two. The word virtual in VPN refers to a logical connection between the two devices.


For example, one user may be connected to the Internet in Kisii City, and another user may be connected to the Internet in Nairobi City, and we could build a logical network, or virtual network, between the two devices using the Internet as our transport mechanism. The letter P in VPN refers to private. The virtual network we could create between our two users in Kisii and Nairobi would be private between those two parties. So, there are the basics for VPN, a virtual private network.


One of the main advantages of using a VPN is cost. It is much cheaper to connect the user to the Internet through a local service provider than to purchase a dedicated circuit that goes to only one other destination.


Another benefit of using a VPN is scalability. If 10 or 20 more new users need to connect to the corporate headquarters, we can provide users access to the Internet via their local service providers (digital subscriber line [DSL], cable modem, and so on). Leveraging the single Internet connection from the headquarters site, we could then simply build logical VPNs using the Internet for the connectivity.



Based on the definition of a virtual private network, the following could be considered VPN technologies:


IPsec: Implements security of IP packets at Layer 3 of the OSI model, and can be used for site-to-site VPNs and remote-access VPNs.


SSL: Secure Sockets Layer implements security of TCP sessions over encrypted SSL tunnels of the OSI model, and can be used for remote-access VPNs (as well as being used to securely visit a web server that supports it via HTTPS).


MPLS: Multiprotocol Label Switching and MPLS Layer 3 VPNs are provided by a service provider to allow a company with two or more sites to have logical connectivity between the sites using the service provider network for transport. This is also a type of VPN (called MPLS L3VPN), but there is no encryption by default.  IPsec could be used on top of the MPLS VPN to add confidentiality (through encryption) and the other benefits of IPsec to protect the Layer 3 packets.


MPLS L3VPNs are not the primary type of VPNs we focus on for the rest of this topic and security series. The primary VPNs that provide encryption, data integrity, authentication of who the peer is on the other end of the VPN, and so on use IPsec or SSL.



There are two major categories into which VPNs could be placed: remote-access and site-to-site. The following are details about each, including when they might be used:


Remote-access VPNs:

Some users might need to build a VPN connection from their individual computer to the corporate headquarters (or to the destination they want to connect to). This is referred to as a remote-access VPN connection. Remote-access VPNs can use IPsec or Secure Shell (SSL) technologies for their VPN. Many Cisco customers use the Cisco AnyConnect client for remote access SSL VPNs. SSL VPN use is more prevalent, even though the Cisco AnyConnect client also supports IPsec (IKEv2).


Site-to-site VPNs:

The other main VPN implementation is by companies that may have two or more sites that they want to connect securely together (likely using the Internet) so that each site can communicate with the other site or sites. This implementation is called a site-to-site VPN. Site-to-site VPNs traditionally use a collection of VPN technologies called IPsec.


Figure 1 shows an example of site-to-site and remote-access VPNs. The Cisco ASA in the Raleigh, North Carolina, corporate headquarters is configured to accept remote-access SSL VPN connections, in addition to a site-to-site tunnel with a branch in San Jose, California.


Figure 1: Example of Remote-Access and Site-to-Site VPNs





The main benefits of using either remote-access or site-to-site VPNs include the following:

§  Confidentiality

§  Data integrity

§  Authentication

§  Anti-replay protection






Go to top