FlexVPN PKI Authentication

In the FlexVPN site-to-site smart defaults lesson, we used a pre-shared key (PSK) to authenticate the routers to each other. We can also use Public Key Infrastructure (PKI) for authentication. This means we use a certificate to authenticate ourselves instead of the PSK.

Cisco IOS supports everything you need for PKI. You can configure one router as a Certificate Authority (CA), generate a certificate, and use that certificate to authenticate to the other router instead of a PSK.

Configuration

This is the topology we’ll use:

We use the two routers from the FlexVPN site-to-site smart defaults lesson and make some changes to this network:

• We configure a CA on R1.
• We generate a certificate on R1.
• We configure R1 so it authenticates itself to R2 with a certificate.
• We configure R2 to verify the certificate from R1.

R2 will still authenticate itself to R1 with its PSK. In a real network, you would also generate a certificate for R2 and use that for authentication. I am using IOSv Version 15.9(3)M2.

hostname R1
!
ip cef
!
crypto ikev2 keyring KEYRING
 peer R2
  address 192.168.12.2
  pre-shared-key local CISCO
  pre-shared-key remote CISCO
!
crypto ikev2 profile default
 match identity remote fqdn R2.NWL.LAB
 identity local fqdn R1.NWL.LAB
 authentication remote pre-share
 authentication local pre-share
 keyring local KEYRING
!
crypto ipsec profile default
 set ikev2-profile default
!
interface Tunnel0
 ip address 172.16.12.1 255.255.255.0
 tunnel source GigabitEthernet0/0
 tunnel destination 192.168.12.2
 tunnel protection ipsec profile default
!
interface GigabitEthernet0/0
 ip address 192.168.12.1 255.255.255.0
!
end

hostname R2
!
ip cef
!
crypto ikev2 keyring KEYRING
 peer R1
  address 192.168.12.1
  pre-shared-key local CISCO
  pre-shared-key remote CISCO
!
crypto ikev2 profile default
 match identity remote fqdn R1.NWL.LAB
 identity local fqdn R2.NWL.LAB
 authentication remote pre-share
 authentication local pre-share
 keyring local KEYRING
!
crypto ipsec profile default
 set ikev2-profile default
!
interface Tunnel0
 ip address 172.16.12.2 255.255.255.0
 tunnel source GigabitEthernet0/0
 tunnel destination 192.168.12.1
 tunnel protection ipsec profile default
!
interface GigabitEthernet0/0
 ip address 192.168.12.2 255.255.255.0
!
end

R1

Let’s start with R1.

Certificate Authority (CA)

To communicate with the CA, we need to enable the HTTP server:

R1(config)#ip http server 

Let’s turn R1 into a CA:

R1(config)#crypto pki server R1-CA
R1(cs-server)#issuer-name cn="R1-CA"
R1(cs-server)#grant auto
R1(cs-server)#no shutdown
%Some server settings cannot be changed after CA certificate generation.

Password: 

Re-enter password: 
% Generating 1024 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 0 seconds)

% Certificate Server enabled.

R1 is now a CA and ready to create certificates.

ID Trustpoint

We are going to create a client certificate for R1. First, we need to set a domain name:

R1(config)#ip domain name NWL.LAB

Now we configure a new trustpoint. This is where we set the enrollment URL we use to reach the CA. We also set a subject name for the certificate:

R1(config)#crypto pki trustpoint R1-CLIENT
R1(ca-trustpoint)#enrollment url http://192.168.12.1
R1(ca-trustpoint)#subject-name cn=R1-CLIENT.LAB.NWL

Let’s accept the certificate from the CA:

R1(config)#crypto pki authenticate R1-CLIENT
Certificate has the following attributes:
       Fingerprint MD5: 41AD31E8 DE034F0C 0F4415EA 37165620 
      Fingerprint SHA1: AB9EC15F FBBF7C9A 2F85C44F 654FE42C 3EF77A8E 

% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.

Now we can request a client certificate for R1:

R1(config)#crypto pki enroll R1-CLIENT
%
% Start certificate enrollment .. 
% Create a challenge password. You will need to verbally provide this
   password to the CA Administrator in order to revoke your certificate.
   For security reasons your password will not be saved in the configuration.
   Please make a note of it.

Password: 
Re-enter password: 

% The subject name in the certificate will include: cn=R1-CLIENT.LAB.NWL
% The subject name in the certificate will include: R1.NWL.LAB
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: no
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The '
' commandwill show the fingerprint.

R1 now has a client certificate we can use to authenticate to R2.

IKEv2 Profile

We need to change the IKEv2 profile to use the certificate instead of a PSK:

R1(config)#crypto ikev2 profile default
R1(config-ikev2-profile)#authentication local rsa-sig
R1(config-ikev2-profile)#identity local dn
R1(config-ikev2-profile)#pki trustpoint R1-CLIENT

This completes the configuration on R1.

R2

There are two things we have to do on R2:

• Authenticate the CA trustpoint so we can verify R1’s certificate.
• Configure the IKEv2 profile to authenticate R1 with R1’s certificate.

Authenticate CA trustpoint

We’ll create a new trustpoint and set the enrollment URL of the CA:

R2(config)#crypto pki trustpoint R2-CLIENT
R2(ca-trustpoint)#enrollment url http://192.168.12.1
R2(ca-trustpoint)#revocation-check none

Now we can configure the CA trustpoint:

