While pre-shared keys (PSKs) are commonly used in many VPN deployments, they have limitations in terms of scalability and security. Cisco IOS devices support an alternative: certificate-based authentication using an IOS-based Certificate Authority (CA). This approach enhances trust, automates identity verification, and strengthens encryption handling in IPSec VPNs.

Replacing Pre-Shared Keys with Public/Private Keypairs

Instead of manually managing shared secrets across devices, certificates rely on asymmetric encryption. This involves two keys:

  • The public key, which is used to encrypt data.
  • The private key, which is used to decrypt it.

This method increases security, as one key cannot be used to derive the other. The use of certificates also makes large-scale deployments more manageable and secure by ensuring identity validation through a trusted authority.

What is a Certificate Authority (CA)?

A Certificate Authority acts as the trusted entity that issues digital certificates to routers and other network devices. The CA can either be a dedicated external server or hosted on an IOS router itself. When configured, the IOS router can generate and issue X.509 certificates to clients.

Each certificate digitally verifies identity and is signed by the CA, allowing the router to confirm the legitimacy of its peers without manual key management.

X.509 v3 Certificate Structure

An X.509 v3 certificate includes several key fields that define identity, purpose, and validity:

  • Version
  • Serial Number
  • Issuer
  • Validity Period
  • Subject (including both structured attributes like CN, OU, and unstructured parts like IP addresses)
  • Subject Public Key Info
  • Extensions (optional)
  • Certificate Signature Algorithm
  • Certificate Signature

The Distinguished Name (DN) field in the subject helps uniquely identify the certificate holder, combining attributes like CN (Common Name), OU (Organizational Unit), C (Country), and more.

Certificate Validation Process

When a peer receives a certificate, the router performs a detailed validation. Once the correct trustpoint (Root CA certificate) is found, the router checks:

  • The digital signature
  • The Certificate Revocation List (CRL)
  • The certificate’s validity dates

If all checks pass, the certificate is considered valid and can be cached in the public keyring for faster reuse. Cisco routers also allow use of Certificate Maps (ACL-like filters) to restrict which certificates are accepted or to bypass some validation steps. These maps can match fields like IP, serial number, or FQDN.

Cached certificates that have already been validated aren’t rechecked until their timeout, which boosts performance. You can manage this behavior using the command:

crypto key pubkey-chain rsa

Certificate Issuance and Use in IOS

Deploying a Cisco IOS router as a CA provides a lightweight yet effective PKI solution. It replaces manual pre-shared keys with robust asymmetric encryption and leverages X.509 certificates to automatically validate identities. For environments demanding high security and minimal operational overhead, certificate-based IPSec VPN authentication is the way forward.

Building a Cisco IOS-Based PKI and VPN with Certificate Authentication

In secure network environments, managing IPSec VPNs with pre-shared keys can become cumbersome and insecure at scale. To address this, Cisco routers can be configured as Certificate Authorities (CAs) to issue, manage, and validate digital certificates. These certificates can then be used to replace PSKs, bringing in the strength of asymmetric cryptography and centralized trust.

This guide walks through the full setup: configuring an IOS router as a CA server, issuing certificates to peers, and establishing an IPSec VPN using certificate-based authentication.

Step 1: Set Time on the Router

Certificates depend on accurate time to validate issuance and expiration. Cisco IOS will block CA configuration unless the time or NTP is set.

clock set 12:00:00 June 10 2025
ntp server x.x.x.x

Step 2: Configure the CA Server on the Router

Start by generating a public/private key pair that will be used to sign certificates:

crypto key generate rsa modulus 1024 label MYCASERVER

Enable HTTP services so peers can reach the CA:

ip http server

Next, configure the CA server itself and specify where the certificate database will be stored:

crypto pki server MYCASERVER
database url flash:
issuer-name cn=MY CA SERVER O=ABC OU=Training L=LONDON C=UK
no shutdown

Step 3: Enroll a Peer Device with the CA

On each router that needs a certificate.

1. Set the domain name and generate RSA keys:

ip domain-name cisco.com
crypto key generate rsa modulus 1024

2. Configure a trustpoint pointing to the CA:

crypto pki trustpoint CAS
enrollment url http://1.1.1.1
revocation-check none

3. Authenticate the CA by downloading its root certificate:

crypto pki authenticate CAS

4. Enroll and send the public key to be signed:

crypto pki enroll CAS

You’ll be prompted for a password; this is a revocation password for future use.

If grant auto is not configured on the CA, you’ll need to manually approve the request:

show crypto pki server MYCASERVER requests
crypto pki server MYCASERVER grant 1

Step 4: Replace PSK with Certificate-Based VPN (ISAKMP + IPSec)

On both routers, configure ISAKMP (Phase 1) to use certificates:

crypto isakmp policy 10
authentication rsa-sig
hash md5
encryption 3des
group 2

Configure the transform set (Phase 2):

crypto ipsec transform-set ABC esp-3des esp-md5

Define the interesting traffic that should trigger the VPN tunnel:

access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255

Create the crypto map and bind it to the VPN peer:

crypto map CMAP 10 ipsec-isakmp
set peer 192.168.12.2
set transform-set ABC
match address 101

Apply the crypto map to the correct interface:

interface g2
crypto map CMAP

Using Certificate Maps with Cisco IPSec VPNs for Scalable Identity Matching

In large-scale IPSec VPN deployments, especially when routers or users present different certificate identities, certificate maps provide a powerful way to selectively authenticate peers based on their certificate attributes. Rather than relying solely on trustpoints or pre-shared keys, certificate maps enable granular control over which certificates are accepted, based on criteria such as subject name, organization, or issuer.

Let’s explore how to configure VPNs using certificate maps on Cisco routers and how to verify and troubleshoot the setup.

Step 1: Configure the Certificate Authority (CA) Trustpoint

Begin by defining a trustpoint to the CA that issued the certificates. This links your router to the CA and sets how certificate checks are handled:

crypto pki trustpoint IOS-CA
enrollment url http://2.2.2.2:80
password cisco123
subject-name cn=r10.cisco.com, ou=itworkers, l=san jose, c=US
revocation-check none

Step 2: Configure ISAKMP Policy (Phase 1)

Define how IPSec will authenticate peers, using RSA-signed certificates in this case:

crypto isakmp policy 10
authentication rsa-sig
encryption aes
hash sha
group 5

Step 3: Define the “Interesting” Traffic

Set up an access list to specify which traffic will trigger the VPN tunnel:

access-list 101 permit ip 1.1.1.0 0.0.0.255 2.2.2.0 0.0.0.255

Step 4: Configure the IPSec Transform Set (Phase 2)

Define the algorithms used to protect the data phase of the tunnel:

crypto ipsec transform-set tset esp-aes esp-sha-hmac

Step 5: Create and Apply the Certificate Map

Certificate maps allow you to match certificate fields like subject name. This example matches the domain cisco.com in the subject:

crypto pki certificate map CERT_MAP 10
subject-name co cisco.com

Link the certificate map to an ISAKMP profile:

crypto isakmp profile ISA_PROF
match certificate CERT_MAP

Step 6: Configure the Crypto Map

The crypto map ties everything together and is applied to the outbound interface:

crypto map CMAP 10 ipsec-isakmp
set peer 101.1.1.1
set transform-set tset
set pfs group5
set isakmp-profile ISA_PROF
match address 101

Apply the crypto map to the interface:

interface g1
crypto map CMAP

Step 7: Verification and Troubleshooting

Once configured, you’ll want to validate your PKI and IPSec operations.

View installed certificates:

show crypto pki certificate

View the public keyring:

show crypto key pubkey-chain rsa

Check IPSec session status:

show crypto session detail

The show crypto session detail output confirms whether Phase 1 and Phase 2 are active, lists the peer IP, the encryption/authentication algorithms used, and session uptime. Certificate maps will be referenced under the active ISAKMP profile if matched correctly.

Enable debugging for deeper insight:

debug crypto pki mess
debug crypto pki server
debug crypto pki transaction
debug crypto pki validation