R2(config)#crypto pki authenticate R2-CLIENT
Certificate has the following attributes:
       Fingerprint MD5: 41AD31E8 DE034F0C 0F4415EA 37165620 
      Fingerprint SHA1: AB9EC15F FBBF7C9A 2F85C44F 654FE42C 3EF77A8E 

% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.

IKEv2 Profile

Let’s configure the IKEv2 profile so that we authenticate R1 with its certificate. The IKEv2 profile requires a certificate map where we configure the issuer name of R1’s certificate:

R2(config)#crypto pki certificate map R2-CLIENT-MAP 10
R2(ca-certificate-map)#issuer-name eq cn=R1-CA

Change the IKEv2 profile to authenticate R1’s certificate:

R2(config)#crypto ikev2 profile default
R2(config-ikev2-profile)#match certificate R2-CLIENT-MAP
R2(config-ikev2-profile)#authentication remote rsa-sig

This completes the configuration on R2.

Verification

Let’s verify our work. I’ll focus on show commands that tell us we are using the certificate for authentication. First, let’s check the certificate on R1:

R1#show crypto pki certificate verbose R1-CLIENT
Certificate
  Status: Available
  Version: 3
  Certificate Serial Number (hex): 02
  Certificate Usage: General Purpose
  Issuer: 
    cn=R1-CA
  Subject:
    Name: R1.NWL.LAB
    hostname=R1.NWL.LAB
    cn=R1-CLIENT.LAB.NWL
  Validity Date: 
    start date: 15:21:50 UTC Dec 23 2020
    end   date: 15:21:50 UTC Dec 23 2021
  Subject Key Info:
    Public Key Algorithm: rsaEncryption
    RSA Public Key: (1024 bit)
  Signature Algorithm: SHA1 with RSA Encryption
  Fingerprint MD5: 29D2C4DF 4A1EC296 5BEDBBF6 F5C3D626 
  Fingerprint SHA1: 6D128664 F87369FB 93DC9B70 59D6BBA8 E4BCA26E 
  X509v3 extensions:
    X509v3 Key Usage: A0000000
      Digital Signature
      Key Encipherment
    X509v3 Subject Key ID: 648C1B44 EA227444 DD67269D C06AB5FC 52490C0C 
    X509v3 Authority Key ID: BFA5B53C EDD072A2 D6CA5578 328676FF FE247582 
    Authority Info Access:
  Associated Trustpoints: R1-CLIENT
  Key Label: R1.NWL.LAB

CA Certificate
  Status: Available
  Version: 3
  Certificate Serial Number (hex): 01
  Certificate Usage: Signature
  Issuer: 
    cn=R1-CA
  Subject: 
    cn=R1-CA
  Validity Date: 
    start date: 15:19:03 UTC Dec 23 2020
    end   date: 15:19:03 UTC Dec 23 2023
  Subject Key Info:
    Public Key Algorithm: rsaEncryption
    RSA Public Key: (1024 bit)
  Signature Algorithm: MD5 with RSA Encryption
  Fingerprint MD5: 41AD31E8 DE034F0C 0F4415EA 37165620 
  Fingerprint SHA1: AB9EC15F FBBF7C9A 2F85C44F 654FE42C 3EF77A8E 
  X509v3 extensions:
    X509v3 Key Usage: 86000000
      Digital Signature
      Key Cert Sign
      CRL Signature
    X509v3 Subject Key ID: BFA5B53C EDD072A2 D6CA5578 328676FF FE247582 
    X509v3 Basic Constraints:
        CA: TRUE
    X509v3 Authority Key ID: BFA5B53C EDD072A2 D6CA5578 328676FF FE247582 
    Authority Info Access:
  Associated Trustpoints: R1-CLIENT R1-CA

The output above gives me information about the CA and client certificates. Let’s check the VPN.  If you already had IKEv2 SA based on PSKs, it’s best to clear those:

R1#clear crypto ikev2 sa

Let’s generate some traffic to trigger the VPN:

R1#ping 172.16.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/6 ms

I can verify our authentication methods by looking at the IKEv2 profile:

R1#show crypto ikev2 profile | include authentication method
 Local authentication method: rsa-sig
 Remote authentication method(s): pre-share

Let’s check the IKEv2 SA:

R1#show crypto ikev2 sa detailed 
 IPv4 Crypto IKEv2  SA 

Tunnel-id Local                 Remote                fvrf/ivrf            Status 
1         192.168.12.1/500      192.168.12.2/500      none/none            READY  
      Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:5, Auth sign: RSA, Auth verify: PSK
      Life/Active Time: 86400/77 sec
      CE id: 1005, Session-id: 4
      Status Description: Negotiation done
      Local spi: 4DF61A7B597A360C       Remote spi: 49D091E94ED9C4D3
      Local id: hostname=R1.NWL.LAB,cn=R1-CLIENT.LAB.NWL
      Remote id: R2.NWL.LAB
      Local req msg id:  2              Remote req msg id:  0         
      Local next msg id: 2              Remote next msg id: 0         
      Local req queued:  2              Remote req queued:  0         
      Local window:      5              Remote window:      5         
      DPD configured for 0 seconds, retry 0
      Fragmentation not  configured.
      Dynamic Route Update: disabled
      Extended Authentication not configured.
      NAT-T is not detected  
      Cisco Trust Security SGT is disabled
      Initiator of SA : Yes

 IPv6 Crypto IKEv2  SA 

There are a couple of interesting things we see in the output above: